The Failed Promise of Web Components

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.

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

Would it help if we made a standard for communication between web components, so whatever tools they use internally, you can wire them into your code or to each other?

Web components are abstraction boundaries, and you have to define boundaries carefully or you still end up with a big ball of mud, now with extra layers of indirection to make your life even worse.

The important thing about web components is that we _can_ import the component's script and then have new useful HTML tags.

You can drop this on a page and it _just works_:

    <script type="module" src="https://unpkg.com/chessboard-element?module"></script>
    <chess-board></chess-board>

And this is built with LitElement.

Live demo: https://jsbin.com/kicelemara/2/edit?html,output

Having dependencies doesn't change the external interface to an element, or prevent it from being drop-in. Dependencies are very often good, because they are well tested implementations of a common need, rather than ad hoc implementations that may be brittle or duplicative.

We have those standards: properties, attributes, events, children, CSS custom properties and ::part(). It all works quite well already.

Yes, but I'm unsure what a well-designed execution of that would look like.

Yes, thank you. I don't know why "they have dependencies" is a valid criticism. Literally any complex thing where the developer didn't write 100% of the code has dependencies. Most of the dependencies for the web components we use at work are... other web components, which is EXACTLY THE POINT of web components: reusability, portability, encapsulation.

I'll agree with a few of her points, but as far as this point goes, I have to wonder what components she's trying to use here. And if she wants to see the full markup of the shop demo, all she has to do is use "inspect element" on it rather than "view source."