My take on the current React and Server Components controversy

[flagged]

In the past few years I think the ‘JavaScript community’ (whoever that is) has done a decent job at dispelling the reputation of ‘silly js devs, making a new framework every other week that you have to learn’.

This React Server Components seems to be a bunch of effort on throwing all that good will down the drain. It seems like they’re really excited about this new API and the react and nextjs teams have just charged forward with whatever this is, without really much consideration or anything else.

Disclaimer: I’m an interested observer, but an observer nonetheless. I don’t think I’ll have a compelling reason to use RSC (or even React in any form) for anything other than curiosity in the foreseeable future. But I’ve been somewhat eagerly following the RSC evolution with eager interest out of purely academic interest in some of the problem spaces it’s meant (or could be positioned) to address.

With that disclaimed, I have a strong inclination to believe that RSC—its design and implementation, its apparent rollout strategy, communication and documentation around both—is going to lead to a probably underserved mass defection from React overall. I think so because the actual execution so far has substantially undermined the thing which made React so successful in the first place: perceived simplicity.

It’s not the first time this perception has taken a hit with a major transition. Hooks are a prominent example. But that hit and most others have turned out to be mostly temporary, or at least their fallout has been limited to people who reasonably don’t want to invest their time absorbing a fairly limited and transferable set of new concepts.

RSC simply isn’t, and cannot be, that. To understand RSC, you have to understand:

- Everything you already needed to understand to use React effectively

- Compiler directives that have to and might not ever transcend multiple build steps across multiple projects and teams

- Stuff is gonna request and respond with magic bespoke data on the wire for Reasons; the React team can explain the Reasons, but the state space is so large you’d have to be effectively a core contributor or early adopter to have any chance at holding it all in your head

- A supported feature matrix that’s essentially unknowable without keeping up as a personal hobby, because that matrix is partially determined by an external entity who can mark unstable features stable on their own whims and who are being actively encouraged to do so by the React team

- Not just the why is RSC but even the what is RSC in the face of incredibly casual and glib explanations like “yeah it is PHP actually” when it clearly is not, to anyone who has meaningful experience with both

- Any and all of what’s been understood so far is subject to become completely irrelevant at a moment’s notice, made so by an unknowable set of decision makers

- React is its own metaframework. You are explicitly expected not to use it directly, but rather to use some other metaframework’s implementation of an increasingly deeply complex set of interfaces—which you shouldn’t use directly

All of that, especially when combined, is in stark contrast with React’s defining features:

- View = (state) => abstract tree representing state, with some rules around…

- …effects are a messy reality but they’re comprehensible and composable if you invest some time understanding that

And, echoing the article author: I think there’s a probably a lot to like about RSC and the general technical strategy React is taking. But damned if it doesn’t feel like they’ve assembled an enormous boulder that will inevitably roll back down the hill they’re rolling it up while they also assemble the hill.

So the moral of the story is that you should be using old timers to write your code? They've seen it all and no longer are impressed by the shiny new thing. All they care about is making it work and most importantly: being productive.

> The number of concepts you needed to learn started growing, and the old intuitiveness of React began to go away.

Oh sure, there's new things to learn. But hooks encapsulate & contain the complexity much better than they used to.

I can only laugh to myself at the idea at class-based React or HoC was some halcyon "intuitive" React era. What we have now can be basically read top-to-bottom, with much less needing to deeply know lifecycle implications & complections & puzzle out implications each time we go to understand how a thing is behaving.

> On top of that, there was a mad rush throughout the ecosystem to implement them, many times poorly, leading to more confusion.

Can we use them poorly? Sure. Did we rush to play with the new tech? Absolutely! My though, it's sad to see this portrayed as a negative, as a strike against: this is how we learn! Open-source is strengthened by diversity, by learning in the wide. Initial adoption will be chaotic, but that vast experience leads more quickly to a healthier better normalized set of end behaviors!

The historical precedent for software framework development is having controlled, restrained ecosystem growth largely by a software giant or elite team, who is responsible for making perfect choices that everyone is going to have to live with either forever or until everyone's sick of all the old mistakes & makes a brand new library (like the long long long sequence of Microsoft frameworks for native & web). React by contrast as kept being successful because it keeps distilling out small core central ideas, and letting the ecosystem explore and innovate at the frontier with those ideas. Cathedral vs Bazaar models.

There's a lot of people whose idea of control and order is to believe in top-down systems, to believe in only guided careful controlled evolution. But this isn't the open source way, and, in my view, that way always leads to fragility and weaknesses. Including too many batteries in your solution leads to ossification & stagnation. Robust, long-term, good answers emerge only over time, only with lots of practice. And we're in such a beautiful age, where peership matters, where we have taste & sensibility to discern out of the many examples put before us what looks right & what looks good. These are the strengths of our era, our ability to iterate forward.

And with React Hooks, I think we're quite decently into the adoption curve. It's 4 years down the road from their introduction (16.8, in February 2019). I have a hard time imagining having to stick with the old ways. The old code that our small org refactors & cleans up is awful by comparison, is much less clear to read, has complex HoC concerns that rebuffed & scared most people. Meanwhile I think the ecosystem has really grown a very sophisticated smart sense of how hooks can & should be built, and is doing really stellar works with incredibly advanced hooks, that span front & back end both, which I doubt would have been a feasible wide-scale target previously.

Where we are is better. With great possibility & progress comes upheaval, yes, but it'd be a shame to dread it. Our designs are imperfect, our architectures ever apt for iterations; that we can adapt forward with grace & on so many frontiers - while still ending up speaking the same core language - all at once is truly a modern marvel. I can't imagine any better paths that what we've done.