A fun thing about reading Alex is that you can tell he's had the same arguments over and over again for a decade now and he's frustrated with having to keep on making the same points and getting the exact same responses.
Most of the people commenting on this piece won't have read this whole article (it's long, and internet attention spans are short). As a result, you'll find plenty of the comments here were exactly predicted by his writing here.
I see him as something of a Cassandra at this point, doomed to see the truth about web performance based on many years of research... and then to have nobody believe him. https://en.wikipedia.org/wiki/Cassandra
The people who don't think React (or Vue) is important are the same ones who have never worked on a large project with lots of screen updates and state changes that absolutely cannot be avoided. React is still #1 in popularity, and the most crucial tool for almost any web developer (aside from using TypeScript, instead of plain JS which is also critical for large projects)
React is reported to be used by 39.5% of developers worldwide, while Vue.js is at 15.4%. The number of "apps" using just HTML+CSS is precisely zero, because those aren't "apps" they're documents.
WordPress relies on server-generated HTML and its admin interface is a fairly complex "app", especially once you factor in the plugin ecosystem. According to [1], it's used on 43.7% of all public websites.
Generalizing much? React is as popular as it is because of inertia.
React holds an important space but its hardly the only tool that can succeed in a "large project with lots of screen updates and state changes". That's ridiculous.
I still think you can build good tools using just html, css and pure js if you have the right knowledge. For example, this social network was built without any frameworks and has the performance it has https://chat-to.dev
WOW this is a long article! Still waiting for the substance though...
The only point I can agree with is that React is stupidly hard to learn. It feels like a tool made for aliens, though once you master it, it can be pretty efficient.
Sorry to be the bearer of bad news, but the JS-free web isn't coming back. And if you're using modern JS, you might as well use React (or a similar tool). The user won't be able to tell the difference.
> Sorry to be the bearer of bad news, but the JS-free web isn't coming back.
It has never went anywhere? All it takes is a user brave enough to disable it or to use a web browser that doesn't use it or has issues with it. But for some reason many web devs actively ignore that.
Not GP. Started using React at work around 2017. The hooks API is just awful. Those complaints are extremely well-trodden ground at this point so I won't rehash. I'm using Lit.js for personal stuff instead these days. Shadow DOM isn't perfect but web components with Lit has been pretty low-surprise so far, which I can't say for Hooks React.
As someone who's been doing React since the beginning, I would agree that it's hard starting out.
However, I think any new paradigm is difficult starting out. Recently I've been learning OO for work and I've been finding it stupidly hard and entirely unintuitive.
Yes, you the developer. I think that’s his point. The performance if react sites is another thing and that’s what the user cares about. It also doesn’t work on mobile. React native was worshipped and now is thrown out.
Is it even working for the developer though? Last I checked the server-side rendering performance for react based frameworks was somewhere like 200 pages per second? Is that something to be proud of as a developer?
They're a wide chasm between what one can make and what is led to making. React can lead to fast, responsive websites, though you'd be fighting against a current pulling you out to a bloated, buggy mess. There's a unique stench that comes from many react sites where everything is a skeleton screen, everything loads slowly, history rewriting is busted, there's no hotlinking, and scrolling is glitchy. Peek under the hood, it's almost always react. Facebook.com quality is the outlier, not the likely outcome.
Tell that to all the former PHP developers. Where are these performant React sites? The largest and best tech companies out there certainly can’t do it.
Correct. The reason is not the frameworks but the languages. What is needed is a much more high-level and feature-powerful language.
Just look at react. Passing down dependencies/values is a pain. So what did react do? It introduced contexts. Similar, other react addons try to solve this problem. But they all sacrifice type-safety in the process.
They simply cannot solve this problem; only a better language can. Typescript maybe could, but they restrict themselves to not generate code (or at least very limited, I think for enums they do it).
The React team should have done their own language, rather than making it a framework/library. Then they could ensure the absence of side effects in rendering code, and had a better way of detecting updates. The knowledge about how to do this was already out there for many years before they started: https://en.wikipedia.org/wiki/Functional_reactive_programmin...
The only part of this whole thing I agree with is that you shouldn’t start a new project in React. Switch to SolidJS, and gain all the benefits (aside from the huge ecosystem) but with a speed to match plain HTML/JS.
I read through this to hopefully save all of you the clickbait and mid-way through nonsensical philosophical diatribe. It's a bit ranty and devoid of technically-caloric content.
The author is advocating for use of plain HTML/SSR patterns and avoiding SPAs and complicated frameworks/libraries ala Angular/React/etc. It's an old thought that lines up with the "you don't need JS" crowd.
Oh, and the author would like to kindly point out that React is legacy now. Because they said so. In case you didn't know.
You can read it that way if you ignore the rest of the article, I guess. They simply are saying many (most?) sites do not need to be SPAs and the baggage that entails with load times and latency. Follow a process to determine what is really needed based on objective requirements and then use objective measures to ensure it does not degrade the experience.
In most cases later frameworks are slow and bulky. I certainly hate using sites like X or Target on mobile. Random delayed loading of things, loss of scrolling position when going back, things just not loading the first time it delayed reactions. It sucks.
> Follow a process to determine what is really needed based on objective requirements and then use objective measures to ensure it does not degrade the experience.
This is how you end up with an amalgam of legacy crap that no one wants to touch. I can’t read guarantee you that outside of big tech and a couple of unicorns started by experienced devs this will NEVER work reliably.
React works because I can hire engineers that can be productive quickly. A lot of tech conversations leave the talent pool aside as if it's easy to find good engineers in all of the options you might have.
The ecosystem is another aspect. You have so many great options for off the shelf components and libraries with React that you might not have with other frameworks.
Before anyone mentions Custom Elements and Web Components, I must say I tried it. Gave it a lot of effort to be a solution but it is not!
"React works because I can hire engineers that can be productive quickly. A lot of tech conversations leave the talent pool aside as if it's easy to find good engineers in all of the options you might have."
"The ecosystem is another aspect. You have so many great options for off the shelf components and libraries with React that you might not have with other frameworks."
o7 thanks, people like this who do not work in contexts with problems that React solves yet insist React is not solving problems are profoundly boring.
I spent a lot of time working on react applications of one kind or another and I think most businesses don’t have “problems that React solves” for their frontends. Somewhere that’s actually an application might, but most line of business applications would be better as something like Rails views rather than React
Really? HTMX for me brings spaghetti code on the server side. Fine for small projects but not so for large ones. I would prefer the clear separation between frontend and backend beyond small scale projects.
Heartily concur. It's a classic of an essay written by one of those tortured souls who cannot understand why everyone so blithely moves past the incisive, obvious, truths they share.
With a topping of how this is all just solved by "giving a toss about the user", followed by a cloying apology for being vulgar
I'm not in web and am amenable to a good web dev hot take but this simply isn't worth the time, it's an array of generic wisdom delivered as if it's specific, written with the effort of someone who is proud of themselves when you disagree.
I mean the graph in the article of Amazon vs Target vs Wayfair is pretty damning. And honestly you don't even need the graph, just go to their sites. Target is dog slow while Amazon loads instantly.
Out of curiosity I checked on iPhone 14/4g and 2018 Intel MBP.
I don't get what the point of these comments is ? If you're using RPI with a 2g connection you'll have a bad experience shopping at the site ? And somehow that's supposed to factor in to my tech stack decisions ?
Most of the people commenting on this piece won't have read this whole article (it's long, and internet attention spans are short). As a result, you'll find plenty of the comments here were exactly predicted by his writing here.
I see him as something of a Cassandra at this point, doomed to see the truth about web performance based on many years of research... and then to have nobody believe him. https://en.wikipedia.org/wiki/Cassandra
reply