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.

▲

nikitaga 6 hours ago | parent | next [-]

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

▲

spankalee 2 hours ago | parent | prev | next [-]

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.

▲

degun 6 hours ago | parent | prev [-]

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.