Concatenating text
In the dying embers of 2023, Mayank wrote a post that went through the trials and tribulations of React Server Components. I read the article, eyes widening all the way through to the end until my face vaguely resembled a US electrical socket, and it ultimately left me feeling like, man, I’m glad I’m not doing React at the moment.
Almost a year has passed since my last diatribe and it seems were still stuck in a sort of swirly miasma of maybe-react-isn’t-so-great-after-all. Last time, people were mostly grumbling about the terrible performance and the lack of server side rendering. Today, we’re still mad about the performance but we’re also mad that 1) Vercel has co-opted React, turning its canary releases into a vehicle for their own clunky metaframework, and 2) server side components as they stand are complex, cumbersome, and not really up to the job. I come from another perspective. (It’s the same one as last time, though.) Why the heck is everyone reaching for React as soon as something on the screen needs to update? And why do we insist on squishing our frontend concerns together with our backend concerns?
The discourse
We’re regularly treated to posts exploring the App vs Document dilemma for the web. A recent and fairly well-reasoned one is by Jake Lazaroff where he attempts to move it from a binary either-or proposition into a four-fielder. And he has some good points. You can’t do offline without resorting to some fairly gnarly JavaScript. We also saw Tom Macwright go to bat for the React crowd, saying that it’s all well and good for your personal blog to be statically rendered and dependency-free, but in the Real World™ people have Real Complexity™ and so we have React and SolidJS and friends.
I’m not going to argue against any of that, because it’s true! Lazaroff gives a bunch of examples: Zoom, Discord, Figma, Runescape, Wordle, Photopea among others. Those are proper-ass applications with proper-ass business models and proper-ass teams and they definitely require an advanced and battle-tested framework to take care of their proper-ass problems.
My argument, however, is that these sorts of applications are a tiny, nay, minuscule, part of our industry but we’re arguing about them as if the web was 50% realtime applications and 50% documents. My killgissning is that the actual ratio would be more like 95% document to 5% application, depending on where you draw that rather arbitrary line. For every person working on GMail you have a hundred people doing unglamorous maintenance on various Wordpress or dot-net CRUD apps. The amount of “applications” that totally should have been plain-vanilla websites is also too damn high. The web is—let’s just face it—basically a hundred million forms, and a couple of successful outliers that have to be something else. In my previous life I worked on dozens of high-profile projects of varying sizes and complexities for one of Sweden’s most prestigious consultancies. We made a lot of cool stuff on a lot of screens! We absolutely did some great work but we also committed pretty heinous crimes using Flash, Backbone.js, and eventually React. I don’t know what to tell you other than this: the hitbox for “this project would be a great fit for hydrated edge-rendered React/Vue/Qwik” is motherfucking tiny. Yet here I am, ranting about it like everyone else. It’s easy to get swept up.
The locality
I think the dev community (or whatever we should call the loose amalgamation of influencers that comprise the current tech thinkiverse) has a very unhealthy fixation with Silicon Valley. That’s not surprising. Everyone’s been staring slack-jawed for over a decade as the VC-industrial complex has strewn obscene amounts of yanqui dollar over feckless twentysomething “xooglers” in San Francisco, with some notable successes and a whole lot of failures. If you want a piece of that pie, you have to be a salesman, and you have to forcefully project feats of engineering on your company devblog in a very particular and muscular way. Since the Internet knows no borders, a lot of that showmanship has spilled over into the real world. Everyone keeps saying to use the Right Tool For The Job, and for the vast majority of developers The Job involves something like sitting at perfectly decent Mittelstand auto parts manufacturers and building decidedly unsexy order pipelines and support forms. But for some reason when the “right tool” discussion comes up, everyone immediately has to namedrop the most interactive, native-like thing they can imagine, and point to that as if it were representative of something they need to build on the web. (I have decided to name this practice a “Figma leaf,” for obvious reasons.) I understand the urge to rewrite your fifteen-year-old Java deployment into something more modern but I wish we would stop stroking our collective chins about just how many optimistic UI updates are required before a form turns into a shimmering, unicornlike Web App, and would instead start pondering how to make whatever interactivity we do have into something reasonable and re-usable without turning everything into a fetid 2MB soup of transpiled JavaScript.
The other thing
While we’re at it: I love component-driven development, and I’m grateful to React for popularizing it. It’s awesome. I don’t miss the old long-pages-of-string-interpolation ways one bit, even if we’re all just concatenating text in the end. JSX was a mistake, though! Not from a technical standpoint, but for the fact that it has encouraged so many people to try and smoosh the frontend into the backend, and that just hasn’t panned out. The code you run in your browser operates under a very different set of circumstances than your backend code. (That blog post was written almost nine years ago, by the way: we already knew that client-side rendering was difficult and expensive back then, and while the last decade has been a neverending procession of fresh code and ideas for it, the iron rule of “browsers will break your shit” has steadfastly remained.)
Look: is the idea of physically separating “code that runs business logic and builds markup” from “code that handles realtime interactions” really that awful? You can write both in JS if you like, I promise I won’t judge, but we can’t keep pretending that they’re basically the same. The popular abstractions that promise to make the backend/frontend experience seamless all leak in various ways, and straddling the divide is way, way harder than it seems at first glance. Plus, why are we doing this again? Oh, right: it makes developers feel good because they get to have everything in the same file. Prioritizing your DX over your users is not a great look.
My wish for 2024 is that everyone gets the epiphany that React is legacy tech from 2013 when browsers didn’t have template strings or a BFCache. Then it can finally pass into a sort of dignified irrelevance, and the general consensus can coalesce around the fact that a nice and robust server-rendering framework is probably what you need (unless you’re Figma, but my second wish for 2024 is that we all shut up about Figma.) Then maybe we can start coming up with good ways of sharing and collaborating on Web Components instead. Seems like a better use of everyone’s time.