24 ms·

Is React Having an Angular.js Moment?

114 points by Ins43b 3y ago

hoofhearted 3y ago
React is a component library, Angular is a framework. We don’t really compare them apples to apples at work because they serve two different use cases.
- Bilal_io 3y ago
  The author is talking about Angular.js, which the legacy version 1.x, and not the modern Angular 2+.
- peer2pay 3y ago
  This is a heavily outdated opinion. The "default" react experience nowadays is Next.js and that is definitely a framework not a library.
  - Capricorn2481 3y ago
    Agreed, although NextJS is still a lot lighter to me than angular
  - hoofhearted 3y ago
    React is a component library. Angular.js is a framework. Next.js is also a framework. Comparing apples to apples, then you should compare Angular.js to Next.js, and not React.
    - filestorage 3y ago
      Isn't next.js a server side framework? How can you compare server side framework with frontend framework? It's the same (silly) way you'd compare PHP with HTML!
    - ttfkam 3y ago
      React is a component library. Next.js is a framework. Angular is both a component library AND a framework.
revskill 3y ago
It's a good thing. React team needs to keep up and keep fighting on the performance story. Longer story: I hate ALL-in-one framework/libraries. I prefer separation of bundling, compiling, rendering,... . It's called the SRP principle.
- deleted 3y ago
  [deleted]
fabian2k 3y ago
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.
scientaster2 3y ago
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 https://github.com/vercel/next.js/issues/43704
- vbello 3y ago
  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.
  - fabian2k 3y ago
    That's kind of a really "meh" thing if you develop web applications and not websites. The static parts aren't that large, and the app kinda useless until the dynamic parts are there. So that doesn't really justify additional effort.
    - vbello 3y ago
      What additional effort?
- flashgordon 3y ago
  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.
spicyusername 3y ago
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.
- deleted 3y ago
  [deleted]
thomasfromcdnjs 3y ago
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)
- paulddraper 3y ago
  I don't get it either. Doesn't a backend API and frontend web/mobile clients just make so much sense?
resoluteteeth 3y ago
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?
- soneca 3y ago
  I think, right now, they are nudging everyone to change. And if there is no pushback, like this article, in an year or two they will be forcing.
  - deleted 3y ago
    [deleted]
  - patates 3y ago
    They never made such a forced (big) breaking change. I don't have a reason to think they would in a year or two.
marviel 3y ago
> 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 mean, yeah, I see your point. React should always be self-hostable, full-stop.
Merad 3y ago
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).
- patates 3y ago
  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. A better explanation: https://blog.bitsrc.io/bff-pattern-backend-for-frontend-an-introduction-e4fa965128bf https://blog.bitsrc.io/bff-pattern-backend-for-frontend-an-i...
  - datavirtue 3y ago
    Horrid dev experience.
  - Merad 3y ago
    I totally get that it's possible, but it's completely unnecessary complexity for both deployed apps and local dev. If the react team tells us that we have to jump through these extra hoops to use react*, my response will probably be to move to a different front end framework. And I say this as someone who honestly really likes react and who never really cared for front end work prior to learning react. * I'm aware that server components aren't required, and probably won't be in the near future. But the way they're being pushed ATM they're likely to become the de facto standard, similar to how functional components and hooks have completely displaced class components even though the latter is still officially supported.
  - deleted 3y ago
    [deleted]
- Capricorn2481 3y ago
soneca 3y ago
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.
- mu53 3y ago
  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
  - boringuser2 3y ago
    I've never seen the use-case. If you're building trivial brochure pages that need SSR for adsense, you shouldnt be using react at all. If you're building complex apps, it doesn't really make much sense to put the burden of rendering on your server.
    - mu53 3y ago
      A lot of companies depend on search indexing from google and other platforms. E-Commerce, blogs, and trivial information websites all need their traffic to come from somewhere. If you were going to dynamically render the page anyways, why not do it in node with the best UI framework out there right now? The burden isn't that much when you put a caching CDN in front of it.
mrcwinn 3y ago
Having experienced Vercel enterprise sales, I can confirm they are indeed the Death Star and will inadvertently destroy React. Very happily using Phoenix LiveView these days.
- throwaway290 3y ago
  Curious to know more about their sales... I am already veering away from everything Vercel, didn't know RSC are so NextJS affiliated, this will certainly influence my library choices.
thunderbong 3y ago
From the article (italics mine) - > 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.
- dimmke 3y ago
  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.
- aigoochamna 3y ago
  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.
  - 8n4vidtmkvmk 3y ago
    You can do better than a 6MB blob. You can code split and cache. It's not that bad. Especially if it's an app, not an SEO site.
    - aigoochamna 3y ago
      A 6MB blob is identical to 2MB, 1MB and 3MB blobs.
      - erhaetherth 3y ago
        Not quite. 1. They can potentially be downloaded and parsed in parallel 2. They can be invalidated independently, meaning on your next visit you may only need to re-DL the 1MB blob instead of the whole thing 3. Not every page will need all 3 blobs, you might only need the 2MB blob to load the homepage which means it'll load a little bit quicker. Then you can either load the next blob on the next click, or start downloading it in the background so the next click is nearly instant 4. You can do this not just between pages, but progressively within a single page. Render part of the UI, wait for the 2nd blob, then render the components that need that bit.
the_third_wave 3y ago
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.
Vanit 3y ago
React Server Components remind me of inline PHP with html. Wasn't a good idea then. Not a good idea now.
- beezlewax 3y ago
  They literally make this comparison in the next docs somewhere
  - beezlewax 3y ago
    https://nextjs.org/docs/getting-started/react-essentials#why-server-components https://nextjs.org/docs/getting-started/react-essentials#why...
baerrie 3y ago
Tldr, React is overcomplicating things like Angular did
- dagamerish 3y ago
  While Angular is simplifying things now
thdc 3y ago
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). [1] https://angular.io/guide/upgrade#how-ngupgrade-works https://angular.io/guide/upgrade#how-ngupgrade-works [2] https://angular.io/generated/images/guide/upgrade/dom.png https://angular.io/generated/images/guide/upgrade/dom.png
deleted 3y ago
[deleted]
andrewmcwatters 3y ago
Having? Had. React <16.8 (Class Components) and React >=16.8 (Hooks) are "React.js" and "React 2."
solatic 3y ago
The author just doesn't get it. > 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/deploying#self-hosting 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 3y ago
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!!
v0idzer0 3y ago
> 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!
- ivanfeli 3y ago
  I don't get this argument. Who says the server needs to be Vercel. You can just npm run start on any hosting provider.
- ilrwbwrkhv 3y ago
  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.

114 points by Ins43b 3y ago

React is a component library, Angular is a framework. We don’t really compare them apples to apples at work because they serve two different use cases.

Bilal_io 3y ago
The author is talking about Angular.js, which the legacy version 1.x, and not the modern Angular 2+.
peer2pay 3y ago
This is a heavily outdated opinion. The "default" react experience nowadays is Next.js and that is definitely a framework not a library.
- Capricorn2481 3y ago
  Agreed, although NextJS is still a lot lighter to me than angular
- hoofhearted 3y ago
  React is a component library. Angular.js is a framework. Next.js is also a framework. Comparing apples to apples, then you should compare Angular.js to Next.js, and not React.
  - filestorage 3y ago
    Isn't next.js a server side framework? How can you compare server side framework with frontend framework? It's the same (silly) way you'd compare PHP with HTML!
  - ttfkam 3y ago
    React is a component library. Next.js is a framework. Angular is both a component library AND a framework.

revskill 3y ago

It's a good thing. React team needs to keep up and keep fighting on the performance story. Longer story: I hate ALL-in-one framework/libraries. I prefer separation of bundling, compiling, rendering,... . It's called the SRP principle.

deleted 3y ago
[deleted]

fabian2k 3y ago

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.

scientaster2 3y ago

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 https://github.com/vercel/next.js/issues/43704

vbello 3y ago
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.
- fabian2k 3y ago
  That's kind of a really "meh" thing if you develop web applications and not websites. The static parts aren't that large, and the app kinda useless until the dynamic parts are there. So that doesn't really justify additional effort.
  - vbello 3y ago
    What additional effort?
flashgordon 3y ago
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.

spicyusername 3y ago

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.

deleted 3y ago
[deleted]

thomasfromcdnjs 3y ago

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)

paulddraper 3y ago
I don't get it either. Doesn't a backend API and frontend web/mobile clients just make so much sense?

resoluteteeth 3y ago

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?

soneca 3y ago
I think, right now, they are nudging everyone to change. And if there is no pushback, like this article, in an year or two they will be forcing.
- deleted 3y ago
  [deleted]
- patates 3y ago
  They never made such a forced (big) breaking change. I don't have a reason to think they would in a year or two.

marviel 3y ago

> 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 mean, yeah, I see your point. React should always be self-hostable, full-stop.

Merad 3y ago

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).

patates 3y ago
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. A better explanation: https://blog.bitsrc.io/bff-pattern-backend-for-frontend-an-introduction-e4fa965128bf https://blog.bitsrc.io/bff-pattern-backend-for-frontend-an-i...
- datavirtue 3y ago
  Horrid dev experience.
- Merad 3y ago
  I totally get that it's possible, but it's completely unnecessary complexity for both deployed apps and local dev. If the react team tells us that we have to jump through these extra hoops to use react*, my response will probably be to move to a different front end framework. And I say this as someone who honestly really likes react and who never really cared for front end work prior to learning react. * I'm aware that server components aren't required, and probably won't be in the near future. But the way they're being pushed ATM they're likely to become the de facto standard, similar to how functional components and hooks have completely displaced class components even though the latter is still officially supported.
- deleted 3y ago
  [deleted]
Capricorn2481 3y ago

soneca 3y ago

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.

mu53 3y ago
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
- boringuser2 3y ago
  I've never seen the use-case. If you're building trivial brochure pages that need SSR for adsense, you shouldnt be using react at all. If you're building complex apps, it doesn't really make much sense to put the burden of rendering on your server.
  - mu53 3y ago
    A lot of companies depend on search indexing from google and other platforms. E-Commerce, blogs, and trivial information websites all need their traffic to come from somewhere. If you were going to dynamically render the page anyways, why not do it in node with the best UI framework out there right now? The burden isn't that much when you put a caching CDN in front of it.

mrcwinn 3y ago

Having experienced Vercel enterprise sales, I can confirm they are indeed the Death Star and will inadvertently destroy React. Very happily using Phoenix LiveView these days.

throwaway290 3y ago
Curious to know more about their sales... I am already veering away from everything Vercel, didn't know RSC are so NextJS affiliated, this will certainly influence my library choices.

thunderbong 3y ago

From the article (italics mine) - > 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.

dimmke 3y ago
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.
aigoochamna 3y ago
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.
- 8n4vidtmkvmk 3y ago
  You can do better than a 6MB blob. You can code split and cache. It's not that bad. Especially if it's an app, not an SEO site.
  - aigoochamna 3y ago
    A 6MB blob is identical to 2MB, 1MB and 3MB blobs.
    - erhaetherth 3y ago
      Not quite. 1. They can potentially be downloaded and parsed in parallel 2. They can be invalidated independently, meaning on your next visit you may only need to re-DL the 1MB blob instead of the whole thing 3. Not every page will need all 3 blobs, you might only need the 2MB blob to load the homepage which means it'll load a little bit quicker. Then you can either load the next blob on the next click, or start downloading it in the background so the next click is nearly instant 4. You can do this not just between pages, but progressively within a single page. Render part of the UI, wait for the 2nd blob, then render the components that need that bit.

the_third_wave 3y ago

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.

Vanit 3y ago

React Server Components remind me of inline PHP with html. Wasn't a good idea then. Not a good idea now.

beezlewax 3y ago
They literally make this comparison in the next docs somewhere
- beezlewax 3y ago
  https://nextjs.org/docs/getting-started/react-essentials#why-server-components https://nextjs.org/docs/getting-started/react-essentials#why...

baerrie 3y ago

Tldr, React is overcomplicating things like Angular did

dagamerish 3y ago
While Angular is simplifying things now

thdc 3y ago

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). [1] https://angular.io/guide/upgrade#how-ngupgrade-works https://angular.io/guide/upgrade#how-ngupgrade-works [2] https://angular.io/generated/images/guide/upgrade/dom.png https://angular.io/generated/images/guide/upgrade/dom.png

deleted 3y ago

[deleted]

andrewmcwatters 3y ago

Having? Had. React <16.8 (Class Components) and React >=16.8 (Hooks) are "React.js" and "React 2."

solatic 3y ago

The author just doesn't get it. > 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/deploying#self-hosting 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 3y ago

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!!

v0idzer0 3y ago

> 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!

ivanfeli 3y ago
I don't get this argument. Who says the server needs to be Vercel. You can just npm run start on any hosting provider.
ilrwbwrkhv 3y ago
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.