React Is the New IBM (2023)

> 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.

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.

The data to support the argument looks very weak.

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

- Solid.js requires *babel-preset-solid* [1]

- Selvte has a compiler

- Astro components are custom `.astro` files

- Qwik.js ships an optimizing compiler [2]

- Vue has `@vue/compiler-sfc` [3]

React is fine, stable and easy to upgrade

[1] https://www.solidjs.com/guides/getting-started

[2] https://qwik.dev/docs/advanced/optimizer/

[3] https://vuejs.org/guide/scaling-up/tooling#lower-level-packa...

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 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.

(edited for formatting)

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.

I never, ever bothered to learn React.

Stuck with .NET/C#.

If I have to write web UI, I use Angular, Blazor, and Razor MVC.

React never made any sense to me, and the more I saw people using it, the more it reconfirmed my belief that it was a no-go.

Usually, people win if they do the opposite of what the mass is doing :)

Just an entire post of copium. React is fine move along

> 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.

Synthetic benchmarks should be retired. Build a real app, measure real impact. Unless your users insert 1000 rows, of course.

Other than that, I agree with the general premise of React becoming the new IBM, that's totally fair.

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?

React is the new Apple :)

React is awesome.

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