The Failed Promise of Web Components

Man I remember reading about web components some years ago after reading up on Poylmer Dart. It seemed like they were destined to become a common standard for building web apps soon(tm) but I guess frameworks like React blew up a lot quicker.

It would have helped a lot if JS had a working modules systems on the web.

> 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”.

JS has been in a dark & ugly spot, & WebComponents feeling janky & weird is probably 50% the fact that JS is this dark twisting maze where each project has it's own very unique assumptions about how to turn authored JS into usable, deployable JS. We'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/build tools: https://github.com/Fyrd/caniuse/issues/4810

By compare, Big Framework land often adopts some suggested normative best paths people can work with (ex, create-react-app bundling build/test/&c tools). Alas, the language itself is still, a decade latter, trying to proceed to useable modules on the web.

The other major point of this article tends towards a JS vs HTML problem, another area I am very sympathetic to & have hopes for.

> Far more people can write HTML than JS. Even for those who do eventually write JS, it often comes after spending years writing HTML & CSS. [...] If components are designed in a way that requires JS, this excludes thousands of people from using them.

There are ongoing efforts with HTML Modules ( https://www.chromestatus.com/feature/4854408103854080 ) to try to make, among other things, bringing in WebComponents much easier, and Declarative Custom Elements ( https://blog.usejournal.com/w3c-declarative-custom-elements-... ) to make building modules much more HTML-centric & declarative versus today where most of the authoring of a custom element has to be done in JS.

There are very real problems, there is too much js, the js module system is still in a 1/2 complete state on the web, & these very much dog Web Components. But the future is exciting, & 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'm not fully surprised, & I'm delighted that we are spending so long building & experimenting & 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.

I completely agree with the author that WCs fail to push more behaviors into HTML. As she describes, you really want to be able to import the WC's script and then have new useful HTML tags.

I use LitElement pretty extensively, which is a wrapper around WCs, and I like it quite a bit - but it's only a minor improvement in my mind compared to React, and that improvement is just reducing the abstractions from the DOM API. It's still a mega codebase.

I've also tried multiple times to just work with vanilla WCs, and it's sensible only up to a very limited point. If you got a JSX/lit-html module involved it would go further, but at that point it's pretty past "vanilla." And even then, you're not in the realm of "just using HTML."

Author lays a lot of that on the developers having a proclivity for JS, and that may be true, but I've been trying to figure out if this is just complexity in the stack that hasn't yet be solved. UIs are complex, you have lots of stateful interactions between them, and I'm really not sure what the right solution would be for a "do lots via HTML" goal.

Another "big issue" (for me as I develop first on FF) is that Firefox developers refused to implement HTML import. That'd simplify much of using web-components. I include it and the browser can automatically use HTTP2 to load all the components quickly.

It'd be interesting to see how much web-components could be pushed using only CSS via things like the "space toggle" trick (https://github.com/propjockey/css-sweeper). Though I guess that couldn't emit events and the like.

> it suffers from the same oversight every other web component library (polymer, mdl) suffers from:

> - I can't swipe left/right between the tabs

> - I can't pull the menu out from the left by swiping the entire page right

Most native apps don't do either of those two things either... at least on iOS. I can't speak to how Android apps behave these days.

Maybe these are your favorite interaction modes, but it really has nothing to do with whether X is "up to par with native apps."

I'm certain these things could be implemented. Clearly they weren't considered desirable by the authors of Shoelace.

What really holds HTML5 apps back is the fact that Apple consistently drags their heels on adopting push notifications for web. It only has to be available for apps that have been added to the home screen, so all the users who complain about getting nagged for notifications as they browse the web would still be perfectly happy not to be getting nagged. Without notification support, the number of companies who seriously invest in HTML5 apps (instead of native apps) is nearly zero, which really hinders investment in HTML5 frameworks targeting mobile app development (not frameworks just targeting mobile website development).

Clearly, Apple benefits from pushing app developers into the App Store where they can require those developers to give them a cut of the profits.