Hacker News new | past | comments | ask | show | jobs | submit login

That's just an illustration of how it can be done otherwise. The only non-standard thing there is that CSS glue construct:

   selector { aspect: Func url(script.js); }
It tells that as soon as element matching that selector will appear in the DOM it will have Func() called (from script.js). No complex abstractions are required.

"to share internal web component libraries within my own company, never mind some other 3rd party"

My pardon, I didn't get the "to share" part, who share, what, and with whom?




I meant creating a web component based widget library and sharing that for use on anything from desktop GUIs to web sites.

Sciter’s approach is pretty much the same approach used by web components (combining css/html/js to a single reuseable element). Unfortunately it isn’t 100% compliant with browser based web components and hence Sciter based widget libraries can not be used for web sites or vice versa.


Again, that's not about Sciter but rather discussion of Web Components idea in general.

Essentially WebComponent is the way of associating some JS class with custom DOM elements.

At the nutshell, WebComponents is just this one JS function:

    customElements.define('hello-world', HelloWorld);
But it is quite limited as you see - a) only custom elements and b) you need to load some JS file in order to initialize bindings.

That element->JS code binding could be done by CSS with much greater flexibility:

    /* custom element */
    hello-world { aspect: HelloWorld url(hello-world.js); }

    /* existing element */
    span.hello-world { aspect: HelloWorld url(hello-world.js); }

    /* existing element, conditionally */
    a[href^="http"] { aspect: HelloWorld url(hello-world.js); }
Yet note that, in case of CSS bindings, hello-world.js will be loaded only if your document will have matching elements - better componentization I would say.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: