The Case for Web Components: A Simpler, Framework-Free Future for the Web
1–10 of 23 posts
Re: The Case for Web Components: A Simpler, Framework-Free Future for the Web
#2This 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/
Re: The Case for Web Components: A Simpler, Framework-Free Future for the Web
#3Been 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
Re: The Case for Web Components: A Simpler, Framework-Free Future for the Web
#4It'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".
Re: The Case for Web Components: A Simpler, Framework-Free Future for the Web
#5Is 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!
Re: The Case for Web Components: A Simpler, Framework-Free Future for the Web
#6Been 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
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.
Re: The Case for Web Components: A Simpler, Framework-Free Future for the Web
#7I’m only exploring web components but I like the ability to go smoothly from regular 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.
Re: The Case for Web Components: A Simpler, Framework-Free Future for the Web
#8This 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 thes…
It seems like it was written by ChatGPT.
Re: The Case for Web Components: A Simpler, Framework-Free Future for the Web
#9This 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 thes…
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'?
Re: The Case for Web Components: A Simpler, Framework-Free Future for the Web
#10This 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 thes…
It seems like it was written by ChatGPT.
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.