.png)
4 months ago
2
Conferences, Clarity, and Smokescreens
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 evidence we can see and 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 I fear 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.
Per the 2024 Web Almanac, less than half of sites passing mobile grades.
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 — particularly React stacks — aren't positively correlated with delivering good user-experiences.
This implies the organisations that adopt React did not contain the requisite variety needed to manage this new complexity. That complexity comes from tools, practices, and community habits, but it is clearly a package deal. The result are systems that are out of control and behave in dynamically unstable ways relative to the business goals.
The evidence is everywhere. React-based stacks fail more often to deliver good experiences than competing architectures. And weren't "fluid user experiences" the point of the JS/SPA/React boondoggle?
That this ambushes businesses time and again is a scandal:
2024's switch from FID to INP caused React (particularly Next and Gatsby) sites which already had low pass-rates to drop more than sites constructed on many other stacks.
But good luck finding out that React has failed to deliver at scale at a React conference. There's scant discussion that the more React practices and norms spread into domains previously occupied by HTML-first approaches, the worse the results get, despite the eye-watering sums spent on conversion. 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 substantially all 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 abject 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 the relatively slower CPUs in those devices 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 I think folks mean when they say that "JavaScript broke the web and called it progress".
Is waiting 30 seconds for a loading spinner bad?Asking for an industry.
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:
There's something about the architectural compromises involved in investing in the React Native + Expo + React web model that prevents teams from either managing their web performance or adding the 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:
If we're going to get out of this mess, we need to stop conflating failure with success. The entire point of this tech was to deliver better user experiences, and so the essential job of management is to ask: does it?
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, but saying it is necessary if we're going to do engineering rather that marketing.
Popularity is not an accepted unit of engineering quality measurement.
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:
An absolute rout. The main difference? The amount of JS the lived values of each team allow them to justify sending.
| 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 and of a software practice that aspires to be a profession. When the folks talking loudest about "scale" and "high quality" and "delivery speed" without metrics or measurement keep delivering comparatively 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 the Q&A sessions after my talk are any indication, Luca faced serious risk of being ignored as a heretic for putting this on a slide.
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.
