Link tags: react

Training your replacement | Go Make Things

I’ve had a lot of people recently tell me AI is “inevitable.” That this is “the future” and “we all better get used to it.”

For the last decade, I’ve had a lot of people tell me the same thing about React.

And over that decade of React being “the future” and “inevitable,” I worked on many, many projects without it. I’ve built a thriving career.

AI feels like that in many ways. It also feels different in that non-technical people also won’t shut the fuck about it.

JS-heavy approaches are not compatible with long-term performance goals

Frameworks like React are often perceived as accelerators, or even as the only sensible way to do web development. There’s this notion that a more “modern” stack (read: JS-heavy, where the JS ends up running on the user’s browser) allows you to be more agile, release more often with fewer bugs, make code more maintainable, and ultimately launch better sites. In short, the claim is that this approach will offer huge improvements to developer experience, and that these DevEx benefits will trickle down to the user.

But over the years, this narrative has proven to be unrealistic, at best. In reality, for any decently sized JS-heavy project, you should expect that what you build will be slower than advertised, it will keep getting slower over time while it sees ongoing work, and it will take more effort to develop and especially to maintain than what you were led to believe, with as many bugs as any other approach.

Where it comes to performance, the important thing to note is that a JS-heavy approach (and particularly one based on React & friends) will most likely not be a good starting point; in fact, it will probably prove to be a performance minefield that you will need to keep revisiting, risking a detonation with every new commit.

The Incredible Overcomplexity of the Shadcn Radio Button

Well, this is horrifying.

dead framework theory | AI Focus

This is depressing.

Escape Velocity: Break Free from Framework Gravity — Den Odell

React is no longer just a library. It’s a full ecosystem that defines how frontend developers are allowed to think.

Real talk!

Browsers now ship View Transitions, Container Queries, and smarter scheduling primitives. The platform keeps evolving at a fair pace, but most teams won’t touch these capabilities until React officially wraps them in a hook or they show up in Next.js docs.

Innovation keeps happening right across the ecosystem, but for many it only becomes “real” once React validates the approach. Which is fine, assuming you enjoy waiting for permission to use the platform you’re already building on.

Zing!

The critique isn’t that React is bad, but that treating any single framework as infrastructure creates blind spots in how we think and build. When React becomes the lens through which we see the web, we stop noticing what the platform itself can already do, and we stop reaching for native solutions because we’re waiting for the framework-approved version to show up first.

If your team’s evolution depends on a single framework’s roadmap, you are not steering your product; you are waiting for permission to move.

Is it Time to Regulate React? – David Bushell – Web Dev (UK)

React exists as a profound perversion of the web platform. React has failed upwards to widespread adoption because it provides a “developer experience” that bypasses the hard parts. Like learning HTML, or CSS, or JavaScript. Even learning React itself is discouraged; that’s for adults, you should use meta-frameworks. React devs are burdened with multi-megabyte monstrosities before they’ve written a single line of code. You cannot fix “too much JavaScript” with more JavaScript and yet React devs are trained to npm install until their problems become their users’ problems.

Default Isn’t Design

Framework monoculture is a psychology problem as much as a tech problem. When one approach becomes “how things are done,” we unconsciously defend it even when standards would give us a healthier, more interoperable ecosystem. Psychologists call this reflex System Justification.

The explains a lot about React-driven front-end development!

When a single toolset becomes the default, we don’t just prefer it, we build narratives that justify it. And that’s when a tool quietly becomes a gate or even a destructive force.

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.

JavaScript broke the web (and called it progress) - Jono Alderson

Semantic HTML? Optional. Server-side rendering? Rebuilt from scratch. Accessibility? Maybe, if there’s time. Performance? Who cares, when you can save costs by putting loading burdens onto the user’s device, instead of your server?

So gradually, the web became something you had to compile before you could publish. Not because users needed it. But because developers wanted it to feel modern.

Everything’s optimised for developers – and hostile to everyone else.

This isn’t accidental. It’s cultural. We’ve created an industry where complexity is celebrated. Where cleverness is rewarded. Where engineering sophistication is valued more than clarity, usability, or commercial effectiveness.

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

Stop Using and Recommending React - Lusitos Tech Blog

I can’t recommend React to any project or customer anymore.

Using almost any other modern alternative, you will save time, money and nerves, even if you haven’t used them before.

Don’t stick to technology just because you know it.

AI is Stifling Tech Adoption | Vale.Rocks

Want to use all those great features that have been in landing in browsers over the past year or two? View transitions! Scroll-driven animations! So much more!

Well, your coding co-pilot is not going to going to be of any help.

Large language models, especially those on the scale of many of the most accessible, popular hosted options, take humongous datasets and long periods to train. By the time everything has been scraped and a dataset has been built, the set is on some level already obsolete. Then, before a model can reach the hands of consumers, time must be taken to train and evaluate it, and then even more to finally deploy it.

Once it has finally released, it usually remains stagnant in terms of having its knowledge updated. This creates an AI knowledge gap. A period between the present and AI’s training cutoff. This gap creates a time between when a new technology emerges and when AI systems can effectively support user needs regarding its adoption, meaning that models will not be able to service users requesting assistance with new technologies, thus disincentivising their use.

So we get this instead:

I’ve anecdotally noticed that many AI tools have a ‘preference’ for React and Tailwind when asked to tackle a web-based task, or even to create any app involving an interface at all.

JSX.lol - Does anybody actually like React?

I’m subscribing to this RSS feed.

If Not React, Then What? - Infrequently Noted

Put the kettle on; it’s another epic data-driven screed from Alex. The footnotes on this would be a regular post on any other blog (and yes, even the footnotes have footnotes).

This is a spot-on description of the difference between back-end development and front-end development:

Code that runs on the server can be fully costed. Performance and availability of server-side systems are under the control of the provisioning organisation, and latency can be actively managed by developers and DevOps engineers.

Code that runs on the client, by contrast, is running on The Devil’s Computer. Nothing about the experienced latency, client resources, or even available APIs are under the developer’s control.

Client-side web development is perhaps best conceived of as influence-oriented programming. Once code has left the datacenter, all a web developer can do is send thoughts and prayers.

As a result, an unreasonably effective strategy is to send less code. In practice, this means favouring HTML and CSS over JavaScript, as they degrade gracefully and feature higher compression ratios. Declarative forms generate more functional UI per byte sent. These improvements in resilience and reductions in costs are beneficial in compounding ways over a site’s lifetime.

I don’t have time to learn React - Keith Cirkel

React is a non-transferable skill.

React proponents might claim that React will teach you modern UI, but from what I’ve seen it barely copes with modern UI. autofocus is broken, custom elements don’t work in all but the experimental version, using any “modern” features like dialog or popovers requires useEffect, and the synthetic event system teaches you so little about how DOM actually works. This isn’t modern UI, it’s UI from 2013 at its inception. I don’t have the time left in my career to pick up UI paradigms that haven’t evolved much beyond from when Barack Obama was in office.

When I mentor early career developers and they ask me what they should learn, I can’t say React, they don’t have time. I mean sure, pick up enough React to land you the inevitable job doing it, but it’s not going to level up your career.

How Microsoft Edge Is Replacing React With Web Components - The New Stack

“And so what we did is we started looking at, internally, all of the places where we’re using web technology — so all of our internal web UIs — and realized that they were just really unacceptably slow.”

Why were they slow? The answer: React.

“We realized that our performance, especially on low-end machines, was really terrible — and that was because we had adopted this React framework, and we had used React in probably one of the worst ways possible.”

Liskov’s Gun: The parallel evolution of React and Web Components – Baldur Bjarnason

React has become a bloated carcass of false promises, misleading claims, and unending layers of backwards compatibility – the wrong kind of backwards compatibility, as they still occasionally break your fucking code when updating.

Pretty much anything else is a better tool for pretty much any web development task.

The Neverending Story

Since the early days of the web, large corporations have seemingly always wanted more than the web platform or web standards could offer at any given moment. Whether they were aiming for cross-platform-compatibility, more advanced capabilities, or just to be the one runtime/framework/language to rule them all, there’s always been a company that believes they can “fix” it or “own” it.

Applets. ActiveX. Flash. Flex. Silverlight. Angular. React.

What Is React.js? (Webbed Briefs)

Its proponents can be weird, it takes itself far too seriously, and its documentation is interminable. These are some ways that some people have described Christianity. This video is about React.js.

Reckoning: Part 1 — The Landscape - Infrequently Noted

I want to be a part of a frontend culture that accepts and promotes our responsibilities to others, rather than wallowing in self-centred “DX” puffery. In the hierarchy of priorities, users must come first.

Alex doesn’t pull his punches in this four-part truth-telling:

1. The Landscape
2. Object Lesson
3. Caprock
4. The Way Out

The React anti-pattern of hugely bloated single-page apps has to stop. And we can stop it.

Success or failure is in your hands, literally. Others in the equation may have authority, but you have power.

Begin to use that power to make noise. Refuse to go along with plans to build YAJSD (Yet Another JavaScript Disaster). Engineering leaders look to their senior engineers for trusted guidance about what technologies to adopt. When someone inevitably proposes the React rewrite, do not be silent. Do not let the bullshit arguments and nonsense justifications pass unchallenged. Make it clear to engineering leadership that this stuff is expensive and is absolutely not “standard”.