3 ms·
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 anyt
by eyelidlessness 3y ago
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.
- madeofpalk 3y agoI don’t think this will cause people to drop react. I think it will cause people to just ignore this new thing and carry on like they were before.
- eyelidlessness 3y agoHow are they going to do that? The only way it’s conceivable is a hard fork, or something equivalent, or some very abrupt architectural and strategic changes that would seem just as disruptive to users (and much more disruptive to heavily invested partners). I made the same prediction about hooks, but the fundamental difference is that you can ignore hooks. You can drop in basically any state/effect system and interop with components using their own, or hooks, or whatever. But you literally can’t even import existing components or call existing APIs (even hooks!) without rethinking the call stack. Parents and children are much more coupled than they used to be. Some libraries will either earnestly adopt RSC, or will make minimal necessary changes to be compatible, and propagate the problem to each of their consumers. And they, in turn, will have to choose whether to adapt to these factors within React… or without. And again, as an observer, it doesn’t seem like that prospect is being received very well. It seems like it’s being received the same way Angular 2 was: you’re in for some large dose of pain no matter what you choose to do, and “no one ever gets fired for choosing ___” feels a lot less of a safe bet. And unlike the Angular 2 experience, the other options are increasingly viable and mature and well received. My knowledge transfer to Solid took a few hours playing with a toy project for fun. Which is notably far less time and effort than I’d expect to spend getting up to speed with React today. I’d be happy to be wrong, I actually want the React team to succeed on several different highly principled vectors. But at minimum I think they’re going to need to really rethink how they’re communicating this set of changes and very probably how they’re rolling them out.