[nine_k]

React (and the unidirectional FRP approach in general) is the only known sane way to describe complex GUIs. It's the same approach that powers spreadsheet calculations.

Most websites are not complex GUIs though, and do not need React.

[wizzwizz4]

It's not "the only known sane way". In many cases, it's not even an appropriate approach! MVC, PAC, and self-contained widgets which make asynchronous calls to an API surface, are perfectly cromulent alternatives, each with their own strengths, but I've yet to see a situation where React was actually the best way to go.

[killerstorm]

React is very different from dataflow computation - it rebuilds a component subtree upon a property update; it also doesn't quite understand what "property update" means because it's defined on top of JS semantics. It's a hodgepodge of leaky abstractions and outright insanity.

I've been making GUIs (among other things) for 25 years, including 12 years using React, so you don't need to tell me how amazing it is. There's nothing particularly wrong with using React for rendering (although there's a whole lot of gotchas), the real problem is when people use React hooks for business logic - that's like you decide you need to fetch something in a middle of rendering screen.