4 ms·
In case anyone was wondering, JavaScript per se isn't replaced at all. All mentioned examples still use event listeners, querySelectorAll, ES modules, and what
by tannhaeuser 3y ago
In case anyone was wondering, JavaScript per se isn't replaced at all. All mentioned examples still use event listeners, querySelectorAll, ES modules, and what not. Most importantly, you need to subclass HTMLElement and register your custom element using JavaScript in the first place eg:
class MyElement
extends HTMLElement {
}
window.customElements
.register('my-element',
MyElement)
(the hyphen in the name is idiosyncratically required by the custom element spec).
As such, "HTML web components" (aka custom elements, which have be around for many years) are targeted at developers not hypothetical web users/authors. Then what is the point? When you're relying on JavaScript anyway, you have already much greater freedoms - syntactically and otherwise.
Custom element declarations and custom vocabularies can make sense as a means to organize and isolate authoring concerns when you're creating hypertext documents. The fact alone that you have to use JavaScript for registering custom elements make them a non-starter though (ie consider an authoring tool which surely doesn't want to execute arbitrary JavaScript in client docs).
It's not that there's no precedent either. SGML has a mechanism for parametric macro expansion where your element is syntactically replaced into an arbitrary markup fragment, with type-checked arguments (= attributes at the call site, just as with custom elements), and with type-checking the resultant expansion in context (ie. checking whether the expansion adheres to the content model at the expansion site), also having of course the capability to include JavaScript. Moreover, SGML actually can serialize/re-parse such markup whereas HTML's preliminary APIs for fragment parsing won't deal with contextual tag inference at all.
- runarberg 3y agoFor me, being able to offer my library as a web component is kind of neat. Sure I can ask users of my library to import it then query select math inputs, then apply my library on these, and remember to apply it also on DOM change. <script type="module"> import lib from "/path/to/my/lib.js"; for (const target of document.querySelectorAll(".target")) { lib(target); } // TODO: Watch for DOM change and apply lib. <script> <span class="target">Some Input</span> Or I can simply ask them to import my web component module and use the custom element: <script src="/path/to/my/web-component.js"></script> <my-lib>Some input</my-lib> The latter certainly feels like a superior API for my users.
- svieira 3y agoOr you can do a little more work in your lib for your users and offer: <script type="module"> import lib from "the-lib.co.uk"; lib({ target: ".target" }); </script> If your users might not want you to watch the _whole_ DOM for performance reasons: <script type="module"> import lib from "the-lib.co.uk"; lib({ target: ".target", root: ".all-the-targets-show-up-here" }); </script> And if your users might already have a mutation observer in their apps: <script type="module"> import lib from "the-lib.co.uk"; lib({ target: ".target", observer: theAppObserver }); </script>
- runarberg 3y agoIt may just be me, but all of these seem a lot inferior API design then a simple web component. Particularly if I’m asking my users to setup a mutation observer. Aside: Don’t you need to pass the library function into the callback while constructing the mutation observer? import lib, { mutationObserverCallback } from "https://my-lib.example"; lib({ target: ".target", observer: new MutationObserver(mutationObserverCallback), }); Honestly, this feels like so much magic compared to a simple: <my-lib>Some Input</my-lib> where I handle update in my library by listening to the slotchange event.