Dimitri Glazkov

(Disclaimer: author and editor of the modern custom elements spec here.)

The specific "failed promise" that I see is largely this positioning of web components vs. frameworks.

How web components was originally envisioned was as leaf-node or light-DOM-using components, of the sort HTML already has. For example, <dialog>, <details>, <input type=range>, etc. Web components was supposed to give you the tools to create your own components of this sort, such as <tabpanel->, <toast->, <carousel->, <switch->, etc. In particular:

* Custom elements gives you the ability to just drop in tags, like you do with vanilla HTML, and those tags can react to lifecycle events like being added/moved/attributes changed, automatically. The browser mediates between those occurrences and the web component's code.

* Shadow DOM lets you encapsulate the inner details of your component, while using slots to reproject content into it. So e.g. <switch-> could have its innards entirely in shadow DOM, just like <input type=range>. While <tabpanel-> would be given children by the web developer using it, with some of those children being special (like <summary> is special for <details>), but some parts hidden in the shadow DOM and not provided by the web developer (like the disclosure triangle and behavior for <details>). More on this in https://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/

From this perspective, the lack of data-binding (cited in a sibling thread) is not a big deal. There's no…

There has been a good deal of talk over the years of making form controls stylable[1]; a few, like buttons, already are, and WebKit has some vendor-specific extensions for things like scrollbars[2]. But it will take quite a bit of work to hash out standards, and a lot of implementation work in all of the major browsers to get it there. The WebKit scrollbars use a whole bunch of pseudo-elements and pseudo-classes, but there's also a possibility that the functionality for reaching inside controls and interacting with their individual parts may be exposed through a shadow DOM[3].

As mentioned in the shadow DOM post, there's a lot of work needed to be done discussing, standardizing, and implementing these features. I'd encourage people interested to get involved on www-style and public-webapps at the W3C, and the WHATWG mailing list (avoid public-html at the W3C, it appears to be purely political at this point), or get involved in one of the open-source browser engines implementing experimental versions of this stuff to give a starting point for discussion.

[1]: http://goo.gl/i1eL9
[2]: http://www.webkit.org/blog/363/styling-scrollbars/
[3]: http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/

Adapton is definitely an inspiration, and I have cited it in previous iterations (and even had it in an earlier draft - if you check the Markdown source, the link def is still there).

Here's my current thinking on the topic. It all depends on whether you want to model your problem as a tree or a graph (see also [1] for some great discussion of that tension). If you model your problem as a graph, then a general purpose incremental computation engine like Adapton (or Incremental or Salsa) is great. However, if your problem is a tree, then constructing the explicit dependency graph requires a nontrivial amount of ceremony. What Xilem does is represent the most common tree-structured flows of information in a very lightweight manner (mostly just plain code that builds views), while allowing you to insert arbitrary graph edges if you like with more work.

I think it's a discussion worth continuing. One thing you could do is integrate Adapton and Xilem together, where the implementation of most view nodes in the latter becomes queries into the Adapton engine. How well would that work? Really only one way to find out.

[1]: https://glazkov.com/2022/02/06/tension-between-graphs-and-trees/

The DOM is indeed too low-level. We need higher-level components, and the ability to develop custom components. We also need a way to firewall segments of a page, so we can reason about it at a higher level of abstraction. This technology is coming, it's called shadow dom ( http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/ ).

I've been developing a 100.000 line single page javascript app for the past few years. You can't build an app like that if you code at the level of dom elements. Encapsulation and abstraction is essential. Because the shadow dom didn't exist i used extjs as a crude alternative (extjs's component framework is really nice, but the dom structure it produces is ugly). However, with shadow dom I can imagine a way of writing javascript in the large without needing the heavy abstraction layer that extjs provides.

I don’t think cascading is necessarily a problem; rather, HTML/CSS lacks good encapsulation features. Actually, this has been well-recognized by browser vendors, who want to use HTML and CSS to implement things like HTML5 video player UIs, but don’t want the styles of the page itself to interfere with the video player. They’ve implemented a rather intricate system called the "shadow DOM" to manage this. (This page explains it decently well: http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/)

We'd like CSS to grow up, and decide it wants to be a proper programming languages, with all the abstraction and encapsulation facilities we'd come to expect. Until then, I guess there is this language called JavaScript...

You use a JavaScript polyfill which handles browsers which don't yet support them. For example, I recently launched a project using <input type=range> with a [modernizr.load](http://modernizr.com/docs/#load) test which uses
https://github.com/freqdec/fd-slider if the browser doesn't have native support.

As for styling the native controls, I generally recommend thinking twice about that as the usability benefits of having a familiar standard control are significant but you should read up on the Shadow DOM and the emerging CSS support for it: http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom&#x2F;