> React’s logical model of recreating the UI on change of state is incredibly difficult to do right at scale.
What's much more difficult at scale is doing this without React.
In the old days when building a complex front-end web app, your app would slowly devolve into complex web of event handlers changing the DOM, and you'd eventually arrive at the conclusion that you'd eventually arrive at the conclusion that centralizing state and triggering UI updates based on those changes was the only sane thing to do. And then you'd end up either: 1) re-rendering the whole DOM on ALL state changes -- which came without its own set of problems of which performance was just one, or 2) manually hooking up callbacks to change pieces of the DOM as the relevant pieces of state changed -- which was only slightly less of a nightmare to maintain then the event handler spaghetti you were coming from. Also another dev your team would always just hook up and event another event handler to change the DOM somewhere, and ignore your state entirely.
React actually made this both much more performant and much easier to maintain.
If you aren't building a complex web app with a lot interconnected interactions and state changes, you don't have to use React. If you are, I encourage you to build it with jQuery, and look forward to your follow up blogpost.
React was the first front end js framework that passed the smell test, it just looked right.
If you'd worked in UI generally the popular libraries of the time like backbone, angular 1, ember, knockout, etc. clearly were flawed and chaotic (with apologies to mithril and a few others.) and would obviously quickly spaghettify.
These days between template literals, indexeddb and a simple library like morphdom you can write fast, predictable, queriable UI's that are offline first, persistent and easy to refactor and decouple components if your data model changes.
The problem with front end UI in js was that instead of being logical and operating off of some kind of persistent DBesque data model that you could query and increment.. you were stuck with ephemeral data and your UI was built off of arbitrary API calls that disjoint the consumption of and hide the underlying data model.
Rendering complex UI without the backing of proper data tools will not be clean or comprehendable over time.
I see the point but I think the article is overplaying its hand.
Sacrificing performance for a cleaner programming model is a reasonable tradeoff, it's weird that it's being criticized as though it were a matter of principle.
I'm very much a backend person and I don't like React either -- as far as I'm concerned raw HTML on a webpage as God intended peak UI -- but if you're writing full webapps you're going to need some form of framework regardless.
It's just a fairly lengthy fall into a trap that many, many programmers fall into: detaching their craft from the business purpose it serves.
A webpage rendering Xms faster has negative value if it e.g. took 3 months longer to hire the programmer responsible for writing it, or if that programmer costs $100,000/yr more, or if training them to proficiency took 6 months, etc etc. The advantages of well-known frameworks are very real to the business, they just offend some programmers' sensibilities which should be simply ignored.
In any case, the IBM analog is also weird/wrong. The takeaway from IBM has to do with bureaucratic decision-making and especially the principal-agent conflict between people who buy systems like IBM and people who have to use them. I have never seen a similar dynamic be responsible for the decision to use React. There is no React salesperson wining and dining the C-suite.
I’m sure there are exceptions, but every single project I’ve seen the decision to use React (or Angular) has been entirely imposed from above based on the best availability of cheap third world labor, so even if there are no React (or Angular) salesmen proper, there likely are salesmen of something else that are affecting the decision making process.
> detaching their craft from the business purpose it serves
Amen. This is the classical principal/agent problem and affects everyone all the time, not just programmers. But the amount of disregard for the overall business goal can be astounding.
There's a graph showing JavaScript execution time for "sites with JQuery" and "sites with React". With no further context about what kind of sites these are, the comparison is useless. It's like sampling binaries found on your local OS to count the number of machine code instructions per binary, then concluding that certain subdirectories are more efficient than others. "We found that you should put your code in /usr/bin to make it run faster."
> Andrew Clark’s vision of using more compiler magic to solve for React’s shortcomings is indeed a very Facebook-esque approach to solving problems with performance and suitability
and
> Much of the innovation in the UI space is now happening around the edges of the React ecosystem: Solid.js, Preact.js, Svelte.js, Vue.js, Astro.js, Qwik.js, Marko.js
Dismissing a compiler improvement is weird. Facebook has presumably millions of lines of React everywhere. Legacy tech is a thing, and most tech is legacy. Usability and familiarity matter. The tech is a collateral of the business, and it doesn't matter as long as it works.
Compiler "hack" or not, the business doesn't care, the business is about revenue and maintenance burden.
I don’t think it’s dismissing compiler improvements, I think it’s dismissing compiler astronautics when there already is a good, performant solution at hand.
Though to be fair to Facebook, in 2004 there were no good web languages. The choice was between weird enterprise stuff like WebObjects, JavaEE and ColdFusion, or small pragmatic languages with clumsy implementations like Python, Ruby and PHP.
Yes, if an aspect of React’s ecosystem makes it easier to deliver the project.
For example React Native seems like a nifty way to deliver mobile app functionality with less code/functionality duplication and simpler staffing. I might be out of the loop, is there something similar building on React alternatives?
Certainly React is not the only option these days, thank god.
The weirdest part is "compiler improvement is the wrong approach" then pushing Svelte, Solid, etc which ALL REQUIRE custom compilers. At least the React team is looking to make any added compiler optional.
I think this is a misunderstanding of the "nobody ever got fired for using tech stack X"
The background is something like:
1. I'm a profitable (or governmental) organization
2. I'm doing a thing in a critical part of my enterprise
3. That thing is not seen by stakeholders as a core business competency
So examples might be the computer network of a hospital or inventory management for a manufacturer.
The "build / buy" is more "I want to give someone money who will make my problem go away."
And with a sufficiently large organization even ordinary problems potentially turn into complex problems, so when you find an organization to give money to to make the problem go away, you want an organization that can make all of the problem go away even if it means spending a lot of money.
IBM (and microsoft / cisco, oracle, amazon, and a pretty small number of other players) can all cash the "give me money and I will solve all your problems" check.
I still like React and unlike many others I even like the newer stuff like RSCs. At the same time, it is hard to shake the feeling that React's core team and associated personalities have lost sight of the changing frontend landscape, and have become disconnected from software design principles. Instead they seem to be chasing some totalizing purity where everything can be handled in the React "model."
IMO, React repeatedly nerfing external stores and encouraging users more and more to shove their application state into React components has exposed what a poor model of reactivity React actually offers.
> Those of us that have been in the industry long enough…
For such an article, I would expect the author to spend some time talking about their real-world experience with React at scale.
> Much of the innovation in the UI space is now happening around the edges of the React ecosystem: Solid.js, Preact.js, Svelte.js, Vue.js, Astro.js, Qwik.js, Marko.js
Similar problem, the author suggests a bunch of libraries based on features rather than problems and solutions.
React and .NET/C# made sense to me but are nauseating abominations of mediocre corporate tech, and the more I saw people using them, the more it reconfirmed my belief that they were a no-go.
Usually, people win if they do the opposite of what the mass is doing :)
> React’s logical model of recreating the UI on change of state is incredibly difficult to do right at scale. By that I mean that as applications and teams get larger, the chances of writing components with side effects increases due to differing levels of skill, knowledge, experience, and simply having a larger body of code to cover.
This is a problem with all UI libraries. React at least makes it difficult to write components with side effects.
I know at least one CTO who was fired for picking IBM. And, BTW, nobody should ever be fired for making an honest mistake. He listened to the wrong advice and acquired lots of gear that was a poor fit for our needs.
Or, as Thomas J. Watson Sr. allegedly said:
“Recently, I was asked if I was going to fire an employee who made a mistake that cost the company $600,000. No, I replied, I just spent $600,000 training him. Why would I want somebody to hire his experience?”
> Like IBM, React will one day lose its crown by virtue of its own mass and inability to innovate towards better solutions.
I always thought one of the complaints of React was that they innovated too much. Things like Hooks and Server Components and Fiber were controversial, but seemed like radical attempts at innovation.
What kind of things are other frameworks doing to out-innovate React such that React won't be able to keep up?
I think this is kind of foolish. You should pick whatever tech your team is familiar and comfortable with, and avoid building insanely complicated monolithic apps that will be hard to port to the next technology (or version) your future developers will be familiar and comfortable with.
Also, I doubt too many front-end apps will have the long lives of the COBOL code that runs on IBM mainframes.
I can't really make my mind up on react, although it is definitely Java/IBM now - react devs are on average less smart than [newer framework] a la Graham on python.
Despite that, I actually quite like writing react in some sense - I prefer state in React to Svelte, even though I like where svelte is trying to go more.
I do absolutely hate some aspects of JSX - the nested ternaries are brutal and quite horrible IMO, so:
My ideal framework for the data work I do is probably a compiled (useMemo for performance is just inexcusable, sorry) react for the UI knobs, with Svelte components inside it for laying out the data
This seems wrong in many different levels. Not only React is getting faster, better, and more simple, but also is still the most adopted and the fastest growing web framework.
That's kinda like saying WordPress runs 40% of all websites....it's not really a testament to its quality, it's just what everybody knows how to build and deploy.
The difference being Wordpress is going down and React still going up. It's still the best business decision today and for the foreseeable future. It won't last forever, but the paradigm shift in UX that JS frameworks created will.
Am I the only one, who is frightened, that current stable version of React is almost two years old? Even if React#19 will be mostly backwards compatible (I hope), how many subtle differences will be introduced?
another month, another post complaining about react and claiming that its slow and hard... But its not hard, at all. Learning core react functinoality (which will let you make complex apps on its own) takes 2-3 hours (if you're a slow reader), and performance is fine. 99% of the time its not the tool, its the app's code being slow, and when its slow, its easy to fix most of the time
What's much more difficult at scale is doing this without React.
In the old days when building a complex front-end web app, your app would slowly devolve into complex web of event handlers changing the DOM, and you'd eventually arrive at the conclusion that you'd eventually arrive at the conclusion that centralizing state and triggering UI updates based on those changes was the only sane thing to do. And then you'd end up either: 1) re-rendering the whole DOM on ALL state changes -- which came without its own set of problems of which performance was just one, or 2) manually hooking up callbacks to change pieces of the DOM as the relevant pieces of state changed -- which was only slightly less of a nightmare to maintain then the event handler spaghetti you were coming from. Also another dev your team would always just hook up and event another event handler to change the DOM somewhere, and ignore your state entirely.
React actually made this both much more performant and much easier to maintain.
If you aren't building a complex web app with a lot interconnected interactions and state changes, you don't have to use React. If you are, I encourage you to build it with jQuery, and look forward to your follow up blogpost.