The Failed Promise of Web Components

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.

The web components under the hood would still need a way to program themselves in response to that data, so a templating language would need to be baked in along with data binding.

Secondary languages are a bad idea, so hopefully this templating language would be something like jsx/ejs.

The proposal really is to bake applications support in to the browser. That seems right to me. The browser is more and more an os, and it should support rich applications out of the box.

React is derivative of windows application development, so there is precedent for something like it to be baked in to an OS.

Lit-HTML is a templating system that's baked into Lit-Element, which is basically the successor to the Polymer framework. It simply uses JS template strings, with a few little niceties in the binding syntax to allow for things like setting properties rather than attributes, adding/removing boolean attributes, and defining event handlers inline. It lacks two-way data binding, but we use "data" elements as a centralized data store. That store provides a master state object that's passed down to every component on the page - though frequently it's just a sub-tree of state that gets passed down. If a component receives some input and needs to update its state, it fires off an event with the updated value, which has a corresponding handler in the data element. That handler taps into a functional pipeline we've built to handle function composition, passes the information down the appropriate pipeline, and the master state is updated appropriately. At that point the data element fires a "state-changed" even that basically everything listens for, and whoever cares can then update their own little bit of state from the master store (typically one line of code).