React Won by Default – And It’s Killing Frontend Innovation | Loren Stewart
React is no longer winning by technical merit. Today it is winning by default. That default is now slowing innovation across the frontend ecosystem.
Visitors, Developers, or Machines
Garrett’s observation is spot-on here:
I’ve been trying to understand the appeal of these frameworks by giving them an objective chance. I’ve expanded my knowledge of JavaScript and tried to give them the benefit of the doubt. They do have their places, but the only explanation I can come up with is that developers are taking a similar approach as Ruby and focusing on developer convenience and productivity. Only, instead of Ruby’s performance being tied to the CPU level, JavaScript frameworks push the performance burden to the client.
In both cases, the tradeoff happens in the name of developer happiness and productivity, but the strategies have entirely different consequences. With Ruby, the CPU is still (mostly) the responsibility of the development team, and it can be upgraded. With JavaScript, the page weight becomes an externality pushed onto visitors.
Related links
Hack to the Future - Frontend - Matt Hobbs
Put the kettle on. This is a long one!
Matt takes a trip down memory lane and looks at all the frontend tools, technologies, and techniques that have come and gone over the years.
But this isn’t about nostalgia (although it does make you appreciate how far we’ve come). He’s looking at whether anything from the past is worth keeping today.
Studying past best practices and legacy systems is crucial for understanding the evolution of technology and making informed decisions today.
There’s only one technique that makes the cut:
After discussing countless legacy approaches and techniques best left in the past, you’ve finally arrived at a truly timeless and Incredibly important methodology.
Why Silicon Valley CTOs Are Secretly Moving Away from React | by Coders Stop | in JavaScript in Plain English - Freedium
“We’ve stripped React out of our highest-traffic user flows and replaced it with vanilla JavaScript using small, focused libraries for specific needs,” said the CTO of a streaming service. “Our page load times dropped by 60% and our conversion rates improved by 14%.”
Close to the metal: web design and the browser
It seems like the misguided perception of needing to use complex tools and frameworks to build a website comes from a thinking that web browsers are inherently limited. When, in fact, browsers have evolved to a tremendous degree
Who’s Afraid of a Hard Page Load?
Why single-page apps are just not worth it:
Here’s the problem: your team almost certainly doesn’t have what it takes to out-engineer the browser. The browser will continuously improve the experience of plain HTML, at no cost to you, using a rendering engine that is orders of magnitude more efficient than JavaScript.
Meanwhile, the browser marches on, improving the UX of every website that uses basic HTML semantics. For instance: browsers often don’t repaint full pages anymore.
Related posts
Progressively enhancing maps
How I switched to high-resolution maps on The Session without degrading performance.
Responsibility
Fear of a third-party planet.
Switching costs
The enshittification of React …which was already pretty shitty for users.
HTML web components
Don’t replace. Augment.
Multi-page web apps
A question via email…