undefined | Better HN

0 pointsWA6mo ago0 comments

Web components are an implementation detail. They don't bring anything framework-like to the table. The most important being: reactivity. You have to write DOM manipulations imperatively like you did 15 years ago with jQuery. If you don't want that, you gotta bring a wrapper or another reactivity library/framework.

For many use cases, there's not much difference between writing a Web component or an IIFE (Immediately Invoked Function Expression) that attaches your JS functionality to a div somewhere like we wrote JS without jQuery 15 years ago, although Web components are more elegant. But still, they are mostly packaging.

I say this as someone who likes Web components and who created several ones that are used in production. But just yesterday, when I added a new attribute to one of my Web components and wondered for a moment why the new attribute wouldn't get rendered, I realized that I forgot to add the code that imperatively tells the DOM how to update itself. Which is okay, because this is just a small component and it's pretty lightweight. I'd never use a framework for stuff that can be achieved without much effort in vanilla JS.

My point is: selling Web components as a way out of this trap is disingenuous. They don't offer anything at all that is important for modern frontend dev.

0 comments

nikitaga6mo ago

> If you don't want that, you gotta bring a wrapper or another reactivity library/framework.

Being able to use a different library with a component, instead of the component being tied to React, is the whole point.

React isn't 100x more popular because its reactivity system or any other feature is 100x better. Half the reason it's popular is network effects – too many frontend components / libraries are made React-only even though they don't need to be React-specific.

Those network effects are the trap, not the reactivity system that's as good as any other for the purpose of writing a Web Component. If you don't want to use simple and small tools like Lit.js, that's fine, but that's your choice, not a limitation of Web Components.

The point of Web Components is not to provide a blessed state management or virtual DOM implementation that will have to stay in JS stdlib forever, it's to make the components you author compatible with most / all UI libraries. For that goal, I don't know of a better solution.

WAOP6mo ago

I get your point. I'm fully with you that it makes no sense to use React and write React apps if you can achieve the same without React. I hate the fact that many great frontend components only work with React, especially considering that React didn't properly support Web components for ages, whereas almost every other framework had no problems with them.

However, out of the box, Web components don't come with almost anything. Comparing React to Web components is comparing apples to oranges.

Lit is great, but Lit is a framework. Now you're comparing React with Lit. Different story than React vs. vanilla Web components.

spankalee6mo ago

Lit is not a framework. Lit only helps you make standard web components that you can use anywhere *because they are web components*.

You could take a Lit-based web components a rip Lit out and you would still have the same component that you can still use anywhere. Lit is just an implementation detail.

1 more reply

nikitaga6mo ago

> Comparing React to Web components is comparing apples to oranges.

I mean, yes, but you're the one making this comparison, saying that WCs lack reactivity etc.

Web Components are an extension of the DOM – a low level browser API. They are similarly low level. That's expected. I don't need or expect them to be something more.

I am happy that I can use any reactivity system I want to implement a Web Component. That's a feature, not a bug. Having implemented a reactivity system myself, I know that there isn't a perfect one, the design is full of tradeoffs, and I'd rather not have a blessed implementation in the browser, because it will inevitably turn out to be flawed, yet we won't be able to retire it because "we can't break the web". A blessed implementation like that would benefit from network effects just like React does, and would have all the same problems as React, plus the inability to rapidly innovate due to the browser's unique backwards compatibility concerns. I'd rather ship an extra 3KB and avoid all those problems.

1 more reply

MrJohz6mo ago

Except the problem with compatibility is almost always the reactivity element, right? Getting, say, Vue's reactivity system to compose properly with Svelte's, or React's with Angular's. And that's not going to work well when Vue is using signals to decide when to rerender a component, React is using its props and state, and Svelte isn't even rerendering components in the first place.

This is especially difficult when you start running into complicated issues like render props in JSX-based frameworks, context for passing state deeply into a component, or slots/children that mean reactivity needs to be threaded through different frameworks.

degun6mo ago

The offer a way to build custom components that you can use everywhere, on every frontend framework, or plain html page. That's something that can't be achieved with any other tool. Also, if you use the Lit framework to build web components, @property and @state are reactive. The DOM part that uses those variables updates by itself.

spankalee6mo ago

Web components are the opposite of what you say: they are the component interface and specifically not the implementation. You can implement them however you want.

What they offer is interoperability and the ability to use components outside of a framework or with a framework.

And that's why they help solve the ecosystem trap.

j / k navigate · click thread line to collapse

0 pointsWA6mo ago0 comments

My point is: selling Web components as a way out of this trap is disingenuous. They don't offer anything at all that is important for modern frontend dev.

0 comments

nikitaga6mo ago

> If you don't want that, you gotta bring a wrapper or another reactivity library/framework.

Being able to use a different library with a component, instead of the component being tied to React, is the whole point.

WAOP6mo ago

However, out of the box, Web components don't come with almost anything. Comparing React to Web components is comparing apples to oranges.

Lit is great, but Lit is a framework. Now you're comparing React with Lit. Different story than React vs. vanilla Web components.

spankalee6mo ago

Lit is not a framework. Lit only helps you make standard web components that you can use anywhere *because they are web components*.

You could take a Lit-based web components a rip Lit out and you would still have the same component that you can still use anywhere. Lit is just an implementation detail.

1 more reply

nikitaga6mo ago

> Comparing React to Web components is comparing apples to oranges.

I mean, yes, but you're the one making this comparison, saying that WCs lack reactivity etc.

Web Components are an extension of the DOM – a low level browser API. They are similarly low level. That's expected. I don't need or expect them to be something more.

1 more reply

MrJohz6mo ago

degun6mo ago

spankalee6mo ago

Web components are the opposite of what you say: they are the component interface and specifically not the implementation. You can implement them however you want.

What they offer is interoperability and the ability to use components outside of a framework or with a framework.

And that's why they help solve the ecosystem trap.

j / k navigate · click thread line to collapse