Before saying anything else, I'd like to thank the organisers of JSNation for inviting to speak in Amsterdam. I particularly appreciate the folks who were brave enough to disagree at the Q&A sessions afterwards. Engaged debate about problems we can see and evidence we can measure makes our work better.

The conference venue was lovely, and speakers were more than well looked after. Many of the JSNation talks were of exactly the sort I'd hope to see as our discipline belatedly confronts a lost decade, particularly Jeremias Menichelli's lighting talk. It masterfully outlined how many of the hacks we have become accustomed to are no longer needed, even in the worst contemporary engines. view-source:// on the demo site he made to see what I mean.

Vinicius Dallacqua's talk on LoAF was on-point, and the full JSNation line-up included knowledgeable and wise folks, including Jo, Charlie, Thomas, Barry, Nico, and Eva. There was also a strong set of accessibility talks from presenters I'm less familiar with, but whose topics were timely and went deeper than the surface. They even let me present a spicier topic than I think they might have been initially comfortable with.

All-in-all, JSNation was a lovely time, in good company, with a strong bent toward doing a great job for users. Recommended.

Day 2¹ — React Summit 2025 — could not have been more different. While I was in a parallel framework authors meeting for much of the morning,² I did attend talks in the afternoon, studied the schedule, and went back through many more after the fact on the stream. Aside from Xuan Huang's talk on Lynx and Luca Mezzalira's talk on architecture, there was little in the program that challenged frameworkist dogma, and much that played to it.

This matters because conferences succeed by foregrounding the hot topics within a community. Agendas are curated to reflect the tides of debate in the zeitgeist, and can be read as a map of the narratives a community's leaders wish to see debated. My day-to-day consulting work, along with high-visibility industry data, shows that the React community is mired in a deep, measurable quality crisis. But attendees of React Summit who didn't already know wouldn't hear about it.

Near as I can tell, the schedule of React Summit mirrors the content of other recent and pending React conferences (1, 2, 3, 4, 5, 6) in that these are not engineering conferences; they are marketing events.

How can we tell the difference? The short answer is also a question: "who are we building for?"

The longer form requires distinguishing between occupations and professions.

Occupational Hazards

In a 1912 commencement address, the great American jurist and antitrust reformer Louis Brandeis hoped that a different occupation would aspire to service:

The peculiar characteristics of a profession as distinguished from other occupations, I take to be these:

First. A profession is an occupation for which the necessary preliminary training is intellectual in character, involving knowledge and to some extent learning, as distinguished from mere skill.

Second. It is an occupation which is pursued largely for others and not merely for one's self.

Third. It is an occupation in which the amount of financial return is not the accepted measure of success.

In the same talk, Brandeis named Engineering a discipline already worthy of a professional distinction. Most software development can't share the benefit of the doubt, not matter how often "engineer" appears on CVs and business cards. If React Summit and co. are anything to go by, frontend is mired in the same ethical tar pit that cause Wharton, Kellogg, and Stanford grads to reliably experience midlife crises.³

It may seem slanderous to compare React conference agendas to MBA curricula, but if anything it's letting the lemon vendors off too easily. Conferences crystallise consensus about which problems matter, and React Summit succeeded in projecting a clear perspective, namely that it's time to party like it's 2013.

A patient waking from a decade-long coma would find the themes instantly legible. In no particular order: React is good because it is popular. There is no other way to evaluate framework choice, and that it's daft to try because "everyone knows React".⁴ Investments in React are simultaneously solid long-term choices, but also fragile machines in need of constant maintenance lest they wash away under the annual tax of breaking changes, toolchain instability, and changing solutions to problems React itself introduces. Form validation is not a solved problem, and in our glorious future, the transpilers compilers will save us.

Above all else, the consensus remains that SPAs are unquestionably a good idea, and that React makes sense because you need complex data and state management abstractions to make transitions between app sections seem fluid. And if you're worried about the serially terrible performance of React on mobile, don't worry; for the low, low price of capitulating to App Store gatekeepers, React Native has you covered.⁵

At no point would our theoretical patient risk learning that rephrasing everything in JSX is now optional thanks to React 19 finally unblocking interoperability via Web Components.⁶ Nor would they become aware that new platform APIs like cross-document View Transitions and the Navigation API invalidate foundational premises of the architectures that React itself is justified on. They wouldn't even learn that React hasn't solved the one problem it was pitched to address.

Conspicuously missing from the various "State Of" talks was discussion of the pressing and pervasive UX quality issues that are rampant in the React ecosystem.

We don't need to get distracted looking inside these results. Treating them as black boxes is enough. And at that level we can see that, in aggregate, JS-centric stacks aren't positively correlated with delivering good user-experiences.

This implies that organisations adopting React do not contain the requisite variety needed to manage the new complexity that comes from React ecosystem tools, practices, and community habits. Whatever the source, it is clearly a package deal. The result are systems that are out of control and behave in dynamically unstable ways relative to business goals.

The evidence is everywhere. React-based stacks frequently fail to deliver good experiences. And weren't "fluid user experiences" the point of the JS/SPA/React boondoggle?⁷

That this ambushes businesses time and again is a scandal.

But good luck finding solutions to, or even acknolwedgement of, that scandal on React conference agendas. The reality is that the more React spreads, the worse the results get despite the eye-watering sums spent on conversions away from functional "legacy" HTML-first approaches. Many at React Summit were happy to make these points to me in private, but not on the main stage. The JS-industrial-complex omertà is intense.

No speaker I heard connected the dots between this crisis and the moves of the React team in response to the emergence of comparative quality metrics. React Fiber (née "Concurrent"), React Server Components, the switch away from Create React App, and the React Compiler were discussed as logical next steps, rather than what they are: attempts to stay one step ahead of the law. Everyone in the room was implicitly expected use their employer's money to adopt all of these technologies, rather than reflect on why all of this has been uniquely necessary in the land of the Over Reactors.⁸

The treadmill is real, but even at this late date, developers are expected to take promises of quality and productivity at face value, even as they wade through another swamp of configuration cruft, bugs, and upgrade toil.

React cannot fail, it can only be failed.

OverExposed

And then there was the privilege bubble. Speaker after speaker stressed development speed, including the ability to ship to mobile and desktop from the same React code. The implications for complexity-management and user-experience were somewhat less of a focus. The most egregious example of the day came from Evan Bacon in his talk about Expo, in which he presented Burger King's website as an example of a brand successfully shipping. Here it is under WebPageTest.org's desktop setup:⁹

As you might expect, putting 75% of the 3.5MB JS payload (15MB unzipped) in the critical path does unpleasant things to the user experience, but none of the dizzying array of tools involved in constructing bk.com steered this team away from failure.¹⁰

The fact that Expo enables Burger King to ship a native app from the same codebase seems not to have prevented a statistically significant fraction of users from visiting the site on their mobile devices, where their slower CPUs struggle mightily:

The CrUX data alone is damning:

This sort of omnishambles is what I've come to expect from React-ecosystem experiences of every sort, and it's what folks mean when they say that "JavaScript broke the web and called it progress".

The other poster child for Expo is Bluesky, a site that also serves web and React Native from the same codebase. It's so bewilderingly laden with React-ish excesses that their engineering choices qualify as gifts-in-kind to Elon Musk and Mark Zuckerberg:

Why is Bluesky so slow? A huge, steaming pile of critical-path JS, same as Burger King:

Again, we don't need to look deeply into the black box to understand that there's something rotten about the compromises involved in choosing React Native + Expo + React Web. This combination clearly prevents teams from effectively managing performance or even adding offline resilience via Service Workers. Pinafore and Elk manage to get both right, providing great PWA experiences while being built on a comparative shoestring. It's possible to build a great social SPA experience, but maybe just not with React:

The unflattering comparisons are everywhere when you start looking. Tanner Linsley's talk on TanStack (not yet online) was, in essence, a victory lap. It promised high quality web software and better time-to-market, leaning on popularity contest results and unverifiable, untested claims about productivity to pitch the assembled. To say that this mode of argument is methodologically unsound is an understatement. Rejecting it is necessary if we're going to do engineering rather that marketing.

The TanStack website cites this social proof as an argument for why their software is great, but the proof of the pudding is in the eating:

The contrast grows stark as we push further outside the privilege bubble. Here are the same sites, using the same network configuration as before, but with the CPU emulation modelling a cheap Android instead:

Site	Wire JS	Decoded JS	TBT (ms)
astro.build	11.1 kB	28.9 kB	23
hotwired.dev	1.8 kB	3.6 kB	0
11ty.dev	13.1 kB	42.2 kB	0
expo.dev	1,526.1 kB	5,037.6 kB	578
tanstack.com	1,143.8 kB	3,754.8 kB	366

Yes, these websites target at developers on fast machines. But so what? They speak to the values of their creators. And those values shine through the fog of marketing when we use objective quality measures. The same sorts of engineers who care to shave a few bytes of JS on a site for users on fast machines are the same sorts of folks who will care about the lived UX quality of their approach all the way down.

It is my long experience that cultures that claim "it's fine" to pay for a lot of JS up-front to gain (unquantified) benefits in another dimension almost never check to see if either side of the trade comes up good.

Programming-as-pop-culture is oppositional to the rigour required of engineering. When the folks talking loudest about "scale" and "high quality" and "delivery speed" without metrics or measurement keep delivering crap results for both businesses and users, we need to collectively recalibrate.

There were some bright spots at React Summit, though. A few brave souls tried to sneak perspective in through the side door, and I applaud their efforts:

If frontend aspires to be a profession¹¹ — something we do for others, not just ourselves — then we need a culture that can learn to use statistical methods for measuring quality and reject the sorts of marketing that still dominates the React discourse.

And if that means we have to jettison React on the way, so be it.

---

1. For attendees, JSNation and React Summit were separate events, although one could buy passes that provided access to both. My impression is that many did. As they were in the same venue, this may have simplified some logistics for the organisers, and it was a good way to structure content for adjacent, but not strictly overlapping, communities of interest. ⇐

2. Again, my thanks to the organisers for letting me sit in on this meeting. As with much of my work, my goal was to learn about what's top of mind to the folks solving problems for developers in order to prioritise work on the Web Platform.

   Without giving away confidences from a closed-door meeting, I'll just say that it was refreshing to hear framework authors tell us that they need better HTML elements and that JSX's default implementations are scaling exactly as poorly ecosystem-wide as theory and my own experience suggest. This is down to React's devil-may-care attitude to memory.

   It's not unusual to see heavy GC stalls on the client as a result of Facebook's always-wrong assertion that browsers are magical and that CPU costs don't matter. But memory is a tricksy issue, and it it's a limiting factor on the server too.

   Lots to chew on from those hours, and I thank the folks who participated for their candor, which was likely made easier since nobody from the React team deigned to join. ⇐

3. Or worse, don't.

   Luckily, some who experience the tug of conscience punch out and write about it. Any post-McKinsey tell-all will do, but Anand Giridharadas is good value for money in this genre. ⇐

4. Circular logic is a constant in discussions with frameworkists. A few classics of the genre that got dusted off in conversations over the conference:

   • "The framework makes us more productive."
     
     Oh? And what's the objective evidence for that productivity gain?
     
     Surely, if it's large as frameworkists claim, economists would have noted the effects in aggregate statistics. But we have not seen that. Indeed, there's no credible evidence that we are seeing anything more than the bog-stock gains from learning in any technical feild, except the combinatorial complexity of JS frameworks may, in itself, reduce those gains.
     
     But nobody's running real studies that compare proficient jQuery developers to React developers under objective criteria, and so personal progression is frequently cited as evidence for collective gains, which is obviously nonsensical. It's just gossip.
   • "But we can hire for the framework."
     
     😮 sigh 😮‍💨
   • "The problem isn't React, it's the developers."
     
     Hearing this self-accusation offered at a React conference was truly surreal. In a room free of discussions about real engineering constraints, victim-blaming casts a shadow of next-level cluelessness. But frameworkists soldier on, no matter the damage it does to their argument. Volume and reptition seem key to pressing this line with a straight face.
   ⇐

5. A frequently elided consequence of regulators scrutinising Apple's shocking "oversight" of its app store has been that Apple has relaxed restrictions around PWAs on iOS that were previously enforced often enough in the breach to warn businesses way. But that's over now. To reach app stores on Windows, iOS, and Android, you need is a cromulent website and PWABuilder.

   For most developers, the entire raison d'être for React Native is now kaput; entirely overcome by events. Not that you'd hear about it at an assemblage of Over Reactors. ⇐

6. Instead of describing React's exclusive ownership of subtrees of the DOM, along with the introduction of a proprietary, brittle, and hard-to-integrate parallel lifecycle as a totalising framework that demands bespoke integration effort, the marketing term "composability" was substituted to describe the feeling of giving everything over to JSX-flavoured angle brackets every time a utility is needed. ⇐

7. It has been nearly a decade since the failure of React to reliably deliver better user experiences gave rise to the "Developer Experience" bait-and-switch. ⇐

8. Mark Erikson's talk was ground-zero for this sort of obfuscation. At the time of writing, the recording isn't up yet, but I'll update this post with analysis when it is. I don't want to heavily critique from my fallible memory. ⇐

9. WPT continues to default desktop tests to a configuration that throttles to 5Mbps up, 1Mbps down, with 28ms of RTT latency added to each packet. All tests in this post use a somewhat faster configuration (9Mbps up and down) but with 170ms RTT to better emulate usage from marginal network locations and the effects of full pipes. ⇐

10. I read the bundles so you don't have to.

    So what's in the main, 2.7MB (12.5MB unzipped) bk.com bundle? What follows is a stream-of-consciousness rundown as I read the pretty-printed text top-to-bottom. At the time of writing, it appears to include:

    • A sea of JS objects allocated by the output of a truly cursed "CSS-in-JS" system. As a reminder, "CSS-in-JS" systems with so-called "runtimes" are the slowest possible way to provide styling to web UI. An ominous start.
    • React Native Reanimated (no, I'm not linking to this garbage), which generates rAF-based animations on the web in The Year of Our Lord 2025, a full five years after Safari finally dragged its ass into the 2010s and implemented the Web Animation API. As a result, Renaimated is Jank City. Jank Town. George Clinton and the Parliment Jankidellic. DJ Janky Jeff. Janky Jank and the Janky Bunch. Ole Jankypants. The Undefeated Heavyweight Champion of Jank. You get the idea; it drops frames.
    • Redefinitions of the built-in CSS colour names, because at no point traversing the towering inferno of build tools was it possible to know that this web-targeted artefact would be deployed to, you know, browsers.
    • But this makes some sense, because the build includes React Native Web, which is exactly what it sounds like: a set of React components that emulate the web to provide a build target for React Native's re-creation of a subset of the layout that browsers are natively capable of, which really tells you everything you need to know about how teams get into this sort of mess.
    • Huge amounts of code duplication via inline strings that include the text of functions right next to the functions themselves. Yes, you're reading that right: some part of this toolchain is doubling up the code in the bundle, presumably for the benefit of a native debugger. Bro, do you even sourcemap? At this point it feels like I'm repeating myself, but none of this is necessary on the web, and none of the (many, many) compiler passes saw fit to eliminate this waste in a web-targeted build artefact.
    • Another redefinition of the built-in CSS colour names and values. In browsers that support them natively. I feel like I'm taking crazy pills.
    • A full copy of React, which is almost 10x larger than it needs to be in order to support legacy browsers and React Native.
    • Tens Hundreds of thousands of lines of auto-generated schema validation structures and repeated, useless getter functions for data that will never be validated on the client. How did this ungodly cruft get into the bundle? One guess, and it rhymes with "schmopallo".
    • Of course, no bundle this disastrous would be complete without multiple copies of polyfills for widely supported JS features like Object.assign(), class private fields, decorators, generators, spread, async iterators, and much more.
    • Inline'd WASM code, appearing as a gigantic JS array. No, this is not a joke.
    • A copy of Lottie. Obviously.
    • What looks to be the entire AWS Amplify SDK. So much for tree-shaking.
    • A userland implementation of elliptic curve cryptography primitives that are natively supported in every modern browser via Web Crypto.
    • Inline'd SVGs, but not as strings. No, that would be too efficient. They're inlined as React components.
    • A copy of the app's Web App Manifest, inline, as a string. You cannot make this up.

    Given all of this high-cost, low-quality output, it might not surprise you to learn that the browser's coverage tool reports that more than 75% of functions are totally unused after loading and clicking around a bit. ⇐

11. I'll be the first to point out that what Brandeis is appealing to is distinct from credentialing. As a state-school dropout, that difference matters to me very personally, and it has not been edifying to see credentialism (in the form of dubious bootcamps) erode both the content and form of learning in "tech" over the past few years.

    That doesn't mean I have all the answers. I'm still uncomfortable with the term "professional" for all the connotations it now carries. But I do believe we should all aspire to do our work in a way that is compatible with Brandeis' description of a profession. To do otherwise is to endanger any hope of self-respect and even our social licence to operate. ⇐