[doradoblank]

Web components are neat but they don't solve the problem React solves. React provides a simple mental model for managing client state, which is the one of the main challenges in frontend. It's basically, "re-render everything when one of your dependencies changes" -- and that's extremely easy to understand and reason about. It incurs significant performance overhead, but your app has to be fairly large before you start running into meaningful perf issues.

[ramraj07]

An outsiders perspective: react LOOKS like a simple mental model because all the front-end folks got used to it. Its not simple, its not intuitive, and this fact fundamentally makes it a bad framework: mediocre engineers often end up using it wrong because of this.

I've had an easier time learning Vue than React, and I've probably spent much longer trying to learn react. And if im not wrong, AI writes better Vue code than react code as well.

[skydhash]

React is simple. When you really think about your data model, you’ll find out that you only need a handful of global properties, and the rest is data derivation and integration to your API or your storage layer.

Most issues stem from developers refusing to read the docs and to plan their presentation layer.

[socalgal2]

I agree with some of this. I find react unintuitive. I find it infrutating how many hoops I have to jump through to get things done in react. In the past, I've only looked at UI as a thing I tack on after writing the core functionality. So I go write the core functionality. Then I try to add a react UI on top. Suddently it requires me to re-write my entire core because it wants control of all state. No other UI system I've used does this.

[skydhash]

If what you wrote is truly a core, you’ll only need to write a few functions to translate it to the reactive pattern. You already know the state of your core and the events that drive its transition, matching it to React’s is often pretty straightforward.

[ggregoire]

> mediocre engineers often end up using it wrong

Might be because mediocre engineers don't read the docs.

[claytongulick]

My style with web components solves it really well.

Just have each component maintain it's own state. Class setters work great. If you need the component to update, just call render() in the setter.

It's super simple, encapsulates logic, and brain-dead simple to debug. You know exactly where to go for everything: the component.

I've always felt like react's approach to state management was creating more problems than it solves.

[doradoblank]

How do you handle state that affects multiple components? Like a filter button that affects a list table. In React you just hoist the state up and make both components dependent. If you're managing all state via internal component state, then you need to explicitly pass state between the components. That's okay for simple cases, but in my experience it breaks down pretty quickly. Once you have more than a few components involved, you end up writing your own state reconciliation.

[claytongulick]

There are a few different ways.

One really easy way is to put a custom element at the root of the dom and just add/remove event listeners, maybe one-shot if that's all you need.

I also have a convenient little library called ApplicationState [1], which basically does the same thing but can persist state in indexdb.

Lots of other libraries out there too.

[1] https://claytongulick.github.io/applicationstate/

[gitaarik]

That's why I wrote Lit State, a simple state management lib to use in combination with Lit, a simple web components lib. It works really simple, and it's simple to use. Much more intuitive than React.

https://github.com/gitaarik/lit-state