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

▲

MrJohz 2 hours ago | parent | next [-]

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.

▲

WA 6 hours ago | parent | prev [-]

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 2 hours ago | parent [-]

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.

	▲	MrJohz 2 hours ago \| parent [-]
		Lit is a framework, that's the whole point of it. Lit is a framework that happens to generate web components, but the goal of Lit is to provide the rendering and state management necessary to actually write those components. That's the framework bit. If you take a Lit-based web component and rip Lit out, you have dead code that won't work because it's dependent on a framework that you have removed. You could take a Lit-based web component and replace it with a non-Lit-based web component and that would be fine, because Lit uses web components as its core interface, but Lit itself is still a framework.