What about the web components APIs are bad, and how could they be done differently given the reality of the existing platform?
For one, they can stop pretending that JS and the DOM are two completely separate entities, and lock the two working groups in a basement until they figure out a sane way to do reactivity, natively, that actually works.
> figure out a sane way to do reactivity
(100-epsilon)% of developers write websites in a reactive framework, and the reason we have so many of them is because the platform doesn't provide a sane way to do it, so we keep trying again and again with different hacks on top - virtual DOM, proxies, literal JS to JS compilers, whatever some crazy guy happened to come up with last weekend.
That's the problem developers have, and WebComponents don't solve it. They can't. Nothing you do in the DOM can solve it, you need support from the JS side. Thus, lock the two working groups in a basement until they start talking to each other.
All developers want to be able to do is write this:
JS:
let my_stuff = [1,2,3];
HTML (made up template syntax, pick your favorite one)
<ul><li><$for thing in my_stuff><li>$thing</li></$for>
JS again
my_stuff.push(4, 5);
my_stuff.reverse(); // the user now sees 5 4 3 2 1
But if the web components APIs suck, what sucks about them now?
I - like the vast majority of web developers - don't care about WebComponents, as they solve problems I don't have, create new ones that I do have, and don't solve any of the ones I already have.
Slots need to have a host element to select slotted nodes from. ShadowRoot provides that host. Everyone who I've seen say that it's easy comes up with an ambiguous system that doesn't work in many cases and could never be standardized.
Which is a common problem with most "web components suck" takes - they have no sympathy for standards developers or the difficulty of the problem and somehow assume the spec people are dumb or evil, and they don't do the work to show how something could realistically be better.
Stencil.js[0] has a working "proposal" or workaround. Not sure if it is good or bad but at least it seems to work. When you ask users of an API how it could be better they should not be responsible for the implementation. If it can't be done so it is better to not do it in place of having a half working solution that most people decide to not use because it does not work for their use cases.
> they have no sympathy for standards developers or the difficulty of the problem
The problem with the browsers API is a lack of an understanding on how to design good ergonomic APIs for the end user. All the standards developers I talked think shadowDOM is great and people that don't like it are holding it wrong.
In the real DOM you need to know which element from project _from_. The <slot> itself is only half the connection. In a light-DOM only document full of <slot>s you won't know which elements to project where.
> The problem with the browsers API is a lack of an understanding on how to design good ergonomic APIs for the end user.
This could be slightly true, but the statement also misunderstands the role and priorities of standards. When adding new capabilities to first priority is to make something possible at all, and coherent with the rest of the platform. Making a sugary high-level API is often left to libraries at first, and is exactly what libraries like Lit are.
Perhaps it's a naive solution, but I would imagine that much of that could be solved through deferring to component hierarchy and enabling a way to assign things more specifically when defining the components in the CustomElementRegistry. I recognize your username and I realize that you have spent a lot of time thinking about these problems, so I would really appreciate whatever insight you have to offer. Thanks!
There's still a concept of "importing" a template. A host node has slots under it and requests to "import" a template from elsewhere in the document. That import process can adopt the slots then. It's "adoption" rather than "projection" and you "lose" that relation to the source document that "slots stay in the same place", but the DOM has never been static with respect to source documents.