The Failed Promise of Web Components
It would have helped a lot if JS had a working modules systems on the web.<p>&gt; What hope do those who can’t write JS have? Using a custom element from the directory often needs to be preceded by a ritual of npm flugelhorn, import clownshoes, build quux, all completely unapologetically because “here is my truckload of dependencies, yeah, what”.<p>JS has been in a dark &amp; ugly spot, &amp; WebComponents feeling janky &amp; weird is probably 50% the fact that JS is this dark twisting maze where each project has it&#x27;s own very unique assumptions about how to turn authored JS into usable, deployable JS. We&#x27;re still hoping, praying that import-maps eventually give us modular javascript code that we can deploy, without having to push it through a handful of compile&#x2F;build tools: <a href="https:&#x2F;&#x2F;github.com&#x2F;Fyrd&#x2F;caniuse&#x2F;issues&#x2F;4810" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Fyrd&#x2F;caniuse&#x2F;issues&#x2F;4810</a><p>By compare, Big Framework land often adopts some suggested normative best paths people can work with (ex, create-react-app bundling build&#x2F;test&#x2F;&amp;c tools). Alas, the language itself is still, a decade latter, trying to proceed to useable modules on the web.<p>The other major point of this article tends towards a JS vs HTML problem, another area I am very sympathetic to &amp; have hopes for.<p>&gt;  Far more people can write HTML than JS. Even for those who do eventually write JS, it often comes after spending years writing HTML &amp; CSS. [...] If components are designed in a way that requires JS, this excludes thousands of people from using them.<p>There are ongoing efforts with HTML Modules ( <a href="https:&#x2F;&#x2F;www.chromestatus.com&#x2F;feature&#x2F;4854408103854080" rel="nofollow">https:&#x2F;&#x2F;www.chromestatus.com&#x2F;feature&#x2F;4854408103854080</a> ) to try to make, among other things, bringing in WebComponents much easier, and Declarative Custom Elements ( <a href="https:&#x2F;&#x2F;blog.usejournal.com&#x2F;w3c-declarative-custom-elements-proposal-b9640e54a5fd" rel="nofollow">https:&#x2F;&#x2F;blog.usejournal.com&#x2F;w3c-declarative-custom-elements-...</a> ) to make building modules much more HTML-centric &amp; declarative versus today where most of the authoring of a custom element has to be done in JS.<p>There are very real problems, there is too much js, the js module system is still in a 1&#x2F;2 complete state on the web, &amp; these very much dog Web Components. But the future is exciting, &amp; I continue to have hope that a much better, much more web native way of building emerges on the web platform. Lea talks a lot to how scattershot the last decade of work has been, how inconsistent, but given the other ecosystem constraints I&#x27;m not fully surprised, &amp; I&#x27;m delighted that we are spending so long building &amp; experimenting &amp; learning, that for many of us, the hunger is very real. Also missing, the big adopters of WebComponents have been pretty silent, their thought-leadership seems missing: Youtube, Github. There are visible people from these worlds talking about WebComponents, but to my knowledge the real experience of WebComponents at scale from the very successful adopters remains a story not told.