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...
It’s surprising how bad the API is. Shadow DOM makes just about everything worse. Our frontend org opted out of even using Lit, so we get the raw stupidity of the whole idea.
Style encapsulation? You get that, but not fully, and good luck finding out which parts you don’t get.
State management? Back to query selectors, which btw work worse and need workarounds when reaching into the shadows. We went with DOM-as-state. I don’t want to talk about it.
Slots? After coming from a modern framework, slots are a clear step backwards. In React you can pass a component as a prop but in the shadow DOM world, you have to signify it with HTML. Multiply it by several slots and you get a lot of verbosity just to match the behavior.
Yet to mention using the platform directly means losing so much work around static verifiability. No one has to talk about this anymore, but sticking religiously to the platform by strictly using addEventListener means you can’t require event handlers to exist for any of your elements. People forget this, but the browser’s default way of letting you do anything is an enormous footgun for reliability.
Learn from our frontend org’s mistakes. Run, don’t walk, away from 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...
compacct27 · · focus · HN ↗
Style encapsulation? You get that, but not fully, and good luck finding out which parts you don’t get.
State management? Back to query selectors, which btw work worse and need workarounds when reaching into the shadows. We went with DOM-as-state. I don’t want to talk about it.
Slots? After coming from a modern framework, slots are a clear step backwards. In React you can pass a component as a prop but in the shadow DOM world, you have to signify it with HTML. Multiply it by several slots and you get a lot of verbosity just to match the behavior.
Yet to mention using the platform directly means losing so much work around static verifiability. No one has to talk about this anymore, but sticking religiously to the platform by strictly using addEventListener means you can’t require event handlers to exist for any of your elements. People forget this, but the browser’s default way of letting you do anything is an enormous footgun for reliability.
Learn from our frontend org’s mistakes. Run, don’t walk, away from it.