4 ms·

I love Sciter and it is pretty amazing for what it does, but I still wouldn’t use it to share internal web component libraries within my own company, never mind

I love Sciter and it is pretty amazing for what it does, but I still wouldn’t use it to share internal web component libraries within my own company, never mind some other 3rd party. Sciter unfortunately uses it’s own dialect of JavaScript and CSS which might not be compliant with browser JavaScript engines. I really wish Sciter would move to some other commonly used JS engine and get rid of TIScript, then I would be more confident with creating an internal library, at least I would be able to use web components in a cross compliant way between browsers and Sciter.

c-smile 6y ago
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?
- DethNinja 6y ago
  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.
  - c-smile 6y ago
    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.
EdwinLarkin 6y ago
Your comment makes absolutely no sense. Sciter is not a browser engine nor it tries to sell itself as a browser engine light. Sciter just happens to use dialects that are similar to CSS and JS sort of what XAML is to WPF or what QML is to QT.

c-smile 6y ago

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?

DethNinja 6y ago
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.
- c-smile 6y ago
  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.

EdwinLarkin 6y ago

Your comment makes absolutely no sense. Sciter is not a browser engine nor it tries to sell itself as a browser engine light. Sciter just happens to use dialects that are similar to CSS and JS sort of what XAML is to WPF or what QML is to QT.