The Failed Promise of Web Components

My impression is that JS has led WCs for the simple fact that JS is easier to polyfill/prollyfill/ponyfill and there's a lot more infrastructure today for JS modules and JS bundling. Web Components have been a lot of trying to assemble the cart behind you while riding the (JS) horse, simply because web standards are so slow. (I'm not sure if that analogy entirely works, though in my head it adds the unsightly picture that at least some of the material you have to build the cart with is manure, and WCs being built more than partly from JS manure does sound accurate.)

ES2015 modules are about at the point that caniuse statistics show them as nearly viable for production work, with HTTP/2 (or 3) deployment being possibly the last puzzle piece for a global lessened reliance on bundling for performance reasons. (Though not for simplicity of usage reasons: it's still useful to be able to drop an entire third party bundle all at once on a file host and use the thing as a single import.)

Meanwhile, CSS Modules are still something prollyfilled by JS bundlers and there still isn't an official spec yet?! And "HTML Modules" is so barely on the drawing board that it would be optimistic to call what JS bundlers are doing there as anything resembling a "prollyfill" (we're to "wishfill", I guess?). (And most JS WCs are using virtual DOMs or JS-native template tools instead of HTML templates anyway.)

I love her description of using a dependency-laden component:

> 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”. Many steps are even omitted, likely because they are “obvious”. Often, you wade through the maze only to find the component doesn’t work anymore, or is not fit for your purpose.

That is so true. The "unapologetically" thing is important. I see this all the time. There's often a fair bit of 'tude, where I am looked at with condescension, for not knowing something "obvious."

The fig tree pic is perfect.

EDIT: Removed phrase that was possibly corrosive to the narrative.

They are a common standard for building web apps.

Dart itself hasn't kept up with web standards in general, but that's another story.

caniuse statistics say that ES2015 module support has reached something like 92% of browsers:

https://caniuse.com/es6-module

This post is needlessly snarky, but I don't disagree with the basic premise.

Here's what killed web components: lack of native databinding on the web. That's the reason the standard is useless without JS. Any modular, dynamic, modern UI requires databinding, which means it's going to bring in a framework anyway, which means that self-contained widgets are all going to bring in their own frameworks, which means that instead of one large framework on the page you have five or six, all of them stitched together through rickety HTML-attribute APIs and custom value-parsing strategies because HTML attributes are just strings.

I fail to grasp why databinding hasn't made it into a web standard yet. The web has a long tradition of feeling out features in the JS world before adopting the successful ones into the platform. jQuery turned into querySelector() and fetch(), CommonJS modules blazed the trail that led to ES modules, etc. And this next paradigm is more than ready to get standardized. Not only would it make the dream of web components possible, it would eliminate the need for a whole lot of the JavaScript out there and even make UIs faster, since reactivity logic would be implemented natively.

It's such an obvious, ubiquitous improvement to the web that I can only assume there's some fundamental implementation roadblock I'm missing.