> pretending like they invented FP

More like trying to explain to people who have only done imperative programming (and that also in JS of all languages) why a render function was necessary. The creator of React, Jordan Walke, was big into OCaml and one might even say he got some of the ideas of React through working in OCaml, so much so that he tried to bridge both by making ReasonML which is an alternative syntax for OCaml which has JSX and React bindings.

I don't think React pretended like they've invented FP, and I've always heard them be pretty open about FRP work existing in the past and them leaning on it.

I mean, prior to React the big Framework at the time was AngularJS 1 - a hellscape of two way data binding.

Talking about one-way data flows was an excellent way to speak to a lot of tortured souls at the time (who had just found out they were going to be forced to migrate their projects to something else anyway due to Google's absolutely insane "we're deprecating this, we'll have a replacement for it at... some point, good luck").

> I am one of the people who irreconcilably disagree. I think svelte and solidjs are - obviously - technically superior.

I don't really think that React is necessarily the best possible library, but there is certainly more to a UI library than simply compiling out the need for diffing. For one thing, I find JSX to be a relatively unobtrusive addition to the language. It is implemented by a variety of things and is a pretty simple transform as far as things go; basically pure sugar, it's possible to avoid it if you want. It could be better designed than it is, but I think it's at least sufficiently general - it is feasible to say, use an alternate library with JSX, like Preact.

Svelte on the other hand by its nature just simply requires a more complicated compiler step to work and deliver on its promises. That's a trade-off. Whether you think it's worth it is up to you, but presenting it as an objectively technically superior design is disingenuous. Superior how? Runtime costs? Sure, but it does beg the question how much. Will a well-optimized Svelte app feel much better than a well-optimized React app?

> The amount of hype around it made it really feel like the next big thing.

We are a really long way away from the hype of React. I would argue that hype stopped carrying React a long time ago. Momentum? Sure, but if something was truly dramatically better, then I think it would have a fair shake at beating out React.

The problem is that the web isn't microbenchmarks and developer experience does matter to some degree, so the trade-offs that seem so good on paper don't always pan out.

I'm not a hater of Svelte. On paper, it is a very elegant idea. However, when I actually tried to use it, I genuinely came out feeling that it was simply not for me, and the benefits it has are not enticing enough for me to continue experimenting. My React apps are not particularly slow or bad at handling huge amounts of data. (One of my apps has no problem handling a file grid of over 1 million items, and in fact, I run into issues with browsers not being able to handle a large enough scroll area long before performance of my React code is a problem. That is good enough for me.)

I don't know if that's idiomatic webcomponent or not but that looks unmaintainable, even for such a minimal component, imagine once it grows. It's not separating presentation from state and logic. querySelector need to match classes and elements in the markdown. Mutating textContent is going to run out of sync as soon as you have more than one event source doing the same. Those are all problems that React solve by separating state and only rendering in one path.

That's the best case scenario and already looks like crap. If that looks sane to you, I don't know what to say.

Make it have an initial count via attributes, sync it with the DOM so if the attribute changes the count resets, and make the JS property always match the attribute (and vice-versa) so it behaves sanely. You're in for a world of pain even for something as simple as this.

Plus they're not declarative: you will only make me use innerText-based updates by threatening me and my family.

Plus they only work with JS enabled, while I can use JSX in SSR.

I've worked extensively with Web Components. They suck.

For starters, that it introduces weird special cases to DOM parsing and structure, thereby breaking .isEqualNode whenever <template> elements are present.

Well for one thing, I don't find that to be particularly succinct or nice example. There's a lot going on there:

- HTML in a string. No syntax checks. If you interpolate it, you have to escape manually or you could create trivial XSS vulnerabilities. Your editor will probably not syntax highlight it, making it harder to tell when you break it.

- Manually formatted update logic that is redundant with the string. Not so bad here, but try formulating a practical large component.

- Completely ad-hoc state management, no reconciliation. Again, fine for Hello World, not fine after that.

Using raw WebComponents, your application has to care about all of this on its own and more. You can use templates and slots (which you should) but that makes this even messier IMO and brings back the split that React became famous for getting rid of. We left manual DOM reconciliation, ad-hoc data flow and non-reactive components that manually call a render routine at arbitrary points for a reason: it sucked. It made for buggier, harder to maintain code. It can be done, but usually any decent app will wind up encapsulating patterns into utilities that get reused. And... That's precisely why we want a good library. That's what I want, a library that packages up good reusable patterns for constructing UIs effectively.

And that's exactly my point, which is WebComponents or not, the solution is still basically the same, use libraries. Which begs the question: if I have to use Lit, what is the point of "using the platform"? What is WebComponents doing for me here that React wouldn't be? And in my case, I struggle to see it.

Interoperability? The old way of embedding external components works quite fine. Switching APIs where you pass a DOM node for something to mount into and get back an object with an API to one where you instantiate a component and communicate via properties and events feels like a strictly lateral move. I can't think of a condition where this would be particularly more convenient, but I can think of some where it is actually less. Next.

Isolation? Yes, WebComponents does add tools to provide better isolation between components. For some use cases this is a genuinely useful feature, although it also isn't without tradeoffs (I mean, the flexibility of having things be not isolated comes in clutch sometimes, it's hard to argue this.) But I use React primarily to construct components in an application, where I find this property more undesirable than desirable.

The one thing I thought could be cool with WebComponents is if you could build them in pure HTML when you only needed basic templating, but no: the design they went with always requires subclassing in JS AFAIK.

I could go on and get more specific, but I feel like people will pick everything I just said apart quite enough. I hope I'm at least able to make the case that:

- I do in fact, get the general gist of WebComponents.

- I still don't like it despite that.

Why are your component styles global not encapsulated within the component?

[dead]