I was ready to dismiss the article because the answer to the title question is an obvious “No”, as server components is not a breaking change. It’s optional. But the author addresses it and then makes a very good point.
> ”The introduction of React Server Components, unlike the Angular.js to Angular 2 transition, is not a breaking change. Existing single-page applications will still work with the latest version of React. Existing Next.js apps built with the Pages router will also work. So, the answer to the question "Is React having an Angular.js moment?" is "No".”
> ”So to the question "Is React harming its community by being too ambitious", I think the answer is "Yes"”
The article is very good and well worth the read. I am inclined to agree that this is a NextJS move, that goes against the interests of React developers, with the goal of locking React developers in their own services. The React team is on board with this and playing along. I think they shouldn’t.
I think the React team is responding to current trends. SPAs were super trendy. Once people started building them, they recognized that SPAs are much harder to optimize than the code for a single page. Next.js came in, and everyone has slowly been shifting to SSR.
If the react team doesn't react, other frameworks will eclipse them.
While I don't like the implementation details, I can see what they were going for. Encapsulating certain API calls behind the server adds a new layer of security that react didn't have before. It's good it is opt-in
Agree heavily with the article. As an app developer, I actively spend my time walking away from frameworks/languages/libraries that start mashing the server weirdly into client code. Each to their own but I think quasi-RPC implementations are a relic of the past.
Treating the network layer as an explicit abstraction to components just feels a better developer experience in the long run. The data abstractions are easier to reason about, and caching albeit always hard, is a lot easier to think about.
I don't even know _why_ React/Next is pushing Server Components. (Part of me wants to join the conspiratorial bandwagon like the author)
I've given server components with Next.js an honest try in my personal projects, and honestly, the pain of using them far outweighs the benefits.
I MUCH prefer the pattern of getServerSideProps seeding data on-page-load and working with it via context providers. The fact that data loaded in with server components cannot support reactivity of any kind means you have to litter your code with "use client" wrappers that take in their parent data as initial state, then introducing client reactivity on top.
That^ also means that any time you drop into "use client" you drop any SSR benefits anyway. I agree with a lot of this article that the transition feels forced, and I can't help but hope that Vercel commits to supporting pages style routing indefinitely.
Here's an example, the pattern makes it almost impossible to highlight a currently active route in a navbar. Literally a basic building block of web applications: https://github.com/vercel/next.js/issues/43704
Oh man as a non fe person this is so overwhelming. I just got the hang of page based routing in nextjs and I still feel like I am walking on eggshells. Frankly all I want is TO render a next/jsx page into a jinja style template that I can render with backend of choice (golang) while leaving some ajax loading on the page when needed. I don't need my entire application to be a single page (don't get me started on understanding routing). May be that's why I can't appreciate consumer apps.
Client component still get SSR benefits. They just happen to be included in your JS bundle. This makes sense in the context of your example – you do expect the active route link to change during a client-side navigation.
> So why is Next.js so pushy about it? (React server components)
> I can't avoid feeling that the new direction taken by Next.js is not designed to help developers, but to help Vercel sell React. You can't really sell a service around SPAs: once compiled, a SPA is a single JS file that can be hosted for free anywhere. But a server-side rendered app needs a server to run. And a server is a product that can be sold. Perhaps I'm a conspiracy theorist, but I don't see another reason to break the React ecosystem like this.
If I understand correctly, this server side component technology is strictly JavaScript (or maybe Typescript etc.), so how can it be marketed as a step forward compared to having the React pages interact with any kind of back end through reasonably standard web services?
Throwing away perfectly good backends and replacing them with new and relatively unproven JavaScript implies so much code churn, and novel deployment and management difficulties, that fatally bad downsides like the likelihood of crucifying the masochist hipster's application or site to specific cloud services seems a minor detail.
Is it simply a perversion that has been designed to appeal to exclusively JavaScript project of exclusively JavaScript programmers who have some hope of salvaging and porting already JavaScript business logic?
I’ve had this thought for a while. Companies like Vercel have coined the term “composable” but it really does feel like this is what is actually driving things.
Pretty much every app I've ever needed required an API, which meant a server, which meant Next.js would have been a viable candidate. Sure, there are use-cases that you truly don't need an API or you can just hook up to an existing one, but I don't think they're nearly as common.
If you think that way, you are not objectively weighing the benefits of server side rendering. It _is_ useful and shouldn't be tossed away for the benefits of a 6MB javascript blob.
I would argue it is quite similar to an Angular.js moment, even if it's not a breaking change.
> React suggests mixing server-side and client-side rendering, using what feels like black magic. You can use client components in server components, and vice versa.
This is reminiscent of hybrid Angular apps[1], which allows you to use both Angular.js and modern Angular components together and was introduced to help the upgrade from Angular.js to modern Angular. The only issue is the "black magic" there isn't as good as advertised and you'll run into many holes if working on a moderately complex hybrid Angular app.
I can only hope that the "black magic" for a mixed React app is more complete, though lack of documentation for the wire format that the author pointed out does not inspire confidence.
Interestingly enough, there is a picture of a tree of mix of components[2] on the Angular upgrade guide which parallels the one in tfa. It is basically why I think these scenarios mirror each other: an introduction to a new paradigm which can be used with the old one in a mixed/hybrid application (and a possible lack of documentation which will make that application terrible to maintain without fully transitioning to the new or old paradigm).
I tend to agree with the article. I've felt pretty frustrated with the direction of react in the last few years. Most of the companies I've worked for that used react did so because they wanted a SPA, in most cases making a conscious decision to move away from older SSR technologies towards the SPA.
It's doubly frustrating because we primarily use C# and Asp.Net Core for back end work. A react SPA is trivial to use with any back end of your choosing... this SSR push they're making isn't much fun unless you use a JS back end (no thanks).
Many have switched to a backend for frontend design (BFF). So you have another backend that proxies and/or uses the real backend and makes SSR and other frontend things.
This move seems like something that pleases nobody. There's a crowd that hates SPAs and a crowd that hates heavy react frameworks, and there's very little else. It seems like the number one critique of React is how bloated it has gotten and how much it reinvents the wheel.
Personally, I've always like React as a library for small interactive parts of your website. It's fairly trivial to make your site mostly static and use something like Asp.Net to handle how its rendered.
> React Server components require new generation routers, new generation bundlers. They are officially in alpha, and not ready for production. So why is Next.js so pushy about it? I can't avoid feeling that the new direction taken by Next.js is not designed to help developers, but to help Vercel sell React. You can't really sell a service around SPAs: once compiled, a SPA is a single JS file that can be hosted for free anywhere. But a server-side rendered app needs a server to run. And a server is a product that can be sold. Perhaps I'm a conspiracy theorist, but I don't see another reason to break the React ecosystem like this.
I think we as an industry underestimate the value of stability.
It's easy to always look at what isn't perfect and think, "Hey, we know better now, let's fix that", but what does more damage, architecture that isn't perfect or constant change?
It's hard to really get any momentum going when all the tooling changes every few years.
> I can't avoid feeling that the new direction taken by Next.js is not designed to help developers, but to help Vercel sell React. You can't really sell a service around SPAs: once compiled, a SPA is a single JS file that can be hosted for free anywhere. But a server-side rendered app needs a server to run. And a server is a product that can be sold. Perhaps I'm a conspiracy theorist, but I don't see another reason to break the React ecosystem like this.
Feels like this inevitably ends in a fork. It was a hell of a run though!
Vercel has raised an enormous amount of money and they are stuck with making bizarre choices like this or selling other tech brazenly for higher prices. That is why pg recommends not raising a huge round.
I think this is entirely a documentation and marketing issue at this point. React Server components are very new, probably new enough that most people should not use them unless they're very comfortable working on the bleeding edge.
The problem is that React points towards Nextjs as a default, and Nextjs makes Server Components the new default.
It doesn't actually change anything for anyone that still wants to develop a standard SPA. And these changes also don't seem to make any of the old methods obsolete, they simply add another method that you can use to develop web apps.
React has already through massive changes with emphasizing classes -> function components -> hooks.
OTOH it hasn't broken backwards compatibility.
I think Server Components are similar to the introduction of hooks because while they require changes to use, they don't affect anything if you aren't using them.
You could argue that it's such a massive change they should make it as a separate framework, but React's approach of adding new approaches but maintaining compatibility seems to have been fairly popular.
Maybe server side rendering isn't what everyone wants to do, but you don't have to. I think we can all agree that if they were FORCING everyone to change what they're doing and use server components it would be more of a problem?
There's another aspect to server components and server-side rendering in general: it makes sites less amenable to third-party front ends. The rise of client-side rendered "apps"/SPAs/etc. and the accompanying APIs made it much easier to develop third-party front ends since the data became available in easily-parsed JSON or XML. Server-side rendered sites need to be scraped, a process which is far less robust than API access. Given that many site owners are quite adverse to third-party front ends - just look at the Reddit kerfuffle for an example - this limitation may well be one of the intended features.
> You can't really sell a service around SPAs: once compiled, a SPA is a single JS file that can be hosted for free anywhere. But a server-side rendered app needs a server to run
I hate to break it to the author, but if you're going to limit yourself to apps that don't need a server, you're going to limit yourself to only building toys. The real world is messy because you can't pre-compile all your data into your single JS file ahead of time. Real-world apps need data stored in some kind of database, and some kind of server sitting in front of that database to validate access and present it in a format that can be used by the frontend.
Now, you can build that out in a different language, in a different repository, by a different team, behind a formal, stable API. At a certain scale, that's even preferable. But when you're building new products, when you're trying to find product-market fit, the truth is, API design is just another distraction that doesn't help you build value and just delays you from getting to market. What React Server Components does is allow developers to avoid API design. Sure, that doesn't scale, but in the beginning, you should be doing things that don't scale. Leaving aside the point that, if we're being honest, most developers don't know good API design anyway.
And no, just because Vercel is taking React in a server-first direction, doesn't mean everyone is being forced into using Vercel for hosting. You can self-host NextJS anywhere you can run Node or Docker: https://nextjs.org/docs/app/building-your-application/deploy... . Which you're probably hosting anyway, because again, in the real world, you need to put something between your frontend and your database. That thing just doesn't necessarily need to be an API.
since 2014 I was using angular.js.
Since feb 2016 I've started to use Angular 2, which were a release-candidate version back then and became a stable release just in oct-nov 2016!
So I don't know what the author means by "Just two years later (after 2012), the Angular team launched Angular 2" but it definitely doesn't smell good!!
soneca|2 years ago
> ”The introduction of React Server Components, unlike the Angular.js to Angular 2 transition, is not a breaking change. Existing single-page applications will still work with the latest version of React. Existing Next.js apps built with the Pages router will also work. So, the answer to the question "Is React having an Angular.js moment?" is "No".”
> ”So to the question "Is React harming its community by being too ambitious", I think the answer is "Yes"”
The article is very good and well worth the read. I am inclined to agree that this is a NextJS move, that goes against the interests of React developers, with the goal of locking React developers in their own services. The React team is on board with this and playing along. I think they shouldn’t.
mu53|2 years ago
If the react team doesn't react, other frameworks will eclipse them.
While I don't like the implementation details, I can see what they were going for. Encapsulating certain API calls behind the server adds a new layer of security that react didn't have before. It's good it is opt-in
lakomen|2 years ago
If they won't do it, they'll fall behind.
With Svelte I can render a reactive statically rendered website. Nothing to my knowledge can do that in the JS framework world.
thomasfromcdnjs|2 years ago
Treating the network layer as an explicit abstraction to components just feels a better developer experience in the long run. The data abstractions are easier to reason about, and caching albeit always hard, is a lot easier to think about.
I don't even know _why_ React/Next is pushing Server Components. (Part of me wants to join the conspiratorial bandwagon like the author)
paulddraper|2 years ago
Doesn't a backend API and frontend web/mobile clients just make so much sense?
scientaster2|2 years ago
I MUCH prefer the pattern of getServerSideProps seeding data on-page-load and working with it via context providers. The fact that data loaded in with server components cannot support reactivity of any kind means you have to litter your code with "use client" wrappers that take in their parent data as initial state, then introducing client reactivity on top.
That^ also means that any time you drop into "use client" you drop any SSR benefits anyway. I agree with a lot of this article that the transition feels forced, and I can't help but hope that Vercel commits to supporting pages style routing indefinitely.
Here's an example, the pattern makes it almost impossible to highlight a currently active route in a navbar. Literally a basic building block of web applications: https://github.com/vercel/next.js/issues/43704
flashgordon|2 years ago
vbello|2 years ago
thunderbong|2 years ago
> So why is Next.js so pushy about it? (React server components)
> I can't avoid feeling that the new direction taken by Next.js is not designed to help developers, but to help Vercel sell React. You can't really sell a service around SPAs: once compiled, a SPA is a single JS file that can be hosted for free anywhere. But a server-side rendered app needs a server to run. And a server is a product that can be sold. Perhaps I'm a conspiracy theorist, but I don't see another reason to break the React ecosystem like this.
HelloNurse|2 years ago
Throwing away perfectly good backends and replacing them with new and relatively unproven JavaScript implies so much code churn, and novel deployment and management difficulties, that fatally bad downsides like the likelihood of crucifying the masochist hipster's application or site to specific cloud services seems a minor detail.
Is it simply a perversion that has been designed to appeal to exclusively JavaScript project of exclusively JavaScript programmers who have some hope of salvaging and porting already JavaScript business logic?
dimmke|2 years ago
DangitBobby|2 years ago
aigoochamna|2 years ago
thdc|2 years ago
> React suggests mixing server-side and client-side rendering, using what feels like black magic. You can use client components in server components, and vice versa.
This is reminiscent of hybrid Angular apps[1], which allows you to use both Angular.js and modern Angular components together and was introduced to help the upgrade from Angular.js to modern Angular. The only issue is the "black magic" there isn't as good as advertised and you'll run into many holes if working on a moderately complex hybrid Angular app.
I can only hope that the "black magic" for a mixed React app is more complete, though lack of documentation for the wire format that the author pointed out does not inspire confidence.
Interestingly enough, there is a picture of a tree of mix of components[2] on the Angular upgrade guide which parallels the one in tfa. It is basically why I think these scenarios mirror each other: an introduction to a new paradigm which can be used with the old one in a mixed/hybrid application (and a possible lack of documentation which will make that application terrible to maintain without fully transitioning to the new or old paradigm).
[1] https://angular.io/guide/upgrade#how-ngupgrade-works
[2] https://angular.io/generated/images/guide/upgrade/dom.png
Merad|2 years ago
It's doubly frustrating because we primarily use C# and Asp.Net Core for back end work. A react SPA is trivial to use with any back end of your choosing... this SSR push they're making isn't much fun unless you use a JS back end (no thanks).
patates|2 years ago
A better explanation: https://blog.bitsrc.io/bff-pattern-backend-for-frontend-an-i...
datavirtue|2 years ago
Capricorn2481|2 years ago
Personally, I've always like React as a library for small interactive parts of your website. It's fairly trivial to make your site mostly static and use something like Asp.Net to handle how its rendered.
mrcwinn|2 years ago
Very happily using Phoenix LiveView these days.
throwaway290|2 years ago
I am already veering away from everything Vercel, didn't know RSC are so NextJS affiliated, this will certainly influence my library choices.
marviel|2 years ago
I mean, yeah, I see your point.
React should always be self-hostable, full-stop.
spicyusername|2 years ago
It's easy to always look at what isn't perfect and think, "Hey, we know better now, let's fix that", but what does more damage, architecture that isn't perfect or constant change?
It's hard to really get any momentum going when all the tooling changes every few years.
unknown|2 years ago
[deleted]
v0idzer0|2 years ago
Feels like this inevitably ends in a fork. It was a hell of a run though!
ilrwbwrkhv|2 years ago
ivanfeli|2 years ago
fabian2k|2 years ago
The problem is that React points towards Nextjs as a default, and Nextjs makes Server Components the new default.
It doesn't actually change anything for anyone that still wants to develop a standard SPA. And these changes also don't seem to make any of the old methods obsolete, they simply add another method that you can use to develop web apps.
Vanit|2 years ago
beezlewax|2 years ago
andrewmcwatters|2 years ago
resoluteteeth|2 years ago
OTOH it hasn't broken backwards compatibility.
I think Server Components are similar to the introduction of hooks because while they require changes to use, they don't affect anything if you aren't using them.
You could argue that it's such a massive change they should make it as a separate framework, but React's approach of adding new approaches but maintaining compatibility seems to have been fairly popular.
Maybe server side rendering isn't what everyone wants to do, but you don't have to. I think we can all agree that if they were FORCING everyone to change what they're doing and use server components it would be more of a problem?
soneca|2 years ago
the_third_wave|2 years ago
unknown|2 years ago
[deleted]
solatic|2 years ago
> You can't really sell a service around SPAs: once compiled, a SPA is a single JS file that can be hosted for free anywhere. But a server-side rendered app needs a server to run
I hate to break it to the author, but if you're going to limit yourself to apps that don't need a server, you're going to limit yourself to only building toys. The real world is messy because you can't pre-compile all your data into your single JS file ahead of time. Real-world apps need data stored in some kind of database, and some kind of server sitting in front of that database to validate access and present it in a format that can be used by the frontend.
Now, you can build that out in a different language, in a different repository, by a different team, behind a formal, stable API. At a certain scale, that's even preferable. But when you're building new products, when you're trying to find product-market fit, the truth is, API design is just another distraction that doesn't help you build value and just delays you from getting to market. What React Server Components does is allow developers to avoid API design. Sure, that doesn't scale, but in the beginning, you should be doing things that don't scale. Leaving aside the point that, if we're being honest, most developers don't know good API design anyway.
And no, just because Vercel is taking React in a server-first direction, doesn't mean everyone is being forced into using Vercel for hosting. You can self-host NextJS anywhere you can run Node or Docker: https://nextjs.org/docs/app/building-your-application/deploy... . Which you're probably hosting anyway, because again, in the real world, you need to put something between your frontend and your database. That thing just doesn't necessarily need to be an API.
filestorage|2 years ago
revskill|2 years ago
Longer story: I hate ALL-in-one framework/libraries.
I prefer separation of bundling, compiling, rendering,... . It's called the SRP principle.
unknown|2 years ago
[deleted]
baerrie|2 years ago
dagamerish|2 years ago
hoofhearted|2 years ago
We don’t really compare them apples to apples at work because they serve two different use cases.
peer2pay|2 years ago
Bilal_io|2 years ago