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 …


This content originally appeared on Zach Leatherman and was authored by Zach Leatherman

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!

8.2 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 (prior to adding any application code).

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 Zuckerburg 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:

“If you’re learning React, we recommend Create React App. It is the most popular way to try out React and build a new single-page, client-side application”

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

6.6 years ago

(Update, this entry was added after publishing)

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/

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

5.3 years ago

Rob Dodson filed RFC: Plan for custom element attributes/properties in React 17, 18, 19 #11347

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.

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

1.4 years ago

“øJS is coming to Next 🔜”—@rauchg

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: previously this section incorrectly stated the Remix team as the origin behind issues with server components.

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:

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

3 days ago

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.

Today

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

Addendum:

CSS-in-JS

(Update, this section was modified after publishing)

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). A thank you to Mayank who clarified some history on CSS-in-JS, and you can read more on their blog post.


This content originally appeared on Zach Leatherman and was authored by Zach Leatherman


Print Share Comment Cite Upload Translate Updates
APA

Zach Leatherman | Sciencx (2023-02-06T00:00:00+00:00) A Historical Reference of React Criticism. Retrieved from https://www.scien.cx/2023/02/06/a-historical-reference-of-react-criticism/

MLA
" » A Historical Reference of React Criticism." Zach Leatherman | Sciencx - Monday February 6, 2023, https://www.scien.cx/2023/02/06/a-historical-reference-of-react-criticism/
HARVARD
Zach Leatherman | Sciencx Monday February 6, 2023 » A Historical Reference of React Criticism., viewed ,<https://www.scien.cx/2023/02/06/a-historical-reference-of-react-criticism/>
VANCOUVER
Zach Leatherman | Sciencx - » A Historical Reference of React Criticism. [Internet]. [Accessed ]. Available from: https://www.scien.cx/2023/02/06/a-historical-reference-of-react-criticism/
CHICAGO
" » A Historical Reference of React Criticism." Zach Leatherman | Sciencx - Accessed . https://www.scien.cx/2023/02/06/a-historical-reference-of-react-criticism/
IEEE
" » A Historical Reference of React Criticism." Zach Leatherman | Sciencx [Online]. Available: https://www.scien.cx/2023/02/06/a-historical-reference-of-react-criticism/. [Accessed: ]
rf:citation
» A Historical Reference of React Criticism | Zach Leatherman | Sciencx | https://www.scien.cx/2023/02/06/a-historical-reference-of-react-criticism/ |

Please log in to upload a file.




There are no updates yet.
Click the Upload button above to add an update.

You must be logged in to translate posts. Please log in or register.