This seems to be a pretty low-effort post without any real substantive details.
I'd much rather see discussion of the "Parallel Evolution of React and Web Components" article that got posted earlier today. I don't agree with that author's strong stance against React, but it's at least a well-written post with substantial thought and significant technical detail:
I must be missing something. Could you point me to the section(s) in any of those that make the same point I'm trying to? Or, how many more words do I need to use to say 'Web components don't force you to use Node and don't require a build step'?
Was it? I confess that I initially downvoted them on principle but came back to remove the downvote after reading the article because it did have strong LLM vibes.
There were lots of turns of phrase that didn't feel natural in a technical blog post but are common in ChatGPT's prose. But honestly the bigger red flag for me was the listicle format, with a numbered 6-point outline fleshed out with a few paragraphs per heading and no transitions or relationships of any kind between sections. It felt like something written in chunks and stitched together afterward, which is a common artifact of a ChatGPT workflow (since it produces small chunks of text at a time rather than whole coherent essays).
Here's my quick rebuttal, as someone who likes/uses parts of Web Components but knows it's no panacea. ChatGPT could improve on it I'm sure.
> 1. No Need for Node.js: Keeping Development Simple
You can have code that requires a server or build script with and without web components. You can have code that doesn't require those with and without web components.
> 2. Native Browser Support: No Server-Side Rendering Headaches
This is the point that makes the least sense. You can opt out of server-side rendering when using a non-WC framework, and you lose the headaches. If you don't want server-side rendering and are just glad that Web Components gives you an excuse to not support it, that's silly. If you want server-side rendering, it is possible with Web Components but there's currently a lot more guidance on how to do that with popular non-Web Component frameworks.
> 3. No Compilation Required: Write Once, Run Anywhere
Duplicate of #1. smh
> 4. Universal API, No Lock-In
Does Lock-In just mean including an unencumbered open source library? The API doesn't provide a whole lot. That's why a lot of people are using Lit. When you have Lit, you have some of what is called Lock-In.
> 5. Smaller, Faster, and More Performant
It encourages you to do things that are less performant, maybe only by a little bit, but still. Having a shadow DOM for each item in a large collection means you'd likely have an event handler instead of one that bubbles up. Luckily this is totally optional with Web Components. You can have a Custom Element without a shadow DOM, or you can just create plain elements for items in a large collection and have those bubble up. You can also have your events be composed and they will cross the shadow DOM boundary, though that is tricky in some cases.
> 6. Better Long-Term Maintainability
If you are using a framework (or library), you have to keep up with changes to the framework. If you aren't using one, you may have to do extra maintenance because you're doing something extra that would normally be handled by a framework (or library).
> Conclusion: Embracing the Simplicity of Web Components
Some stuff is simple, some stuff is not.
Edit: I realized that Lock-In could refer to how frameworks try to manage the child elements by default. This can be disabled, and you can have something manage its own child elements. Otherwise you wouldn't be able to use stuff like CodeMirror inside of React. That tends to be done with a ref.
>You can have code that requires a server or build script with and without web components. You can have code that doesn't require those with and without web components.
Believe it or not, there are other server-side languages apart from node. Without Node, you can't SSR in any of those frameworks, so i don't know how that changes my point
>This is the point that makes the least sense. You can opt out of server-side rendering when using a non-WC framework, and you lose the headaches.
But you miss out on performance... without SSR you are bypassing the html parser and just abusing JS to manipulate the DOM.
> Duplicate of #1. smh
If you insist.
> The API doesn't provide a whole lot. That's why a lot of people are using Lit.
Oh no, a js library.
Your other points aren't even worth responding to.
Ah, I see the point about SSR. Yes, frameworks like React and Vue make it less obvious how to do non-framework SSR. However, they don't make it impossible. You can have React and Vue render on an individual element and not the whole document. The HTMLElement part of web components are actually a decent way to do that. You can make a thin wrapper HTMLElement that runs createRoot. https://react.dev/reference/react-dom/client/createRoot
I’m only exploring web components but I like the ability to go smoothly from regular <div> to custom element to element variations depending on attributes to some light JS conditional formatting depending on attributes, also it could be done in open or encapsulated way, then we can do heavier JS and callbacks… and at this point you can still transition to a framework.
Should browsers implement good customizable controls instead all that API? Probably but at this point I would rather have ability to make a good custom drop down with anchored popover API vs limitations of default control.
It's great to see an article not bashing them for once. I love the idea of them not having to compile and the fact they just work in the browser. They aren't without their flaws but I'm hopeful that they'll continue to push through them.
I'm getting older in the world of modern web devs, and I truly can't keep up with all of the frameworks, so I'm hopeful that the core web will eventually win and we won't need all of the "cruft".
Been hearing the case for web components for a very long time. Are there any implemented well? Last I looked at shoelace/web awesome, using a single component brought in 40k+ of JS
Shoelace is excellent, in my experience! Well document, accessible, and a large selection of components. To solve the issue you mention, you can cherry-pick the imports [1], which imports only the specific component you need.
We use them pretty frequently and are even working on releasing our own web component library. I wouldn't recommend using it yet, it needs to be documented better, but here it is if you want to check it out.
The good thing about web components is you don't have to know or care about whatever trendy web framework they're implemented in internally; all that hot garbage is sealed away inside its own individual little ravioli that behaves like anything else in the DOM and can be manipulated with vanilla JS. Fans of various frameworks and methodologies will naturally fume and rant about this sort of "lowest common denominator" treatment, but in a few years the same people may well thank their lucky stars that their new webapps and new shiny frameworks aren't permanently welded to a now distinctly un-trendy implementation strategy hidden within web components they're still using. It's ultimately a feature for protecting the future of the browser from the fads of the present.
This seems to be a pretty low-effort post without any real substantive details.
I'd much rather see discussion of the "Parallel Evolution of React and Web Components" article that got posted earlier today. I don't agree with that author's strong stance against React, but it's at least a well-written post with substantial thought and significant technical detail:
- https://news.ycombinator.com/item?id=41790499
or these other relevant posts:
- https://nolanlawson.com/2024/09/28/web-components-are-okay/
- https://lea.verou.me/blog/2024/wcs-vs-frameworks/
- https://mastodon.social/@molily/113215236512572084
I must be missing something. Could you point me to the section(s) in any of those that make the same point I'm trying to? Or, how many more words do I need to use to say 'Web components don't force you to use Node and don't require a build step'?
Isn't that what people already know about webcomponents? So you'd need to instead write about why that matters?
You can't look up web components on MDN? And if not why it matters, what's my article saying?
It seems like it was written by ChatGPT.
How so?
Was it? I confess that I initially downvoted them on principle but came back to remove the downvote after reading the article because it did have strong LLM vibes.
There were lots of turns of phrase that didn't feel natural in a technical blog post but are common in ChatGPT's prose. But honestly the bigger red flag for me was the listicle format, with a numbered 6-point outline fleshed out with a few paragraphs per heading and no transitions or relationships of any kind between sections. It felt like something written in chunks and stitched together afterward, which is a common artifact of a ChatGPT workflow (since it produces small chunks of text at a time rather than whole coherent essays).
It wasn't and I'm not particularly fond of LLMs, that's just how i write.
Here's my quick rebuttal, as someone who likes/uses parts of Web Components but knows it's no panacea. ChatGPT could improve on it I'm sure.
> 1. No Need for Node.js: Keeping Development Simple
You can have code that requires a server or build script with and without web components. You can have code that doesn't require those with and without web components.
> 2. Native Browser Support: No Server-Side Rendering Headaches
This is the point that makes the least sense. You can opt out of server-side rendering when using a non-WC framework, and you lose the headaches. If you don't want server-side rendering and are just glad that Web Components gives you an excuse to not support it, that's silly. If you want server-side rendering, it is possible with Web Components but there's currently a lot more guidance on how to do that with popular non-Web Component frameworks.
> 3. No Compilation Required: Write Once, Run Anywhere
Duplicate of #1. smh
> 4. Universal API, No Lock-In
Does Lock-In just mean including an unencumbered open source library? The API doesn't provide a whole lot. That's why a lot of people are using Lit. When you have Lit, you have some of what is called Lock-In.
> 5. Smaller, Faster, and More Performant
It encourages you to do things that are less performant, maybe only by a little bit, but still. Having a shadow DOM for each item in a large collection means you'd likely have an event handler instead of one that bubbles up. Luckily this is totally optional with Web Components. You can have a Custom Element without a shadow DOM, or you can just create plain elements for items in a large collection and have those bubble up. You can also have your events be composed and they will cross the shadow DOM boundary, though that is tricky in some cases.
> 6. Better Long-Term Maintainability
If you are using a framework (or library), you have to keep up with changes to the framework. If you aren't using one, you may have to do extra maintenance because you're doing something extra that would normally be handled by a framework (or library).
> Conclusion: Embracing the Simplicity of Web Components
Some stuff is simple, some stuff is not.
Edit: I realized that Lock-In could refer to how frameworks try to manage the child elements by default. This can be disabled, and you can have something manage its own child elements. Otherwise you wouldn't be able to use stuff like CodeMirror inside of React. That tends to be done with a ref.
>You can have code that requires a server or build script with and without web components. You can have code that doesn't require those with and without web components.
Believe it or not, there are other server-side languages apart from node. Without Node, you can't SSR in any of those frameworks, so i don't know how that changes my point
>This is the point that makes the least sense. You can opt out of server-side rendering when using a non-WC framework, and you lose the headaches.
But you miss out on performance... without SSR you are bypassing the html parser and just abusing JS to manipulate the DOM.
> Duplicate of #1. smh
If you insist.
> The API doesn't provide a whole lot. That's why a lot of people are using Lit.
Oh no, a js library.
Your other points aren't even worth responding to.
Ah, I see the point about SSR. Yes, frameworks like React and Vue make it less obvious how to do non-framework SSR. However, they don't make it impossible. You can have React and Vue render on an individual element and not the whole document. The HTMLElement part of web components are actually a decent way to do that. You can make a thin wrapper HTMLElement that runs createRoot. https://react.dev/reference/react-dom/client/createRoot
Do you know what SSR is?
I’m only exploring web components but I like the ability to go smoothly from regular <div> to custom element to element variations depending on attributes to some light JS conditional formatting depending on attributes, also it could be done in open or encapsulated way, then we can do heavier JS and callbacks… and at this point you can still transition to a framework.
Should browsers implement good customizable controls instead all that API? Probably but at this point I would rather have ability to make a good custom drop down with anchored popover API vs limitations of default control.
It's great to see an article not bashing them for once. I love the idea of them not having to compile and the fact they just work in the browser. They aren't without their flaws but I'm hopeful that they'll continue to push through them.
I'm getting older in the world of modern web devs, and I truly can't keep up with all of the frameworks, so I'm hopeful that the core web will eventually win and we won't need all of the "cruft".
Been hearing the case for web components for a very long time. Are there any implemented well? Last I looked at shoelace/web awesome, using a single component brought in 40k+ of JS
Shoelace is excellent, in my experience! Well document, accessible, and a large selection of components. To solve the issue you mention, you can cherry-pick the imports [1], which imports only the specific component you need.
[1]: https://shoelace.style/getting-started/installation#cherry-p...
We use them pretty frequently and are even working on releasing our own web component library. I wouldn't recommend using it yet, it needs to be documented better, but here it is if you want to check it out.
https://github.com/outerbase/astra-ui
Just checked it out. The example in your readme doesn't work (script src is wrong). Also, it loads 250k of JS for a single button :(
The good thing about web components is you don't have to know or care about whatever trendy web framework they're implemented in internally; all that hot garbage is sealed away inside its own individual little ravioli that behaves like anything else in the DOM and can be manipulated with vanilla JS. Fans of various frameworks and methodologies will naturally fume and rant about this sort of "lowest common denominator" treatment, but in a few years the same people may well thank their lucky stars that their new webapps and new shiny frameworks aren't permanently welded to a now distinctly un-trendy implementation strategy hidden within web components they're still using. It's ultimately a feature for protecting the future of the browser from the fads of the present.
Is there any platform where people don't conventionally use frameworks/UI toolkits on top?
The web, arguably the most poorly designed UI target, thinks it can do without. Delusional!