6 ms·

I remember when the point of an SPA was to not have all these elaborate conversations with the server. Just "here's the whole app, now only ask me for raw data

I remember when the point of an SPA was to not have all these elaborate conversations with the server. Just "here's the whole app, now only ask me for raw data."

tshaddox 11mo ago
That was indeed one of the main points of SPAs, but React Server Components are generally not used for pure SPAs.
- reactordev 11mo ago
  Correct, their main purpose is ecosystem lock-in. Because why return json when you can return html. Why even build a SPA when the old school model of server-side includes and PHP worked just fine? TS with koa and htmx if you must but server-side react components are kind of a waste of time. Give me one example where server side react components are the answer over a fetch and json or just fetching an html page?
  - tshaddox 11mo ago
    I like RSCs and mostly dislike SPAs, but I also understand your sentiment.
  - nawgz 11mo ago
    The only example that has any traction in my view are web-shops, which claim that time-to-render and time-to-interactivity are critical for customer retention. Surely there are not so many people building e-commerce sites that server components should have ever become so popular.
    - skydhash 11mo ago
      The thing is time to render and interactivity is much more reliant on the database queries and the internet connection of the user than anything else. Now instead of a spinner or a progress bar in the toolbar of the browser, now I got skeleton loaders and use half of GB for one tab.
      - nawgz 11mo ago
        Not to defend the practice, I’ve never partaken, but I think there’s some legit timing arguments that a server renderer can integrate more requests faster thanks to being collocated with services and dbs.
        reactordev 11mo ago
        which brings me back to my main point of the web 1.0 architecture. Serving pages from the server-side, where the data lives, and we've come full circle.
  - deleted 11mo ago
    [deleted]
- robertoandred 11mo ago
  Sure they are. Next sites are SPAs.
deleted 11mo ago
[deleted]
rustystump 11mo ago
It also decoupled fe and backend. You could use the same apis for say mobile, desktop and web. Teams didnt have to cross streams allowing for deeper expertise on each side. Now they are shoving server rendering into react native…
pjmlp 11mo ago
Until they discovered why so many of us have kept with server side rendering, and only as much JS as needed. Then they rediscovered PHP, Rails, Java EE/Spring, ASP.NET, and reboted SPAs into fullstack frameworks.
- sangeeth96 11mo ago
  > Then they rediscovered PHP, Rails, Java EE/Spring, ASP.NET, and reboted SPAs into fullstack frameworks. I can understand the dislike for Next but this is such a poor comparison. If any of those frameworks at any point did half the things React + Next-like frameworks accomplished and the apps/experiences we got since then, we wouldn't be having this discussion.
  - Atotalnoob 11mo ago
    Blazor? Razor pages?
  - brazukadev 11mo ago
    We are having this discussion because at some point, the people behind React decided it should be profitable and made it become the drug gateway for NextJS/Vercel
    - pjmlp 11mo ago
      Worse, because Vercel then started its marketing wave, thus many SaaS products only support React/Next.js as extensions points. Using anything else requires yak shaving instead of coding the application code. That is the only reason I get to use them.
  - deleted 11mo ago
    [deleted]
  - tacker2000 11mo ago
    How does Next accomplish more than a PHP/Ruby/whatever backend with a React frontend? If anything the latter is much easier to maintain and to develop for.
hedayet 11mo ago
I'd be interested in adopting a sole-purpose framework like that.
moomoo11 11mo ago
I think people just never understood SPA. Like with almost everything people then shit on something they don’t understand.
_jzlw 11mo ago
It's funny (in a "wtf" sort of way) how in C# right now, the new hotness Microsoft is pushing is Blazor Server, which is basically old-school .aspx Web Forms but with websockets instead of full page reloads. Every action, every button click, basically every input is sent to the server, and the changed dom is sent back to the client. And we're all just supposed to act like this isn't absolutely insane.
- c0balt 11mo ago
  Hotwire et al are also doing part of this. It isn't a new concept but it seems to come and go it terms of popularity
- McGlockenshire 11mo ago
  > And we're all just supposed to act like this isn't absolutely insane. This is insane to you only if you didn't experience the emergence of this technique 20-25 years ago. Almost all server-side templates were already partials of some sort in almost all the server-side environments, so why not just send the filled in partial? Business logic belongs on the server, not the client. Never the client. The instant you start having to make the client smart enough to think about business logic, you are doomed.
  - crubier 11mo ago
    > The instant you start having to make the client smart enough to think about business logic, you are doomed. Could you explain more here? What do you consider "business logic". Context: I have a client app to fly drone using gamepad, mouse and keyboard, and video feedback and maps, and drone tasking etc.
- CharlieDigital 11mo ago
  It's kinda nice. Main downside is the hot reload is not nearly as nice as TS. But the coding experience with a C# BE/stack is really nice for admin/internal tools.
- vbezhenar 11mo ago
  I saw this kind of interactivity in Apache Wicket Java framework. It's very interesting approach.
epolanski 11mo ago
Yeah, but then people started building bloated static websites with those libraries instead of using a saner template engine + javascript approach which is fast, easy to cache, debug, and has stellar performance and SEO. Little it helped that even React developers were saying that it was the wrong tool for plenty use cases. Worst of all? The entire nuance of choosing the right tool for the job has been long lost on most developers. Even the comments I read on HN make me question where the engineering part of the job starts.
- CodingJeebus 11mo ago
  It also doesn't help that non-technical stakeholders sometimes want a say in a tech stack conversation as well. I've been at more than one company where either the product team or the acquiring firm wanted us to migrate away from a tried and true Rails setup to a fullstack JS platform simply because they either wanted the UI development flexibility or to not have to hire Ruby devs. Non-technical MBA's seem to have a hard time grasping that a JS-only platform is not a panacea and comes with serious tradeoffs.

I remember when the point of an SPA was to not have all these elaborate conversations with the server. Just "here's the whole app, now only ask me for raw data."

tshaddox 11mo ago

That was indeed one of the main points of SPAs, but React Server Components are generally not used for pure SPAs.

reactordev 11mo ago
Correct, their main purpose is ecosystem lock-in. Because why return json when you can return html. Why even build a SPA when the old school model of server-side includes and PHP worked just fine? TS with koa and htmx if you must but server-side react components are kind of a waste of time. Give me one example where server side react components are the answer over a fetch and json or just fetching an html page?
- tshaddox 11mo ago
  I like RSCs and mostly dislike SPAs, but I also understand your sentiment.
- nawgz 11mo ago
  The only example that has any traction in my view are web-shops, which claim that time-to-render and time-to-interactivity are critical for customer retention. Surely there are not so many people building e-commerce sites that server components should have ever become so popular.
  - skydhash 11mo ago
    The thing is time to render and interactivity is much more reliant on the database queries and the internet connection of the user than anything else. Now instead of a spinner or a progress bar in the toolbar of the browser, now I got skeleton loaders and use half of GB for one tab.
    - nawgz 11mo ago
      Not to defend the practice, I’ve never partaken, but I think there’s some legit timing arguments that a server renderer can integrate more requests faster thanks to being collocated with services and dbs.
      - reactordev 11mo ago
        which brings me back to my main point of the web 1.0 architecture. Serving pages from the server-side, where the data lives, and we've come full circle.
- deleted 11mo ago
  [deleted]
robertoandred 11mo ago
Sure they are. Next sites are SPAs.

deleted 11mo ago

[deleted]

rustystump 11mo ago

It also decoupled fe and backend. You could use the same apis for say mobile, desktop and web. Teams didnt have to cross streams allowing for deeper expertise on each side. Now they are shoving server rendering into react native…

pjmlp 11mo ago

Until they discovered why so many of us have kept with server side rendering, and only as much JS as needed. Then they rediscovered PHP, Rails, Java EE/Spring, ASP.NET, and reboted SPAs into fullstack frameworks.

sangeeth96 11mo ago
> Then they rediscovered PHP, Rails, Java EE/Spring, ASP.NET, and reboted SPAs into fullstack frameworks. I can understand the dislike for Next but this is such a poor comparison. If any of those frameworks at any point did half the things React + Next-like frameworks accomplished and the apps/experiences we got since then, we wouldn't be having this discussion.
- Atotalnoob 11mo ago
  Blazor? Razor pages?
- brazukadev 11mo ago
  We are having this discussion because at some point, the people behind React decided it should be profitable and made it become the drug gateway for NextJS/Vercel
  - pjmlp 11mo ago
    Worse, because Vercel then started its marketing wave, thus many SaaS products only support React/Next.js as extensions points. Using anything else requires yak shaving instead of coding the application code. That is the only reason I get to use them.
- deleted 11mo ago
  [deleted]
- tacker2000 11mo ago
  How does Next accomplish more than a PHP/Ruby/whatever backend with a React frontend? If anything the latter is much easier to maintain and to develop for.

hedayet 11mo ago

I'd be interested in adopting a sole-purpose framework like that.

moomoo11 11mo ago

I think people just never understood SPA. Like with almost everything people then shit on something they don’t understand.

_jzlw 11mo ago

It's funny (in a "wtf" sort of way) how in C# right now, the new hotness Microsoft is pushing is Blazor Server, which is basically old-school .aspx Web Forms but with websockets instead of full page reloads. Every action, every button click, basically every input is sent to the server, and the changed dom is sent back to the client. And we're all just supposed to act like this isn't absolutely insane.

c0balt 11mo ago
Hotwire et al are also doing part of this. It isn't a new concept but it seems to come and go it terms of popularity
McGlockenshire 11mo ago
> And we're all just supposed to act like this isn't absolutely insane. This is insane to you only if you didn't experience the emergence of this technique 20-25 years ago. Almost all server-side templates were already partials of some sort in almost all the server-side environments, so why not just send the filled in partial? Business logic belongs on the server, not the client. Never the client. The instant you start having to make the client smart enough to think about business logic, you are doomed.
- crubier 11mo ago
  > The instant you start having to make the client smart enough to think about business logic, you are doomed. Could you explain more here? What do you consider "business logic". Context: I have a client app to fly drone using gamepad, mouse and keyboard, and video feedback and maps, and drone tasking etc.
CharlieDigital 11mo ago
It's kinda nice. Main downside is the hot reload is not nearly as nice as TS. But the coding experience with a C# BE/stack is really nice for admin/internal tools.
vbezhenar 11mo ago
I saw this kind of interactivity in Apache Wicket Java framework. It's very interesting approach.

epolanski 11mo ago

Yeah, but then people started building bloated static websites with those libraries instead of using a saner template engine + javascript approach which is fast, easy to cache, debug, and has stellar performance and SEO. Little it helped that even React developers were saying that it was the wrong tool for plenty use cases. Worst of all? The entire nuance of choosing the right tool for the job has been long lost on most developers. Even the comments I read on HN make me question where the engineering part of the job starts.

CodingJeebus 11mo ago
It also doesn't help that non-technical stakeholders sometimes want a say in a tech stack conversation as well. I've been at more than one company where either the product team or the acquiring firm wanted us to migrate away from a tried and true Rails setup to a fullstack JS platform simply because they either wanted the UI development flexibility or to not have to hire Ruby devs. Non-technical MBA's seem to have a hard time grasping that a JS-only platform is not a panacea and comes with serious tradeoffs.