Having seen some large react codebases I’d agree wholeheartedly with this article.
React solves problems we don’t have any more (eg IE), badly, at the cost of poor performance, lock-in and a host of other problems that other solutions just don’t have.
It means downloading MBs of javascript just to render a simple page.
It encourages multiple loads of massive json payloads for bits of the page which are then translated into html; this is a huge complexity and network tax for no gain.
It encourages constant re-rendering of page components.
It encourages mixing code and layout, making it incredibly easy for junior developers to make a terrible mess.
It encourages splitting web pages into thousands of components with poorly defined boundaries and putting lots of logic on the front end - this is disastrous for productivity and clarity when the project is of any size.
It has a bunch of legacy bits (double rendering, useEffect, useMemo, shadow dom etc) which just aren’t required and are often solutions to problems react itself created.
As to a prescription for what to use instead of react - anything else which is not ‘modern javascript’ would be a good place to start. Start with server side rendering and stateless web pages, add interactivity and dynamic loading as required.
React was never intended to solve browser inconsistencies. Of course it developed hand-in-hand with the tools that solved those (transpilers, polyfills, bundlers), but that was not the main reason it was invented or became popular.
The original motivation was to describe UI as a function of state. It sounds trivial, because it is when server rendering, but once you start sprinkling enough interactivity it can get messy. It's of course not the solution to everything, but above a certain level of complexity I really think you should let someone else handle the problem of syncing state with UI, and JS on its own will never do that for you.
Yes that’s a good point sorry I just gave one e.g. from the article of IE event handling.
Re the original purpose of react being syncing state, I’m really not sure this small problem is actually worth the trade-offs of massive complexity and lock-in, nor that react is a good solution for it (double renders, persistent rendering bugs, use state, hooks etc).
It’s not something important to lots of apps and there are loads of other options from simple polling to web sockets to reloads, this can be done in a far simpler way without react. Also the use cases where this is central are really quite small.
> It means downloading MBs of javascript just to render a simple page.
React + react-dom minified gzipped is around 60kB. Yes, this is a lot; but no, this is not MBs of javascript. If your (simple) pages download MBs of javascript, that means you have added lots of other stuff on top of react.
While I completely agree that react is unnecessary for simple sites, react itself is not guilty of megabyte-size javascript bundles.
You’re writing your entire website in react then downloading it to the client every time. This means the weight is react plus hundreds or thousands of dependencies (which this is ecosystem seems to actively encourage) plus all your app logic. MBs is not uncommon for larger websites.
Wasn’t expressing UIs declaratively the original purpose of react? “The V in the MVC”. IMO it helped advancing the industry with declarative uis and Jsx
React solves problems we don’t have any more (eg IE), badly, at the cost of poor performance, lock-in and a host of other problems that other solutions just don’t have.
It means downloading MBs of javascript just to render a simple page.
It encourages multiple loads of massive json payloads for bits of the page which are then translated into html; this is a huge complexity and network tax for no gain.
It encourages constant re-rendering of page components.
It encourages mixing code and layout, making it incredibly easy for junior developers to make a terrible mess.
It encourages splitting web pages into thousands of components with poorly defined boundaries and putting lots of logic on the front end - this is disastrous for productivity and clarity when the project is of any size.
It has a bunch of legacy bits (double rendering, useEffect, useMemo, shadow dom etc) which just aren’t required and are often solutions to problems react itself created.
As to a prescription for what to use instead of react - anything else which is not ‘modern javascript’ would be a good place to start. Start with server side rendering and stateless web pages, add interactivity and dynamic loading as required.