A Historical Reference of React Criticism
There have been a number of criticisms levied at the React project over the years, some of them handled and some of them still wavering in the wind. In this post, I’ll summarize the ones that are most prominent in my memory as a way of maintaining a record (primarily for my own use but maybe you’ll find it useful too). If you have others, please send them my way!
December 2014
10 years ago:
Researching the Performance costs of JavaScript MVC Frameworks—John Bender (December 12, 2014)
To my knowledge this was the first data-backed criticism of the SPA/clientside rendering model. It showed an average React performance baseline of 1.26 seconds to first render on a mobile device over 3G, when performance guidelines recommended a goal of first render in under one second.
The React popularization of client-side rendering did not exist in a vacuum. It was happening as developers struggled to make this model of client-side React work on an increasingly diverse and demanding world-wide mobile device landscape, especially as Responsive Web Design won over m-dot architectures for most web work.
I’m reminded of Mark Zuckerberg famously admitting that Facebook bet too much on HTML5 for mobile, although I haven’t seen a connection between that 2012 quote and React’s initial release in 2013.
In the post, John states:
There are practical approaches we can already use today to reliably produce very fast rendering times, but they work best when HTML content is delivered from the server side rather than generating it solely on the client. That approach benefits many areas of user experience aside from performance alone…
The above quote seems incredibly prescient in hindsight and still (somehow) relevant to modern day React discourse as they finally begin to pivot away from create-react-app.
But notably, 8.2 years after the blog post was written, that pivot is as of now only an idea. Currently the React documentation still recommends clientside rendering:
“If you’re learning React or creating a new single-page app, use Create React App.”
It hasn’t improved with the new beta React Docs either:
It is interesting that they have anointed Next.js as the official chosen full-featured framework moving forward in the Beta documentation. I’m sure it has nothing to do with Next.js 13 being the “real React 18 release”.
April 2015
9.7 years ago:
The DOM is NOT Slow, Your Abstraction Is—Andrea Giammarchi (April 20, 2015)
Well, it turned out that React here at least worked (not on Android 2.3, only on webOS), but it delivers the worst performance compared with underscore, paperclip, or my DOM version.
Update February 7, 2023: this entry was added.
July 2015
9.5 years ago:
React + Performance = ?—Paul Lewis (July 3, 2015)
For mobile there's a remarkable (performance) cost to using React over not doing so, and the cost is so high as to be reasonably prohibitive.
React has significant costs, especially on mobile. React has a lot of computational work required to do all of its checks. On mobile the cost is far higher than I think is reasonable.
I really enjoyed using React, but I wouldn't personally use it on an app I'm building; I just don't think it would be fast enough.
Update February 7, 2023: this entry was added.
June 2016
8.5 years ago:
Thomas A. Powell notes that in June 2016, React’s home page was changed to remove copy touting the performance benefit of Virtual DOM with a pivot to a focus on efficiency instead.
Prior to this change it declared:
“React abstracts away the DOM, giving a simpler programming model and better performance.”—
https://facebook.github.io./react/
Update February 6, 2023: this entry was added.
July 2016
8.5 years ago:
Your license to use React.js can be revoked if you compete with Facebook—Jorgé (July 16, 2016)
If you are using or considering using React in a project you might want to consult a lawyer. Because of the patent clause you are not allowed to do anything that constitutes as competing with Facebook. If you do take legal actions or in other ways challenge Facebook, your license to use React is immediately revoked. Your license is also revoked if you have any legal disputes if you have legal disputes with any other company using React.
Update February 7, 2023: this entry was added.
December 2016
8 years ago:
Alright, so you’re not a beginner or you’re not building an app. You know better than to fall into the Create React App pit of client-side rendering performance problems and use a React framework that uses server side rendering, right? Well, not so fast.
🌟 When everything's important, nothing is! 🌟—Paul Lewis (December 10, 2016)
This post was a very early criticism of how Server Side Rendered frameworks using Virtual DOM still block the main thread in a pretty bad way:
SSR typically gets you a faster First Meaningful Paint. That's great for perceived performance, but for libraries / frameworks that recreate the DOM virtually, TTI seems to be pushed back, sometimes a long way. I guess the diffing of real DOM to make VDOM is more expensive than starting fresh?
The Progressive Booting section (to me) reads as the precursor to Islands architecture (August 11, 2020), with a special call in both this and the Islands architecture post to make more use of requestIdleCallback in frameworks, which as far as I could tell is not included with React 18 (with or without Suspense).
August 2017
7.4 years ago:
React’s open source license (with a patent clause) was classified by the Apache Software Foundation as a Category-X (read: problematic) license, meaning that it could not be used for Apache.org projects (July 15, 2017).
The React team at Facebook posted an explanation doubling down on a licensing choice (August 18, 2017) that had been in use since the project’s initial release in 2013.
One month after Facebook’s post, Matt Mullenweg (of WordPress) writes a blog post stating that WordPress would divest from React (September 14, 2017) in large in-progress projects Calpyso and Gutenberg.
Facebook reversed the decision (September 22, 2017) for React v16 a few days later.
The patent clause remained in place for many other open source projects at Facebook (and all prior versions of React).
Update February 7, 2023: some addition timeline context was added.
October 2017
7.2 years ago:
Rob Dodson filed RFC: Plan for custom element attributes/properties in React 17, 18, 19 #11347, noting compatibility issues between Web Components and React.
Currently, React 18.2.0 passes 0/14 of the advanced tests on the Custom Elements Everywhere tests. An experimental build of React is available but it is not (and at this point may never ship?) in a stable release.
7.2 years ago:
The Netflix UI Engineering team tweeted:
Removing client-side React.js (but keeping it on the server) resulted in a 50% performance improvement on our landing page
which included a photo of a talk slide that read:
By getting rid of React and moving to plain JavaScript, we saw a 50% reduction in our Time to Interactive (TTI) metric.
Update March 16, 2023: This section was added.
April 2020
4.7 years ago:
The Cost of Javascript Frameworks—Tim Kadlec (April 21, 2020)
A study of 4.3 million desktop and 5.4 million mobile URLs showed that React sites spent far more scripting related CPU time on the main thread than sites built with Angular, Vue.js, or jQuery.
…while Angular sites shipped more JavaScript than React sites, they (Angular) actually spend less time on the CPU—much less time.
September 2021
3.3 years ago:
“øJS is coming to Next 🔜”—Guillermo Rauch
I remember this tweet pretty vividly, even now! What an exciting possibility—and “soon”!
The tweet was posted on September 13, 2021, a full year before Next.js v13 shipped on October 25, 2022. Astute readers might note that Next.js v13 did not ship with øJS. The Next.js v13 bundle size was 44 kB larger than v12—about half of one React library larger, in fact.
As an aside, I’m curious how much of this had to do with miscommunicated expectations around React Server Components, given the criticisms also levied by the Hydrogen team at Shopify.
Update February 6, 2023: previously this section incorrectly stated the Remix team as the origin behind issues with server components.
Notably, 2021 Guillermo Rauch is a welcome pivot from 2013 Guillermo Rauch, confidently stating that “Single-page, JavaScript-driven apps are the future”. Though 2023 Guillermo Rauch seems to have jumped the shark 😅.
We might also remember that these frameworks are recommended by the React team on the official documentation for content sites and that Next.js, Gatsby, and Remix have long used the blog site as the quintessential starter project in their respective Getting Started documentation.
Here are a few baseline bundle sizes:
- Next.js (v13) was 90 kB (compressed), 272 kB (uncompressed) (as of 25 Oct 2022)
- Remix (v1.5.1) was 67.7 kB (compressed) (as of 8 Jun 2022)
- Next.js (v12) was 72.2 kB (compressed), 228 kB (uncompressed) (as of 7 Dec 2021)
Update February 7, 2023: Added a bit of history on Single Page Applications.
October 2021
3.2 years ago:
Ryan Carniato: JavaScript Framework TodoMVC Size Comparison (October 14, 2021)
A great analysis of how different frameworks grow in relation to application size.
| Preact | React | Solid | Svelte | Vue | |
|---|---|---|---|---|---|
| Vendor Size | 4.39 kb | 36.22 kb | 3.86 kb | 1.85 kb | 16.89 kb |
| Component Size | 1.21 kb | 1.23 kb | 1.26 kb | 1.88 kb | 1.10 kb |
(sizes shown are Brotli compressed)
Alex's goal was 5 seconds TTI on a slower device and network. For some industries like eCommerce that target should be more like 3 seconds. 70kb - 25kb = ~45kb budget here. How can a larger library like React even compete?
I do want to also call out a similar but far more comprehensive (and maintained) analysis of framework bundle sizes was done at webcomponents.dev (first published in February 2020).
February 2023
Alex Russell: The Market for Lemons (February 4, 2023)
This post includes a breathtaking array of receipts, especially in the Sandy Foundations section. I won’t attempt to summarize them here, but it’s definitely worth a read.
An analysis of Core Web Vitals across 9.3 million web sites as of February 6, 2023 shows that Core Web Vitals for both React and Next.js shows that both perform worse than the aggregation of all other sites in the archive for both mobile and desktop.
Currently only 26% of sites using Next.js have good Core Web Vitals. This is lower than React at-large (32.81%) and the entirety of all sites in the data set (39.37%).
August 2023
Things you forgot (or never knew) because of React—Josh Collinsworth (August 4, 2023)
October 2023
Why I Won’t Use Next.js—Kent C. Dodds
Kent lists a host of problems with Vercel’s Next.js in Why I Won’t Use Next.js, and many of those criticisms aren’t limited to Next.js but levied more broadly at the React ecosystem.
Addendum:
krausest/js-framework-benchmark(with commits dating back to 2016) with results- VDOM vs lit-html—Surma and Jake Archibald (November 7, 2017)
- React—Charlie Owen (August 26, 2019)
- This is a
web.archive.orglink posted with permission from the original author.
- This is a
- Static Svelte: JavaScript Blogging with 93% less JavaScript—Shawn Wang (September 13, 2019)
- React is a subsidy—Emma Humphries (September 12, 2020)
- The self-fulfilling prophecy of React—Josh Collinsworth (July 27, 2022)
- Will Serving Real HTML Content Make A Website Faster? Let’s Experiment!—Scott Jehl (September 21, 2022)
Update February 7, 2023: Added resources from Timo Tijhof and Thomas Michael Semmler!
CSS-in-JS
In this post I didn’t mention the rise and fall of CSS-in-JS—an approach created by the React team in November 2014 and further popularized in the React community before quietly walking it back almost 7 years later).
Update February 6, 2023: a thank you to Mayank who clarified some history on CSS-in-JS, and you can read more on their blog post.
39 Comments
Hidde
@zachleat thanks for this post, I find seeing it all in a timeline super helpful!
Zach Leatherman :11ty:
@hdv I learned it from @Jayhoffmann!! (you’re very welcome)
ThomasAPowell
@zachleat June 2016 seems like when they knew, but did very little to dispell conventional dev beliefs.
Zach Leatherman :11ty:
@thomasapowell dang, good find. Any mention of performance on that right version?
Zach Leatherman :11ty:
@slightlyoff @thomasapowell Thanks y’all, I added this to the post!
Mayank
@zachleat since you briefly mentioned CSS-in-JS at the end, i should point out that it was the react team that first coined the term, convincing everyone that it's actually fine. and so the ecosystem went all in on runtime CSS-in-JS 🙃it didn't take long for facebook to i… Truncated
Zach Leatherman :11ty:
@hi_mayank whoa, I did _not_ know that—are there any references I can read?
Mayank
@zachleat the original talk where they introduced it: https://blog.vjeux.com/2014/javascript/react-css-in-js-nationjs.htmltheir hard-to-find new recommendation (see "Future" section): https://github.com/reactwg/react-18/discussions/110i also wrote about it 😄 https://blog… Truncated
Zach Leatherman :11ty:
@hi_mayank amazing, I appreciate it!
passle
@zachleat Reacts custom elements story is a sad joke
Zach Leatherman :11ty:
@passle yeah, hard to argue with that…
Zach Leatherman :11ty:
@hi_mayank I added these links to the post, thank you!
Mayank
@zachleat yay! i love that there are now so many receipts of what the react team is doing/not doing
Kees de Kooter
@zachleat I recall this blogpost by one of the prominent React committers. Admitting that he does not know CSS.I was and still am amazed how you can build a frontend library without such knowledge.And it might explain the css mess around React.https://overreacted.io/things-i-dont… Truncated
Zach Leatherman :11ty:
@kdekooter I do love the vulnerability of that blog post, for what it’s worth!
Brian Rinaldi
@zachleat Wow those numbers for Next.js you cite at the end are abysmal. I am feeling like opinion may be shifting. As someone who has never really bought into React/Next (I've used it and written about it entirely out of necessity), it's nice to see.
frehner
@zachleat one minor correction - the Hydrogen team is the one that made that statement about RSC, not the Remix team. We both work at Shopify, and work together frequently as well, but we are different teams and people.
Zach Leatherman :11ty:
@remotesynth the stats make the marketing hard to stomach, that’s for sure.
Zach Leatherman :11ty:
@frehner oh, you’re absolutely right. I’ll fix that immediately.
Danny Blue
@passle @zachleat I am still seeing arguments that the synthetic event system is a good idea. I just fucking can't.
James Garbutt
@zachleat Can't believe Rob's RFC was 5+ years ago. I feel like one or more people in the react team must hate custom elements and the DOM just as much as they hate classes :D
Zach Leatherman :11ty:
@43081j I honestly think it’s just that they have zero incentive to do it and it’s a difficult breaking change
James Garbutt
@zachleat It's very possible. The majority of their audience doesn't need to care. So time is better spent elsewhere. Still a shame though, especially to see the efforts by people like Rob D wasted. Many of the community would happily help push things like that along
Timo Tijhof
@zachleat Some pages in my secret "React" bookmarks folder:* http://webreflection.blogspot.com/2015/04/the-dom-is-not-slow-your-abstraction-is.html?m=1 * https://www.swyx.io/svelte-static * https://www.youtube.com/watch?v=uCHZJy2n8Qs 2017: VDOM is DX over UX. * https://em… Truncated
Nikolaj Nyboe
@zachleat got it, thanks for that extra nuance 👍
@tmcw
in the universe of essays (from people i like and usually agree with!) are things like zachleat.com/web/react-crit… and infrequently.org/2023/02/the-ma… / in the 'more server rendering', there's next.js, react server components, and remix. for accessibility, basically… Truncated
@MatthieuM_oreau
ne fresque historique des différentes critiques apportées à React et comment il a évolué face à celles-ci zachleat.com/web/react-crit…
Mayank
@zachleat it's just landing page though. their actual product probably uses tons of react
Zach Leatherman :11ty:
@hi_mayank Yeah, for sure. Another data point for the pile though.
Evan
@hi_mayank @zachleat I actually thought I remembered hearing that Netflix moved away from React to vanilla JS for their entire app, but maybe I’m misremembering…
Chris Hayes
@zachleat @kentcdodds Next is changing quite a bit. Think they got a little scared of Remix.Not sure Remix is really the lesser of 2 evils when it's owned by Shopify (though Shopify DX in general is pretty great). I suppose that's not the focus here.But, if we're go… Truncated
Zach Leatherman
@chris_hayes the work is done—it’s shipping soon!https://fediverse.zachleat.com/@zachleat/111268294523729861
Tomb Rotdolph :thomas:
@zachleat while I agree with the very high level sentiment, it's a bit beyond the pale for Kent to say that React wins on The Web Platform, Independence, Too Much Magic, Complexity, and Capability when he's spent years trashing native components at every opportunity.As us… Truncated
Zach Leatherman
@rockerest I’ll keep saying this but I’m okay with folks learning lessons we’ve known for a long time—we need allies and not “I told you so’s!”
Tomb Rotdolph :thomas:
@zachleat fair enough. I'll keep watching!
Zach Leatherman
@chris_hayes no, that shouldn’t be a requirement. CJS plugins should work as is. The one exception there is if you have a CJS config file in 3.0 and you want to import a bundled plugin from Eleventy core, you will need to use dynamic import() in an async config to do this.
Chris Hayes
@zachleat that's helpful, thank you. The lightweight 11ty + WebC flow has me excited.
Brian David
@zachleat @kentcdodds "Overrides global fetch." WHHHHHHaaaaaaaaat?
Zach Leatherman
@bcdavid @kentcdodds mmmmmhmmmmmmmmm