Agreed, Web Components don't require any framework and you can achieve everything you can achieve with React (including reactivity via attributeChangedCallback), the learning curve for Web Components is actually much less steep than React when you consider from the perspective of someone starting from scratch.

Furthermore, Web Components enforce good patterns; like the fact that you can only pass strings as attributes (by-value) is actually genius as it encourages simple, minimalist component interfaces and avoids pass-by-reference issues for which React community had to invent an entirely new paradigm to protect against (I.e. Redux state management with functional programming approach).

And the great irony is that a lot of the top people who are still pushing React are basically rich from Facebook shares and don't have to work anymore. In effect many of them are forcing this technology onto young people who have no choice in the matter whilst they themselves don't need to use it or do any coding anymore. Meanwhile I know a lot of developers who want to leave (or have left) the industry because of how bad it is and how few decisions they're allowed to make.

It's demoralizing to work with inferior tools when you know better tools exist because you use them in side projects... When you see this, you think to yourself "If the company forces me to be inefficient with my choice of tooling, this gives me a license to be inefficient in other ways."

Personally, I don't even code anymore (only on my side projects). It's a shame because one of my main talents is writing clean, minimalist code. In my day job, I'm using drag-and-drop UI platforms like n8n and Flowise (for AI). It's refreshing to be able to use vanilla JS inside the nodes, without a compile step and on a real-world project that actually pays. These UI platforms are actually much more predictable to work with than React. When I was using React (for almost a decade), I was constantly debugging weird glitches and state management issues; I never encountered those with Web Components or with platforms like n8n.

▲

spankalee 19 hours ago | parent [-]

> the fact that you can only pass strings as attributes

This isn't true at all though. It's a lie started in the early days by React engineers that just won't die, unfortunately.

Web components are objects and they can have properties and accessors like any object. The vast majority of declarative template systems like React, Lit, Vue, Angular, Svelte, Solid, etc., will declaratively set properties - which can carry any type of JavaScript value, including complex objects and function - on web components which can then be used to update the component's DOM.

▲

_heimdall 16 hours ago | parent | next [-]

That approach passes values in JS rather than the DOM, right? I read the go comment as talking specifically about DOM attributes which can only be strings (well, you can have boolean attributes as well).

Web components can be passed objects in JS, but its news to me if that is available in HTML.

▲

bythreads 15 hours ago | parent | next [-]

Neither can react

	▲	_heimdall 14 hours ago \| parent [-]
		I didn't say it can, I never actually mentioned react at all here.

▲

moron4hire 12 hours ago | parent | prev [-]

I generally think the reflex to try to pass an object to an attribute on an element is a code-smell that the element hasn't been properly decomposed into sub-components. In those cases, I look more to adding child elements to represent those objects as an HTML serialization of the object.

▲

sporritt 13 hours ago | parent | prev [-]

It is true that web components can have properties and accessors like any object. But what you cant do is pass anything other than a string to a web component's attributes in the markup. I wrote a short article about this when I was investigating web components with JsPlumb a while ago:

https://jsplumbtoolkit.com/blog/2024/07/18/wrapping-data-in-...

TL;DR I ended up creating a context object and a BaseComponent that can access the context. Subclasses of the base component prefix their attributes with a colon to instruct the code to look in the context:

<date-label :value="now"></date-label>

	▲	moron4hire 13 hours ago \| parent [-]
		I think you might be missing out on the standard Time element in HTML5. In use, you set its datetime attribute to a machine-readable format and set its body to the user-readable format. Also, I tend to think of HTML not as my application view, but as a document that represents a serialization of your view. The actual, live view itself is the DOM. Once that document is parsed and rendered, the HTML source from whence it came doesn't matter anymore. Stringly attributes should no longer be a concern. Though, admittedly, the HTMLTimeElement's dateTime property is still a string value. I imagine that is more of a legacy issue. The Date class in JavaScript is a mess as well.