For one thing, I just genuinely think WebComponents are a badly designed API that is weird and hard to use (how many people are using WebComponents without at least Lit, if not something much bigger?), and React is a relatively well-designed library that isn't really that bloated. There's not really much of a point in trying to argue since this is inherently subjective and people with different values are going to irreconcilably disagree. But, if you don't respect that some people hold this position, we're not going to make any progress towards a consensus.
On the note of <dialog>, I recently tried to use <dialog> in a (React) application, and it did work pretty well, but I also found that in Firefox it is only practically possible to do a fade-in animation, not a fade-out one. That isn't really a critical issue for me, it is just an animation after all, but I find it unfortunate. I also find <dialog> to be a weirdly shaped API too: I don't really hate it, but I don't love it either. It feels awkward.
I find this implicit view that developers that, for example, prefer React over WebComponents are making a suboptimal choice to be rather condescending and not really in the spirit of trying to see things from the other side. Wouldn't you want to focus on the strongest arguments and not the weakest ones? Maybe you've literally never heard anyone complain about WebComponents or Shadow DOM, but if so, I find that surprising. Certainly here on HN, I've seen a fair bit of WebComponents hate.
I do, FWIW, realize that I've particularly focused on WebComponents, which this article doesn't actually name directly. But, I assume we're not talking about ditching React to implement our own component framework on top of the traditional DOM APIs, because that's what React already does...
The current state of the platform has even been a blocker to standards folk when they want to add a shiny new thing, thus the absurd bloat of the specs.
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.
Nitpicking specifics misses the elephant in the room:
> 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
A giant update that forces everyone to change to drop their workflow, but doesn't solve this was bound to be dismissed oturight.
How would you solve that? To this day I've never seen a workable proposal.
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.
> How would you solve that? To this day I've never seen a workable proposal.
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.
Stencil's is _not_ a workable platform solution. Stencil is emulating something close to slots _above_ the DOM. Stencil knows the host tree form Stencil's own component definitions, then it flattens before it gets to the DOM. This is basically just what React and every other framework does, just copying the browsers terminology. It's not compatible with anything but Stencil.
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.
I'm not GP, but I would love to understand this issue in more detail. Do you happen to have a good link for me to read about what has been tried and why it failed?
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!
I don't think that standards did anything wrong or incompetent, but with hindsight considering all the complexities they bring i am hot sure they have been worth it
jchw · · focus · HN ↗
On the note of <dialog>, I recently tried to use <dialog> in a (React) application, and it did work pretty well, but I also found that in Firefox it is only practically possible to do a fade-in animation, not a fade-out one. That isn't really a critical issue for me, it is just an animation after all, but I find it unfortunate. I also find <dialog> to be a weirdly shaped API too: I don't really hate it, but I don't love it either. It feels awkward.
I find this implicit view that developers that, for example, prefer React over WebComponents are making a suboptimal choice to be rather condescending and not really in the spirit of trying to see things from the other side. Wouldn't you want to focus on the strongest arguments and not the weakest ones? Maybe you've literally never heard anyone complain about WebComponents or Shadow DOM, but if so, I find that surprising. Certainly here on HN, I've seen a fair bit of WebComponents hate.
I do, FWIW, realize that I've particularly focused on WebComponents, which this article doesn't actually name directly. But, I assume we're not talking about ditching React to implement our own component framework on top of the traditional DOM APIs, because that's what React already does...
spankalee · · focus · HN ↗
nananana9 · · focus · HN ↗
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.
spankalee · · focus · HN ↗
nananana9 · · focus · HN ↗
> 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:
A giant update that forces everyone to change to drop their workflow, but doesn't solve this was bound to be dismissed oturight.brazukadev · · focus · HN ↗
spankalee · · focus · HN ↗
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.
brazukadev · · focus · HN ↗
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.
0. <a href="https://stenciljs.com/docs/templating-jsx#slots" rel="nofollow">https://stenciljs.com/docs/templating-jsx#slots
spankalee · · focus · HN ↗
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.
jazzypants · · focus · HN ↗
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!
afiori · · focus · HN ↗