For me, a big draw of web components is that there's no `npm install` needed. I prefer to ship my components as plain JS files that can either be hot linked from a CDN or downloaded and served locally. Call me paranoid but I just don't fully trust node modules to be clean of bloat and spyware and I just don't want to have to regularly deal with updating them. I'd prefer to download a web component's static JS file a single time, read through it, and forget it. Maybe down the line I might revisit the source for the component as part of standard maintenance.
For example, I made a simple like button component[1]. Later, my friend made a cool component for showing a burst of emoji confetti[2]. I decided to optionally pull it in if an attribute was set on the like component. I downloaded his source and hosted from my own domain. However, there was actually a bug in his code that caused the confetti to "rain" if you spammed the like button a few times quickly. He fixed that, but I actually kind of liked it so I just didn't update the source for the confetti component.
[1]: https://catskull.net/likes [2]: https://github.com/samwarnick/confetti-drop
I just built a script tag based reusable library for our company with react as the only dependency and thanks to stuff like shadow Dom and dialogs I get a much higher quality dev experience than plain js.
My bigger problem with React is that it ends up being used as a form of vendor lock in. Once your entire page is in the React VDOM it’s very, very difficult to pivot to a different framework piece by piece. That’s a core strength of web components.
In the parent comment's case of not having other dependencies, whatever the React ecosystem does isn't relevant if you aren't using any React libraries, which aren't really necessary anyways, especially nowadays when the LLM can reimplement what you need for you.
Nothing has changed about react-dom that prevents you from using React piece by piece—its docs still recommend attaching to a #root node even for single page apps.
Including web components in a React app is very seamless, and embedding non-React-controlled elements inside React is not uncommon (e.g. canvas, Monaco, maps), though for common use cases there's usually convenience libraries for React that wrap around these.
React DOM/views have not significantly changed in 12 years.
Our 10 year React projects that used mobx have not changed very much.
Savage take: I found React when it came out and I thought “wow you made this gorgeous DOM library and then you bolted on this messy ugly wart for state.” Then hooks came out and I’m like… this is a good electrician pretending they can also do plumbing.
To be clear, it's not 100% react. It's the entire ecosystem around it. Want to take wigdet-x v3 for bug fixes. It requires newer react, which may or may not be compatible with widget-z I'm using. Newer react requires newer tools which aren't compatible with the configuration that was created by create-react-app from 2 versions ago. etc...
That's what AI is for. It makes previously unfeasible projects feasible again
If you have a complex app from 2019 that you haven't updated, it is virtually guaranteed that it has memory leaks and bugs.
That could explain why the percentage slider is not showing a current value tooltip when sliding it :P
> We currently use Lit for the framework on top
These two are contradictory statements.
1. lit is both newer than React, and started as a fully backwards incompatible alternative to Polymer
2. Despite being acrively promoted as "not a framework just a lib" it's rapidly sucking in all the features from "fast moving js": from custom proprietary syntax incompatible with anything to contexts, a compiler, "rules of hooks" (aka custom per-dieective rules) etc.
> We're currently on material components and migrating some to Shoelace.
Again, this is exactly the "fast js churn" you're talking about.
Not lit.
Stop pretending this isn't the case
Lit helps you write web components.
Those web components are interoperable with other web components made with Polymer, Stencil, FAST, etc...