A Historical Reference of React Criticism
https://www.zachleat.com/web/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).
Zach Leatherman 5454 replies 150150 likes123123 reposts Original on Mastodon54 replies
-
@hdv I learned it from @Jayhoffmann!! (you’re very welcome)
@zachleat June 2016 seems like when they knew, but did very little to dispell conventional dev beliefs.
@thomasapowell dang, good find. Any mention of performance on that right version?
@zachleat @thomasapowell I often dig this out of the wayback machine when people (wrongly) assert that "the React team never said VDOM was fast"
@slightlyoff @thomasapowell Thanks y’all, I added this to the post!
-
@passle yeah, hard to argue with that…
@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.
@remotesynth the stats make the marketing hard to stomach, that’s for sure.
@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.
@frehner oh, you’re absolutely right. I’ll fix that immediately.
@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
@43081j I honestly think it’s just that they have zero incentive to do it and it’s a difficult breaking change
@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
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://emmas.site/blog/2020/09/12/react-is-a-subsidy
* https://css-tricks.com/the-future-is-bright-because-the-future-is-static/
* https://instagram-engineering.com/making-instagram-com-faster-code-size-and-execution-optimizations-part-4-57668be796a8 Compressing React didn't make it faster, bottleneck is code complexity not transfer.
* https://branislavjenco.github.io/desired-state-systems/ "React is .. because DOM is very slow", citation needed
* https://blog.jim-nielsen.com/2022/web-predictions-on-a-whim/ "the pendulum of React is swinging"
* https://frontendmastery.com/posts/the-new-wave-of-javascript-web-frameworks/Wow, I… uh, well, there are quite a few more submissions from folks that need to be added to this post—I’ll try to get to them in a bit.
A lot more than I remembered, for sure.
@zachleat The line "nobody wanted to turn on the house lights while the JS party was in full swing" from "the market for lemons" is a great line.
@zachleat Almost tempted to pop over to the other place to see the Reaction over there 🍿
@joegaffey nothing yet, maybe still waiting on that long task to finish 🫠
Alright, I pushed a fairly sizeable addendum to this post with a bunch more links.
Thank you to @nachtfunke @krinkle @whalecoiner @hi_mayank @thomasapowell @frehner and the others who sent me things over DMs and will remain anonymous!
@zachleat @nachtfunke @krinkle @whalecoiner @hi_mayank React: The Historical Side-Eye
@zachleat @nachtfunke @krinkle @whalecoiner @hi_mayank @thomasapowell @frehner Such a good bunch of additions! Also amazing how many years it has been since some of them
woaaaah this is wild
@zachleat The thing that drives be absolutely **batty** is that it's always been pretty straightforward to use React in an "island" scenario. Like, a mostly server-rendered app written in any language could just carve out one piece of DOM on some screen and hand it over to a lazy-loaded React. And yet…nobody really seems to do this. React takes over not only the whole page but the whole damn app! Why?? What is it about React that leads people to think that's how it's *supposed* to work?
@jaredwhite React world is still (unwisely) resisting Islands though and you can see it in the Create React App GitHub issue comment from Dan Abramov.
@zachleat Yeeesh. I'll go hunt for that comment but I'm not sure my blood pressure today is ready for it… 😅
@jaredwhite @zachleat Something tells me - don't waste your time... https://tane.codes/@tanepiper/109790772922997251
@jaredwhite at my workplace there's plenty of React “apps” that sit on top of a legacy codebase
@wolfr oh interesting, is it a sort of micro-frontends architecture, or literally just multiple frontend apps?
@jaredwhite what you said - just a layer on top of a mostly server rendered app
@zachleat You can find the source here https://medium.com/@ji/react-was-invented-by-jordan-walke-who-was-working-on-facebook-ads-at-the-time-db5fdd21f5a4
They were having problems keeping things straight (you have to do this with ads code), and React's model is coherent even if I agree with some of the performance criticisms.
I think you're missing a simple point, which is that pushing computation to the client will encounter variable client CPUs, and some of them are not good. You can keep things more uniform by doing things on servers you control, but that might cost more money.
@sayrer whew, I don’t think it’s worth defending client rendering as a framework default at this point (are you doing that?) 😅
@zachleat No, I just don't like writing it, and I know all of the problems.
But sometimes these concerns don't matter. So, all of my values are irrelevant in those cases. I think for things require a login, and thus have a single entry point, it often doesn't matter. Not that I would want to work on that stuff.
@sayrer Anecdotally, I used to manage the login page for a Fortune 200 company back in the late 201x’s.
It was very important to have the login work without JS. We had all kinds of Windows handheld field devices that could not run JS that needed to access secure content.
@zachleat yeah, there's totally stuff like that. But there are also many businesses where 90% of the revenue comes from iPhones, and the remaining 10% is from equivalently fancy Samsung Androids.
All I'm saying is that there are actually quite a lot of cases where the technically-right thing is not even on the priority list. Most sites are Wordpress, Squarespace, or Shopify.
So, the remaining tasks are all quite bespoke, and React can work for some of them.
@sayrer well, I disagree but we needn’t belabor it!
@zachleat looks like there's a similar, somewhat React inspired, history on the iOS side
https://ioc.exchange/@shac/109824219329340869@joegaffey day-long builds oh no
@zachleat This feels a bit ahistorical at some points. The complaints about early performance don't exist in a vacuum. React was eating AngularJS's lunch while Angular 2 was in development hell. React was very much the underdog initially in the CSR space, which was well established. The "VDOM is fast" claim vanished as AngularJS (which used observers, which were slower) became increasingly irrelevant.
In fact, SSR was initially one of React's selling points over the competition until it faded more and more into the background, especially with CRA which has been de facto abandoned by its creators since shortly after its inception - Dan Abramov actually made a poll about where CRA should go from here as it's still the blessed default while being increasingly archaic with the rise of Next, Vite and Remix (he seems to prefer Vite, not Next).
Also, do web components actually have an SSR story yet? A few years ago Google devrels smugly promoted Polymer as "using the platform" with the "best practice" demo's HTML literally containing a single element in the body. Note that actual performance never factored into this, the understanding was that polymer was mostly web standards plus polyfills so it would become fast eventually and was simply morally superior despite being entirely limited to CSR (at least at the time).
It's always fair to criticize React and I'm the last person to complain if people want to shit on Meta but a lot of it just feels like a general criticism of most frameworks in the frontend space at any given time (cf. people in the discourse around this website complaining about tailwind, which seems to be entirely irrelevant beyond philosophical icks), which seems intellectually lazy if not dishonest if the point is to criticize React in particular. The frontend framework demon has been unleashed since at least dojo toolkit and jQueryUI/backbone (which, btw, also had no SSR support) and there's no point in pretending we can just go back to naked HTML+CSS like those mythical alternate early 2000s which never existed in that form ('member XHTML2 and the Semantic Web? They never made it past the concept stage). React didn't start the fire.
@zachleat To be clear, I'm not defending React as an alternative where static site generators are an option. I'm talking about it in the context of shared stateful content, i.e. "apps". In this context there's no question of "React or no React", only "React or what else".
Several prominent voices in the React space have for years now expressed a desire to move on to "the next thing" when it comes around and it's increasingly looking like that time is near with attitudes towards React shifting the same way they did when people abandoned AngularJS (which had been dominant in the same space at its time, though of course the space itself has been consistently increasing in overall size since 1997). Heck, remember Google's "Object.observe" proposal, which failed so badly they had to redesign Angular2 from scratch?
I'm not sure what the point of collecting a thousand ways to say "React bad" is when most of these are presented without the historical context. But if the goal is to get people to abandon React there needs to be a clear direction to move towards. And no, "islands" aren't a panacea unless you just want to ignore apps entirely, aside from them feeling oddly reminiscent of Web2.0 era widgets and could be argued to be the "junk drawer" approach to performance concerns, i.e. simply excluding what you don't want to or can't improve from the relevant metrics.
@alan whew! I don’t have the spoons to reply to all of the points here but I will maintain that there is value in collecting these items together, especially as the landscape shifts and retrospectives are being published leaning on (arguably) revisionist history.
#webcomponents have a SSR story, they’ve had a story for years now. SkateJS had a package that could SSR custom elements. Recent developments include the @lit-labs/ssr package that renders WC in Express middleware. You can see it in action on the 4K Blu-ray pages at https://ultrahdzone.com and the final chapter in my book Fullstack Web Components demos how to render vanilla JS custom elements with the lit package.
@zachleat Thanks for this, Zach. As someone that builds React apps by day, I am quite uneasy about the state we're in as an industry, and aware that what I do isn't helping the matter.
@zander Just keep doing your best (and what’s best for folks using our work) and the web will be fine ❤️
(Just between us as a junior dev I did build a few SPAs early in my career!)
@zachleat But can we talk about that zachleat.com typography. 👍
@toddmorey *chin hands* say more 😎
