[nikitaga]

> 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.

[WA]

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.

[spankalee]

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.

[nikitaga]

> 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.

[MrJohz]

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.