So much of my echo chamber is consumed by people, including myself, who have a very dim view of JavaScript frameworks being thrown at everything, arguing with the people who are in the process of throwing JavaScript frameworks at everything. We forget one very important thing, though: we represent the minority of the web community and our arguments probably look very pointless and silly to the majority.
This is the rarely-seen hour-long version of my Resilience talk. It’s the director’s cut, if you will, featuring an Arthur C. Clarke sub-plot that goes from the telegraph to the World Wide Web to the space elevator.
So instead of asking “why not React?” we asked: Which of our actual problems would React solve? We went through the list. There were none.
Also, this is good advice when you’re about to make a web component:
Every component starts with the question “does a semantic element already exist for this?”, and remarkably often the answer is yes.
A history of front-end development that culminates here:
The frontier of 2026, the stuff the sharpest people are most excited about, is render the HTML on the server, ship almost no JavaScript, and use the web platform instead of fighting it.
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.
Well, this is horrifying.
It’s not just about finding the issues—it’s about finding the issues at the right time.
When it comes to web performance, there are technical issues and then there are human issues.
Or, more precisely, why use React *in the browser*?
Web browsers provide you with great features for free. Why would you choose to use tools that stop you taking advantage of that?
The enshittification of React …which was already pretty shitty for users.