13 ms·

My take on the current React and Server Components controversy

49 points by hyperknot 3y ago

thinkingkong 3y ago
The teams working on Next and React are pushing things a little too fast. The problem is the bulk of the consequences of their actions fall on library developers and maintainers. Frankly Im not even sure why everyone is in such a rush to rewrite all the docs, components, libraries, and frameworks for the unpteenth time.
- nathanaldensr 3y ago
  Boredom alleviation and paycheck justification.
- rjbwork 3y ago
  Fire and Motion.
- ChrisLTD 3y ago
  I don't believe Server Components are a make-work scheme for React specialists, but they feel like a make-work scheme for React specialists.
mmmeff 3y ago
I had a junior on my team propose we switch our year old project to Next’s app router. After telling him no, I became concerned that I was becoming all the lead developers I’ve worked with in the past that shut me down and, at the time, seemed to be holding back innovation on our team. I get it now. I totally get it.
- esskay 3y ago
  I had a similar situation a year or two ago and since then have had several juniors complain that we're using "old tech" or missing out on the latest packages. I gave up trying to be understanding and reason with them. It just seems new developers, and especially frontend developers see a shiny new package every week and want to try it. Before we put a stop to it we were lumped with a handful of projects that were frankly awful, with a bunch of spaghetti javascript code written in the flavor of the week which wouldn't compile on anything except a very specific version of a bunch of packages, whilst pulling in close to a gigabyte of random dependancies that nobody had any kind of handle on from a security point of view.
  - felipemnoa 3y ago
    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.
    - datavirtue 3y ago
      Adults should be present and in charge, yes.
  - zaphirplane 3y ago
    The thing is a library usually advertises how they address a painful experience in other projects. That is the hello world fallacy, there is a blog about it. Basically you see how elegant or easy to do X in a new library but you don’t see how complicated it is to do Y. Y is complex in the new library and simple in your existing library
- athesyn 3y ago
  >I had a junior on my team propose we switch our year old project to Next’s app router. that doesn't sound like a big change.
  - ovao 3y ago
    It’s quite a big change, depending on how many routes are in play. Migrating to App Router is non-trivial. Thankfully, the pages directory model is still just fine, so there’s no immense pressure for existing apps to migrate, and it can be done somewhat incrementally.
  - recursive 3y ago
    Is that supposed to be an argument for or against doing it?
revskill 3y ago
RSC is broken if your library mutate the DOM tree after mounting.
drb999 3y ago
Reading this makes me think I guessed the right way going “all-in” on Remix vs Next. It was a guess, but it’s just so much more intuitive and web standards friendly, serverless friendly, browser friendly…
- seandoe 3y ago
  Yea, I've been using both and really like the direction of remix. Why did react become so intertwined with nextjs and obsessed with ssr? I wish react stayed focused as a light spa library we all learned and loved and let the ssr frameworks do their own thing.
crooked-v 3y ago
RSC feel like a poorly-documented 0.5 beta filled with endless breaking changes being pushed as default for some inexplicable reason.
baerrie 3y ago
As soon as React started suggesting using a framework for their framework, the writing was on the wall. Nested frameworks are like the private equity and financial sector, smoke and mirrors abstraction that delight some, offend others, and make a small group richer and richer. The churn of “progress” is exhausting man
- fourseventy 3y ago
  Its frameworks all the way down
- fourseventy 3y ago
  And the "progress" doesn't even materialize to anything concrete. Are websites really better in 2023 than in 2010? Are they faster to code? I would argue no for both points.
esskay 3y ago
[flagged]
- z3t4 3y ago
  The JS community is like two million developers. When thousands of developers are using butter as an hammer it will feel like a lot. but they are just a small fraction. the js community consist of both small and big warlords pushing their own agenda.
madeofpalk 3y ago
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.
- shipscode 3y ago
  Sounds like the initial hooks launch. A lot of goodwill was used up with that. It might look fine behind the desk at Meta on the React team, but on the ground on real world 2nd and 3rd rate dev teams the damage has been immense. You have entire teams of devs that can't understand useEffect for 2-3 years.. can't say that about pre-hook React.
  - kaba0 3y ago
    As mentioned elsewhere, hooks have very little criticism from any remotely experienced developer who used them, as they are simply an easier/better mental model. It is probably also easier for that “2nd or 3rd rate dev”, unless it is a legacy project where pre-hook react is mixed with it arbitrarily (and God save us, not even the “seniors” know what to make of that)
shaunpersad 3y ago
IMO React started going off the rails when they introduced hooks. The number of concepts you needed to learn started growing, and the old intuitiveness of React began to go away. On top of that, there was a mad rush throughout the ecosystem to implement them, many times poorly, leading to more confusion. RSC seems to be history repeating itself.
- imbnwa 3y ago
  I think hooks made sense, as they gave React the last inch of control over the user call stack to make better, more uniform scheduling decisions; Solid.js demonstrates the idea more clearly in much more idiomatic JavaScript. However, their messaging and documentation were not at all clear for me at launch, to the point that I refused to interact with them for years. The rest though, yeah, I dunno
- jauntywundrkind 3y ago
  > 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.
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.
draw_down 3y ago
[dead]
lucidone 3y ago
Front end development doesn't have to be awful, particularly with how much JavaScript the language has improved alongside browser APIs. React made sense at one point because the abstractions it employed were common in other contexts: lifecycle events (intentionally avoiding the "hook" word here) are present pretty much everywhere in programming abstractions (on initialization, on deinitialization, on update, and so forth). These were aptly named "onComponentThing"s and grokable. Hooks, and particularly useEffect, ruined it for me. I have given up trying to understand why changing button states or presenting modals has become so obtuse and frustrating. I don't care about updating my react-router and rewriting it again for the third or fourth or whatever time. I don't want another new testing library, another new "best practice", or another repeated mistake in the reinventing-the-wheel-cycle the React community seems obsessed with. It's all so exhausting. I write Rails now with erb templates and some dumb javascript to toggle modals and change button colours. It's not cool but at least I can understand it six months later.
- shipscode 3y ago
  I'm in the same boat. Redux + Pre-Hook React was very legible & straightforward... Post hooks React is strong on theory but weak on substance, and I've gone to just jQuery and Python for my latest project. I did migrate my last project the barebones JS MVP -> React and regretted it immensely. It took about a month and didn't provide enough value to make it worth it.
  - datavirtue 3y ago
    I tried to learn React during the transition. Thankfully I had the authority to nope-out after trying to build a few apps with it and running into nothing but tons of arguing online when trying to search for help on what I thought would be an easy five minute task: to find out the best way to track state in my app.
    - shipscode 3y ago
      Yeeeep. The arguing by clout chasers was the worst part.
bob1029 3y ago
How many of us are working on web applications that legitimately cannot be served as basic, server-side web forms with JS only as necessary for dynamic client-side UI (e.g. disabling buttons upon form submit)? How are things like SPA improving the end user's experience and/or adding value to the product? If you are struggling and want a no-bullshit stack, why not PHP or string interpolation in your favorite language? These approaches are easily more productive than anything that has come out over the last 5 years. All the excuses for why this won't work are almost certainly traceable back to ego/resume-driven development pressure rather than actual technical justifications. Bookmarking MDN and literally treating it like the web bible is the solution for most of this. You don't need a JS framework. You don't need a CSS framework. Definitely not as of 2023. Between big wins like grid & flexbox, I can't think of anything I absolutely need to vendor out anymore. Once you take the training wheels off and fall a few times, you will learn that this stuff isn't that scary. You can actually write javascript like "document.getElementById" and retain ownership over your soul. The next step is convincing your teammates of the same and then deciding upon some common patterns to follow that make it easier to collaborate. Put differently, let the frameworks evolve naturally over time. Don't force them in from the beginning.
- synergy20 3y ago
  There are many use cases where server components making no sense: 1. RESTful or API sites that just need a SPA to render 2. embedded boards that can never run node.js etc, there are millions or billions of them. 3. Eletron.js or React Native related applications, why do I need a next.js alike component involved at all? Mixing SPA with SSR into React makes thing unnecessarily complicated, can SSR be an opt-in component just like what it used to be, so us SPA users do not need know your yet another revolutionary goodies that everybody must love it or he/she has no clue what's the best right now? I switched from Vue to React, now it seems I must switch back as Vue still separates SSR from CSR, god knows how long will that stay.
- AgentME 3y ago
  I'm not sure you understand what React Server Components are if you think server-side web forms with only the necessary client-side JS is in opposition of it instead of being exactly what it's about.
deleted 3y ago
[deleted]
shipscode 3y ago
With the amount of bs I had to go through when they dropped Hooks, I'll never use shiny new tech from the React Team again. I'm sure there are thousands of devs who feel the same. I think the React Team will soon be faced with an Angular 2.0 style situation where they are forced to break class components, hooks, etc to get people to use new patterns. The number of people who will do it out of goodwill has had to have been diminished to a minority percentage of React enthusiasts. Personally, I just rock jQuery for my personal projects. I get the same dollar coming over the wire with a way faster time to live and reduced complexity.
- andrewstuart 3y ago
  >> when they dropped Hooks What? Gotta link?
  - epalm 3y ago
    If you think they meant ‘dropped as in removed’, what I think they meant was ‘dropped as in introduced’.
    - andrewstuart 3y ago
      Yeah I guess “dropped” has opposite meanings.
- postalrat 3y ago
  Were you forced to use hooks? Or did other people prefer it?
- leerob 3y ago
  Class components still work in React, right?
andrewstuart 3y ago
It's disappointing the focus React has on server side. I feel like the project should have reorganised into the React Client project and the React Server Side project.
- seandoe 3y ago
  I share the same sentiment. I don't like this "in bed with nextjs" and obsessed with server-side thing. Server rendered apps have their place, but so do spas. Let the spa haters hate. You can make great, performant apps with strictly client side rendering. For some applications, it's the best choice.
jemmyw 3y ago
I really don't like the server side frontend rendering solutions. It's an added complexity especially if the app is served from a non JS backend - now you also have to run nodejs to prerender. Mainly it just seems like a lot of folk rush to implement this kind of optimization because it's cool rather than because it makes sense for your product and users.
leerob 3y ago
(I'm on the Next.js team) I appreciate Lenz's feedback and writing all of this down. I can empathize with how they and other library maintainers are feeling. There's more we can do on the Next.js side to help ease the transition (and this feedback will help us there, so thank you). One point of confusion in the community has been around client components. If server components are new and exciting, does that mean client components are bad and we shouldn't use them anymore? No, it's okay to continue using them, but definitely want to acknowledge that can be draining for library maintainers to have to deliver that message. The client/server evolution of React is still in the early innings, so maybe this will be less of an education issue going forward. Client components = able to use the existing React ecosystem. There's also some confusion about the React canary releases (https://react.dev/blog/2023/05/03/react-canaries https://react.dev/blog/2023/05/03/react-canaries). These features are ready for frameworks to adopt. The normal semver rules still apply for frameworks when they add experimental features (ideally behind flags). There is a separate experimental channel for React, that uses experimental features (like Server Actions). The infinite loop issue mentioned (marking a client component as `async`) now causes an ESLint error in Next.js. Appreciate all of the suggestions in the post. A good conversation to have!
- deminature 3y ago
  Today when creating a new next app, you get this: > Would you like to use App Router? (recommended) It seems like users shouldn't yet be funnelled by default into using RSC.
000ooo000 3y ago
I used React for about 5 years, pre-hooks. I thought it was good, felt productive using it (thanks MobX). I have been putting it on my resume, but I'm starting to think I should be avoiding React jobs because of this churn and grief in the ecosystem. Hooks was bad enough but RSC seems like strike 2. Have been using Lit.js in a hobby project and I'm really enjoying it. I'm not big on how stylesheets don't penetrate the shadow DOM but otherwise it just feels like I'm back writing heyday React.

49 points by hyperknot 3y ago

The teams working on Next and React are pushing things a little too fast. The problem is the bulk of the consequences of their actions fall on library developers and maintainers. Frankly Im not even sure why everyone is in such a rush to rewrite all the docs, components, libraries, and frameworks for the unpteenth time.

nathanaldensr 3y ago
Boredom alleviation and paycheck justification.
rjbwork 3y ago
Fire and Motion.
ChrisLTD 3y ago
I don't believe Server Components are a make-work scheme for React specialists, but they feel like a make-work scheme for React specialists.

mmmeff 3y ago

I had a junior on my team propose we switch our year old project to Next’s app router. After telling him no, I became concerned that I was becoming all the lead developers I’ve worked with in the past that shut me down and, at the time, seemed to be holding back innovation on our team. I get it now. I totally get it.

esskay 3y ago
I had a similar situation a year or two ago and since then have had several juniors complain that we're using "old tech" or missing out on the latest packages. I gave up trying to be understanding and reason with them. It just seems new developers, and especially frontend developers see a shiny new package every week and want to try it. Before we put a stop to it we were lumped with a handful of projects that were frankly awful, with a bunch of spaghetti javascript code written in the flavor of the week which wouldn't compile on anything except a very specific version of a bunch of packages, whilst pulling in close to a gigabyte of random dependancies that nobody had any kind of handle on from a security point of view.
- felipemnoa 3y ago
  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.
  - datavirtue 3y ago
    Adults should be present and in charge, yes.
- zaphirplane 3y ago
  The thing is a library usually advertises how they address a painful experience in other projects. That is the hello world fallacy, there is a blog about it. Basically you see how elegant or easy to do X in a new library but you don’t see how complicated it is to do Y. Y is complex in the new library and simple in your existing library
athesyn 3y ago
>I had a junior on my team propose we switch our year old project to Next’s app router. that doesn't sound like a big change.
- ovao 3y ago
  It’s quite a big change, depending on how many routes are in play. Migrating to App Router is non-trivial. Thankfully, the pages directory model is still just fine, so there’s no immense pressure for existing apps to migrate, and it can be done somewhat incrementally.
- recursive 3y ago
  Is that supposed to be an argument for or against doing it?

revskill 3y ago

RSC is broken if your library mutate the DOM tree after mounting.

drb999 3y ago

Reading this makes me think I guessed the right way going “all-in” on Remix vs Next. It was a guess, but it’s just so much more intuitive and web standards friendly, serverless friendly, browser friendly…

seandoe 3y ago
Yea, I've been using both and really like the direction of remix. Why did react become so intertwined with nextjs and obsessed with ssr? I wish react stayed focused as a light spa library we all learned and loved and let the ssr frameworks do their own thing.

crooked-v 3y ago

RSC feel like a poorly-documented 0.5 beta filled with endless breaking changes being pushed as default for some inexplicable reason.

baerrie 3y ago

As soon as React started suggesting using a framework for their framework, the writing was on the wall. Nested frameworks are like the private equity and financial sector, smoke and mirrors abstraction that delight some, offend others, and make a small group richer and richer. The churn of “progress” is exhausting man

fourseventy 3y ago
Its frameworks all the way down
fourseventy 3y ago
And the "progress" doesn't even materialize to anything concrete. Are websites really better in 2023 than in 2010? Are they faster to code? I would argue no for both points.

esskay 3y ago

[flagged]

z3t4 3y ago
The JS community is like two million developers. When thousands of developers are using butter as an hammer it will feel like a lot. but they are just a small fraction. the js community consist of both small and big warlords pushing their own agenda.

madeofpalk 3y ago

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.

shipscode 3y ago
Sounds like the initial hooks launch. A lot of goodwill was used up with that. It might look fine behind the desk at Meta on the React team, but on the ground on real world 2nd and 3rd rate dev teams the damage has been immense. You have entire teams of devs that can't understand useEffect for 2-3 years.. can't say that about pre-hook React.
- kaba0 3y ago
  As mentioned elsewhere, hooks have very little criticism from any remotely experienced developer who used them, as they are simply an easier/better mental model. It is probably also easier for that “2nd or 3rd rate dev”, unless it is a legacy project where pre-hook react is mixed with it arbitrarily (and God save us, not even the “seniors” know what to make of that)

shaunpersad 3y ago

IMO React started going off the rails when they introduced hooks. The number of concepts you needed to learn started growing, and the old intuitiveness of React began to go away. On top of that, there was a mad rush throughout the ecosystem to implement them, many times poorly, leading to more confusion. RSC seems to be history repeating itself.

imbnwa 3y ago
I think hooks made sense, as they gave React the last inch of control over the user call stack to make better, more uniform scheduling decisions; Solid.js demonstrates the idea more clearly in much more idiomatic JavaScript. However, their messaging and documentation were not at all clear for me at launch, to the point that I refused to interact with them for years. The rest though, yeah, I dunno
jauntywundrkind 3y ago
> 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.

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.

draw_down 3y ago

[dead]

lucidone 3y ago

Front end development doesn't have to be awful, particularly with how much JavaScript the language has improved alongside browser APIs. React made sense at one point because the abstractions it employed were common in other contexts: lifecycle events (intentionally avoiding the "hook" word here) are present pretty much everywhere in programming abstractions (on initialization, on deinitialization, on update, and so forth). These were aptly named "onComponentThing"s and grokable. Hooks, and particularly useEffect, ruined it for me. I have given up trying to understand why changing button states or presenting modals has become so obtuse and frustrating. I don't care about updating my react-router and rewriting it again for the third or fourth or whatever time. I don't want another new testing library, another new "best practice", or another repeated mistake in the reinventing-the-wheel-cycle the React community seems obsessed with. It's all so exhausting. I write Rails now with erb templates and some dumb javascript to toggle modals and change button colours. It's not cool but at least I can understand it six months later.

shipscode 3y ago
I'm in the same boat. Redux + Pre-Hook React was very legible & straightforward... Post hooks React is strong on theory but weak on substance, and I've gone to just jQuery and Python for my latest project. I did migrate my last project the barebones JS MVP -> React and regretted it immensely. It took about a month and didn't provide enough value to make it worth it.
- datavirtue 3y ago
  I tried to learn React during the transition. Thankfully I had the authority to nope-out after trying to build a few apps with it and running into nothing but tons of arguing online when trying to search for help on what I thought would be an easy five minute task: to find out the best way to track state in my app.
  - shipscode 3y ago
    Yeeeep. The arguing by clout chasers was the worst part.

bob1029 3y ago

How many of us are working on web applications that legitimately cannot be served as basic, server-side web forms with JS only as necessary for dynamic client-side UI (e.g. disabling buttons upon form submit)? How are things like SPA improving the end user's experience and/or adding value to the product? If you are struggling and want a no-bullshit stack, why not PHP or string interpolation in your favorite language? These approaches are easily more productive than anything that has come out over the last 5 years. All the excuses for why this won't work are almost certainly traceable back to ego/resume-driven development pressure rather than actual technical justifications. Bookmarking MDN and literally treating it like the web bible is the solution for most of this. You don't need a JS framework. You don't need a CSS framework. Definitely not as of 2023. Between big wins like grid & flexbox, I can't think of anything I absolutely need to vendor out anymore. Once you take the training wheels off and fall a few times, you will learn that this stuff isn't that scary. You can actually write javascript like "document.getElementById" and retain ownership over your soul. The next step is convincing your teammates of the same and then deciding upon some common patterns to follow that make it easier to collaborate. Put differently, let the frameworks evolve naturally over time. Don't force them in from the beginning.

synergy20 3y ago
There are many use cases where server components making no sense: 1. RESTful or API sites that just need a SPA to render 2. embedded boards that can never run node.js etc, there are millions or billions of them. 3. Eletron.js or React Native related applications, why do I need a next.js alike component involved at all? Mixing SPA with SSR into React makes thing unnecessarily complicated, can SSR be an opt-in component just like what it used to be, so us SPA users do not need know your yet another revolutionary goodies that everybody must love it or he/she has no clue what's the best right now? I switched from Vue to React, now it seems I must switch back as Vue still separates SSR from CSR, god knows how long will that stay.
AgentME 3y ago
I'm not sure you understand what React Server Components are if you think server-side web forms with only the necessary client-side JS is in opposition of it instead of being exactly what it's about.

deleted 3y ago

[deleted]

shipscode 3y ago

With the amount of bs I had to go through when they dropped Hooks, I'll never use shiny new tech from the React Team again. I'm sure there are thousands of devs who feel the same. I think the React Team will soon be faced with an Angular 2.0 style situation where they are forced to break class components, hooks, etc to get people to use new patterns. The number of people who will do it out of goodwill has had to have been diminished to a minority percentage of React enthusiasts. Personally, I just rock jQuery for my personal projects. I get the same dollar coming over the wire with a way faster time to live and reduced complexity.

andrewstuart 3y ago
>> when they dropped Hooks What? Gotta link?
- epalm 3y ago
  If you think they meant ‘dropped as in removed’, what I think they meant was ‘dropped as in introduced’.
  - andrewstuart 3y ago
    Yeah I guess “dropped” has opposite meanings.
postalrat 3y ago
Were you forced to use hooks? Or did other people prefer it?
leerob 3y ago
Class components still work in React, right?

andrewstuart 3y ago

It's disappointing the focus React has on server side. I feel like the project should have reorganised into the React Client project and the React Server Side project.

seandoe 3y ago
I share the same sentiment. I don't like this "in bed with nextjs" and obsessed with server-side thing. Server rendered apps have their place, but so do spas. Let the spa haters hate. You can make great, performant apps with strictly client side rendering. For some applications, it's the best choice.

jemmyw 3y ago

I really don't like the server side frontend rendering solutions. It's an added complexity especially if the app is served from a non JS backend - now you also have to run nodejs to prerender. Mainly it just seems like a lot of folk rush to implement this kind of optimization because it's cool rather than because it makes sense for your product and users.

leerob 3y ago

(I'm on the Next.js team) I appreciate Lenz's feedback and writing all of this down. I can empathize with how they and other library maintainers are feeling. There's more we can do on the Next.js side to help ease the transition (and this feedback will help us there, so thank you). One point of confusion in the community has been around client components. If server components are new and exciting, does that mean client components are bad and we shouldn't use them anymore? No, it's okay to continue using them, but definitely want to acknowledge that can be draining for library maintainers to have to deliver that message. The client/server evolution of React is still in the early innings, so maybe this will be less of an education issue going forward. Client components = able to use the existing React ecosystem. There's also some confusion about the React canary releases (https://react.dev/blog/2023/05/03/react-canaries https://react.dev/blog/2023/05/03/react-canaries). These features are ready for frameworks to adopt. The normal semver rules still apply for frameworks when they add experimental features (ideally behind flags). There is a separate experimental channel for React, that uses experimental features (like Server Actions). The infinite loop issue mentioned (marking a client component as `async`) now causes an ESLint error in Next.js. Appreciate all of the suggestions in the post. A good conversation to have!

deminature 3y ago
Today when creating a new next app, you get this: > Would you like to use App Router? (recommended) It seems like users shouldn't yet be funnelled by default into using RSC.

000ooo000 3y ago

I used React for about 5 years, pre-hooks. I thought it was good, felt productive using it (thanks MobX). I have been putting it on my resume, but I'm starting to think I should be avoiding React jobs because of this churn and grief in the ecosystem. Hooks was bad enough but RSC seems like strike 2. Have been using Lit.js in a hobby project and I'm really enjoying it. I'm not big on how stylesheets don't penetrate the shadow DOM but otherwise it just feels like I'm back writing heyday React.