5 ms·

The enthusiasm for RSCs mystifies me. Yes, SSR is a thing that is useful for building websites. It is not useful, at all for building apps. Apps (as in, mobil

The enthusiasm for RSCs mystifies me. Yes, SSR is a thing that is useful for building websites. It is not useful, at all for building apps. Apps (as in, mobile apps) cannot be rendered on the sever. You need an api. Unless you plan not to have an app, why would you choose to build your website in a way that is inconsistent with your design patterns, api design, etc. for you app. Fundamentally, there is a parity between a javascript client to an api and a mobile client to an api. The api can be implemented in anything. You consume the api in an application. The application runs on the client device. SSR is an optimisation for the web side of this, that forces you to use a node/js implementation for at least part of your backend, and mixes (eg. In blazor) where the application logic lives. There’s no question the next.js RSC will do exactly the same thing; a blending of logic that means you don’t need an api, you just have a site. …but you do need an api. Because unless you’re crazy, you need an app. I don’t care about ideals and what ifs; that’s the blunt reality for most companies. It’s weird. I bet that this is going to be a fad, and before you know it, people will use it because it’s “recommended” and then it’ll be a lot of complaints once they realise it’s actually quite problematic.

J_tt 3y ago
It’d be nice to see continued adoption if only to make things searchable when prerendered. Locking data behind an API with a requisite auth token means discoverability goes away. But sadly I think that era has come to an end, with every content company scrambling to lock data away to levy a fee for LLM training.
twodave 3y ago
I’ve found SSR is best when it’s just _one_ way data might be loaded in an app. If I use SSR at all it’s to initialize a page. You’re right that you need a separate API either way. I would think of the SSR host as a backend specifically for your web application. It shouldn’t do anything from a data standpoint that can’t also be accomplished via XHR, but it may layer some other things (like auth/cookies) on a top to provide a better/more secure web experience.
sickcodebruh 3y ago
Not everyone needs an app. I’d argue that most products don’t need an app and would be better off with a fast website or web app that is responsive. A good responsive web app will work on all devices and let you avoid the boundaries of the Apple and Google stores. You’ll reach more people faster, ship updates faster, engage with more open source tools, and benefit from the constant arms race that is improving performance of browsers. If anything, the need for everything to have an app or be a SPA is a fad. The complexity felt by every tiny team and product who thinks they must have multiple languages and deployment pipelines and microservices just because $BIGTECH does it is tragic. I’ve been a professional React developer for years, I love React and I have primarily built complex SPAs that truly required this technology, but I’ve also seen so many companies and people pouring energy into APIs and SPAs and apps that just should have been nice web sites sprinkled with JavaScript. RSC is right at home with the countless server-rendered frameworks that were born before the “API ALL THE THINGS!” era. I’m building a product right now and it feels like being back in Rails, except I have TypeScript and I can drop into a client component at any time. And I can build an API endpoint when I need to for views that absolutely must have that SPA feel, since sometimes you do need that. Or ask anyone working with Phoenix LiveView, or modern Rails with Hotwire, or folks building in Django with htmx. The orthodoxy of “you must have an app” can’t be put to bed fast enough.
- gochi 3y ago
  I fundamentally disagree with this. There is zero logical reason why everyone cannot have an app. We create unintentional barriers to such for no real logical reason. Web apps are an example of this!
  - SamBam 3y ago
    So I need to have as many apps as the number of websites I visit in a month? Hacker news, Reddit, NY Times, other news sites, BoingBoing, my kids' school, each restaurant, each airline I might ever book, Craigslist, etc etc etc? That's ridiculous. Browsers exist for a reason.
    - 3y ago
cageface 3y ago
For a lot of things you don't need an app. A responsive website, maybe with some PWA features, is good enough. Building and maintaining a separate API and a mobile app is a huge amount of work. The pendulum is swinging back from building everything as an SPA to a mix of server-rendered and client side content. It will probably overcorrect as things tend to do in software but the trend makes sense.
rscrawfo 3y ago
Completely agree, but I’ll through in two more reasons. Debug ability. It’s so helpful being able to isolate the network layer and treat each layer independently. State ownership. It’s nice to know that this is client side state, or this server side state. RSC obscures this. Honestly I feel like the hype is mainly so people can avoid http requests.
deleted 3y ago
[deleted]
fouc 3y ago
For those not familiar with React: RSC = React Server Component. SSR in the React world is ultimately only used on initial page load, until the front-end client is fully hydrated. RSCs are rendered on server side, useful for components that rely on backend data. This also reduces front-end bundle sizes, as any rendering dependencies for RSCs are kept on the backend.
brap 3y ago
You can have your cake and eat it too. You can have an API that handles all the important stuff (authn, authz, database access, 3P services...). Your mobile/desktop/CLI/smart toaster apps can speak directly to that. For the web, you can additionally have a web server that just serves HTML/CSS/JS, pre-rendered or not. This server can act as just another client "app", i.e, access the API on behalf of users. No special treatment, no business logic, just a dumb HTML shooter. And definitely no secret tokens.
robertoandred 3y ago
What? You can still use an api with server components.
- wokwokwok 3y ago
  …have you used next? https://nextjs.org/docs/app/building-your-application/data-fetching/forms-and-mutations https://nextjs.org/docs/app/building-your-application/data-f... Spoiler: you don’t get an api.
  - deleted 3y ago
    [deleted]
  - opes 3y ago
    From those same docs, it appears you can build an API with Route Handlers when using Server Components: https://nextjs.org/docs/app/building-your-application/routing/route-handlers https://nextjs.org/docs/app/building-your-application/routin...
    - leerob 3y ago
      Correct. It can also run during the build, so it can be used to dynamically generated .txt, .json, or any other files. Great when deploying a static export of Next.js and dumping on S3 or similar. https://nextjs.org/docs/app/building-your-application/deploying/static-exports https://nextjs.org/docs/app/building-your-application/deploy...
  - robertoandred 3y ago
    Do you know what an api is?
Akronymus 3y ago
> It is not useful, at all for building apps. Apps (as in, mobile apps) cannot be rendered on the sever. You need an api. Pretty sure that's the whole point of htmx.
willsmith72 3y ago
Technically you can still use an API in your server components. But this is what I love about Remix. You write your server and client code in the same place, but the server code is just an api, so can be reused directly.
- SwiftyBug 3y ago
  I'm building my first project with Remix. I was very surprised when I found out that I can have an API route just by adding a `export function action() { return json({ message: "it just works!" }) }` in a regular route file. Things are so simple with Remix.
Jcampuzano2 3y ago
Have you ever considered that Next.js can simply be a layer only used by your web client that just consumes your API's? That or you can write API routes in Next.js yourself that can be used by your apps if you choose. I really don't understand the claim you're making when nothing about uses Next prohibits you from having an API. It is exactly what you say, an optimization/use case for web clients. But nothing about this prohibits other clients from doing their own thing consuming the exact same api's if you choose to do so.
- nwienert 3y ago
  Why would you choose then to have two completely different ways of managing data? It’s insanity. It’s like saying “you can totally use kubernetes to deploy your app and then later switch to swarm and support both!” (And even that analogy doesn’t capture the ridiculousness of doing this, as in that case you’re mostly changing higher level glue code, whereas with RSC your actual data management code would be totally different). Yea, technically you could, but why choose something far more complex that actually actively makes your app like experience worse? Apps want to handle data local-first, offline-first, with optimistic mutations, cached data between screens, instant animations with interactions between screens, etc. The ideal data model for this is something like firebase, parse, graphql, tinybase, etc. So now some bozo on your team bought into the hype and blindly wants to shove RSC into it and you’ve completely ruined the elegance of your stack. Instead of having a single codebase with a single abstraction for data fetching that’s clearly better than server-first, you now have two abstractions, and the server based one ruins all the things that make apps better than sites. It also doesn’t make anything faster for web. You can avoid shipping some JS without RSC, the React team just decided for some reason to couple avoiding sending parts of the tree with a whole new data fetching model, a complete self-own and big mistake. It’s no wonder Vercel the server selling company loves them.
  - Jcampuzano2 3y ago
    But its not two "completely separate ways"? Your data management code is not completely different at all. If you want to, do it all in your API and next.js just calls through to it. And then call fetch in your components to the same API you would in a normal client app. The only difference is now those fetch calls happen on a server in RSC's or w/e rather than from the client directly. I'm honestly not even arguing for the hype since I don't use Next.js myself for any production projects at this time, I was simply pointing out that its not as if choosing to use it automatically means you can't use an API which is what the grandparent makes it seem like with their rant about still needing an API. There are some teams that truly do want a server rendered app that Next.js provides as well as other features. They can use it for that if they so choose. I'm honestly not even arguing RSC's are better or not because I know there are tradeoffs on both ends and we don't use them ourselves at where I work. Like I said, I was just poiting out it isn't a simple one or the other. There are plenty of teams out there that use a backend for frontend architecture that basically is a data transformation layer for their API to clients. For your web stack that could be next.js.
mkleczek 3y ago
If by "an API" you mean "JSON sent over the network" then I don't really see too much of an advantage in: database -> server side program -> JSON -> network -> client side program -> HTML -> browser renderer over database -> server side program -> HTML -> network -> browser renderer
- jfengel 3y ago
  The main advantage is when you have degraded connectivity. Your client app behaves like an app (or app-like web site).
vikramkr 3y ago
Are apps actually still that important? Id be surprised if more than a low single digit of new webapp projects would want to develop an app at some point instead of just having a mobile optimized website. Especially b2b
3np 3y ago
While I think I'd agree with your argument for many projects out there (YAGNI), there are some cases where I think it makes sense. Consider a product or article catalogue with search/filtering/ordering/pagination. This is something that can make sense to do in a SPA while you want it to degrade gracefully and work for clients without JS (including SEO). Or for that matter, a Discourse/Reddit-like discussion board?
uryga 3y ago
> Apps (as in, mobile apps) cannot be rendered on the sever yes and no. sure, you can't do standard SSR like for websites. but i've seen a number of spins[1] on "Server-driven UI", meaning "server defines the app views as a big blob of JSON". usually, it's payload looking something like this: [ { "type": "Heading", "text": "Our cool products" }, { "type": "List", "children": [ { "type": "ProductCard", "id": 123, }, { "type": "ProductCard", "id": 456, } ... ] } ] the app "interprets" this and displays the corresponding components in the specified arrangement. the kicker is that, in a sense, RSC is just a less ad-hoc way to do this kind of thing! instead of `type` tags you get "client references", React handles the relevant parsing/serialization, and a lot of other good stuff on top. it's also quite seamless w.r.t writing components -- react does a very good job of abstracting away all the serialization business. and importantly, you can have an actual ecosystem of RSC packages around it, which a bespoke in-house method of doing this won't have. now, RSC for react native has barely even been teased, but i'll bet good money that they have at least a prototype somewhere. and yeah, of course this would require your app to be in React Native. but that's the selling point -- IF all your stuff is in react, you get a bunch of power and some good DX. --- [1] some examples off the top of my head: - Facebook (not public, described by an employee): https://twitter.com/acdlite/status/1632217463772393473 https://twitter.com/acdlite/status/1632217463772393473 - AirBnb: https://medium.com/airbnb-engineering/a-deep-dive-into-airbnbs-server-driven-ui-system-842244c5f5 https://medium.com/airbnb-engineering/a-deep-dive-into-airbn... - a Polish site called allegro.pl, though I can't find the conf talk about it right now...
EngVagabond 3y ago
Disclaimer, I’m one of the EMs for React at Meta, and spent many years directly working on React Native. > It is not useful, at all for building apps. Apps (as in, mobile apps) cannot be rendered on the sever. You need an api. Yet. React Server Components as a pattern and paradigm are not unique to web sites and the team has designed it with React Native in mind. We are just starting with web to flesh out the ideas and work with the ecosystem first. RSCs (and SSR) are both technologies totally possible to use with RN, theoretically, we just haven’t built out the support yet. At the most basic, instead of rendering to HTML that the server sends down, it would render to commands that React Native’s native code would execute. Similar to the distinction between React DOM and React Native. So we are excited about these technologies even though they are currently web only, and it’ll still be a while until we bring them to React Native. Evan Bacon from Expo also experimented with RSC for React Native: https://x.com/baconbrix/status/1629909713910480898?s=46 https://x.com/baconbrix/status/1629909713910480898?s=46

J_tt 3y ago

It’d be nice to see continued adoption if only to make things searchable when prerendered. Locking data behind an API with a requisite auth token means discoverability goes away. But sadly I think that era has come to an end, with every content company scrambling to lock data away to levy a fee for LLM training.

twodave 3y ago

I’ve found SSR is best when it’s just _one_ way data might be loaded in an app. If I use SSR at all it’s to initialize a page. You’re right that you need a separate API either way. I would think of the SSR host as a backend specifically for your web application. It shouldn’t do anything from a data standpoint that can’t also be accomplished via XHR, but it may layer some other things (like auth/cookies) on a top to provide a better/more secure web experience.

sickcodebruh 3y ago

Not everyone needs an app. I’d argue that most products don’t need an app and would be better off with a fast website or web app that is responsive. A good responsive web app will work on all devices and let you avoid the boundaries of the Apple and Google stores. You’ll reach more people faster, ship updates faster, engage with more open source tools, and benefit from the constant arms race that is improving performance of browsers. If anything, the need for everything to have an app or be a SPA is a fad. The complexity felt by every tiny team and product who thinks they must have multiple languages and deployment pipelines and microservices just because $BIGTECH does it is tragic. I’ve been a professional React developer for years, I love React and I have primarily built complex SPAs that truly required this technology, but I’ve also seen so many companies and people pouring energy into APIs and SPAs and apps that just should have been nice web sites sprinkled with JavaScript. RSC is right at home with the countless server-rendered frameworks that were born before the “API ALL THE THINGS!” era. I’m building a product right now and it feels like being back in Rails, except I have TypeScript and I can drop into a client component at any time. And I can build an API endpoint when I need to for views that absolutely must have that SPA feel, since sometimes you do need that. Or ask anyone working with Phoenix LiveView, or modern Rails with Hotwire, or folks building in Django with htmx. The orthodoxy of “you must have an app” can’t be put to bed fast enough.

gochi 3y ago
I fundamentally disagree with this. There is zero logical reason why everyone cannot have an app. We create unintentional barriers to such for no real logical reason. Web apps are an example of this!
- SamBam 3y ago
  So I need to have as many apps as the number of websites I visit in a month? Hacker news, Reddit, NY Times, other news sites, BoingBoing, my kids' school, each restaurant, each airline I might ever book, Craigslist, etc etc etc? That's ridiculous. Browsers exist for a reason.
  - 3y ago

cageface 3y ago

For a lot of things you don't need an app. A responsive website, maybe with some PWA features, is good enough. Building and maintaining a separate API and a mobile app is a huge amount of work. The pendulum is swinging back from building everything as an SPA to a mix of server-rendered and client side content. It will probably overcorrect as things tend to do in software but the trend makes sense.

rscrawfo 3y ago

Completely agree, but I’ll through in two more reasons. Debug ability. It’s so helpful being able to isolate the network layer and treat each layer independently. State ownership. It’s nice to know that this is client side state, or this server side state. RSC obscures this. Honestly I feel like the hype is mainly so people can avoid http requests.

deleted 3y ago

[deleted]

fouc 3y ago

For those not familiar with React: RSC = React Server Component. SSR in the React world is ultimately only used on initial page load, until the front-end client is fully hydrated. RSCs are rendered on server side, useful for components that rely on backend data. This also reduces front-end bundle sizes, as any rendering dependencies for RSCs are kept on the backend.

brap 3y ago

You can have your cake and eat it too. You can have an API that handles all the important stuff (authn, authz, database access, 3P services...). Your mobile/desktop/CLI/smart toaster apps can speak directly to that. For the web, you can additionally have a web server that just serves HTML/CSS/JS, pre-rendered or not. This server can act as just another client "app", i.e, access the API on behalf of users. No special treatment, no business logic, just a dumb HTML shooter. And definitely no secret tokens.

robertoandred 3y ago

What? You can still use an api with server components.

wokwokwok 3y ago
…have you used next? https://nextjs.org/docs/app/building-your-application/data-fetching/forms-and-mutations https://nextjs.org/docs/app/building-your-application/data-f... Spoiler: you don’t get an api.
- deleted 3y ago
  [deleted]
- opes 3y ago
  From those same docs, it appears you can build an API with Route Handlers when using Server Components: https://nextjs.org/docs/app/building-your-application/routing/route-handlers https://nextjs.org/docs/app/building-your-application/routin...
  - leerob 3y ago
    Correct. It can also run during the build, so it can be used to dynamically generated .txt, .json, or any other files. Great when deploying a static export of Next.js and dumping on S3 or similar. https://nextjs.org/docs/app/building-your-application/deploying/static-exports https://nextjs.org/docs/app/building-your-application/deploy...
- robertoandred 3y ago
  Do you know what an api is?

Akronymus 3y ago

> It is not useful, at all for building apps. Apps (as in, mobile apps) cannot be rendered on the sever. You need an api. Pretty sure that's the whole point of htmx.

willsmith72 3y ago

Technically you can still use an API in your server components. But this is what I love about Remix. You write your server and client code in the same place, but the server code is just an api, so can be reused directly.

SwiftyBug 3y ago
I'm building my first project with Remix. I was very surprised when I found out that I can have an API route just by adding a `export function action() { return json({ message: "it just works!" }) }` in a regular route file. Things are so simple with Remix.

Jcampuzano2 3y ago

Have you ever considered that Next.js can simply be a layer only used by your web client that just consumes your API's? That or you can write API routes in Next.js yourself that can be used by your apps if you choose. I really don't understand the claim you're making when nothing about uses Next prohibits you from having an API. It is exactly what you say, an optimization/use case for web clients. But nothing about this prohibits other clients from doing their own thing consuming the exact same api's if you choose to do so.

nwienert 3y ago
Why would you choose then to have two completely different ways of managing data? It’s insanity. It’s like saying “you can totally use kubernetes to deploy your app and then later switch to swarm and support both!” (And even that analogy doesn’t capture the ridiculousness of doing this, as in that case you’re mostly changing higher level glue code, whereas with RSC your actual data management code would be totally different). Yea, technically you could, but why choose something far more complex that actually actively makes your app like experience worse? Apps want to handle data local-first, offline-first, with optimistic mutations, cached data between screens, instant animations with interactions between screens, etc. The ideal data model for this is something like firebase, parse, graphql, tinybase, etc. So now some bozo on your team bought into the hype and blindly wants to shove RSC into it and you’ve completely ruined the elegance of your stack. Instead of having a single codebase with a single abstraction for data fetching that’s clearly better than server-first, you now have two abstractions, and the server based one ruins all the things that make apps better than sites. It also doesn’t make anything faster for web. You can avoid shipping some JS without RSC, the React team just decided for some reason to couple avoiding sending parts of the tree with a whole new data fetching model, a complete self-own and big mistake. It’s no wonder Vercel the server selling company loves them.
- Jcampuzano2 3y ago
  But its not two "completely separate ways"? Your data management code is not completely different at all. If you want to, do it all in your API and next.js just calls through to it. And then call fetch in your components to the same API you would in a normal client app. The only difference is now those fetch calls happen on a server in RSC's or w/e rather than from the client directly. I'm honestly not even arguing for the hype since I don't use Next.js myself for any production projects at this time, I was simply pointing out that its not as if choosing to use it automatically means you can't use an API which is what the grandparent makes it seem like with their rant about still needing an API. There are some teams that truly do want a server rendered app that Next.js provides as well as other features. They can use it for that if they so choose. I'm honestly not even arguing RSC's are better or not because I know there are tradeoffs on both ends and we don't use them ourselves at where I work. Like I said, I was just poiting out it isn't a simple one or the other. There are plenty of teams out there that use a backend for frontend architecture that basically is a data transformation layer for their API to clients. For your web stack that could be next.js.

mkleczek 3y ago

If by "an API" you mean "JSON sent over the network" then I don't really see too much of an advantage in: database -> server side program -> JSON -> network -> client side program -> HTML -> browser renderer over database -> server side program -> HTML -> network -> browser renderer

jfengel 3y ago
The main advantage is when you have degraded connectivity. Your client app behaves like an app (or app-like web site).

vikramkr 3y ago

Are apps actually still that important? Id be surprised if more than a low single digit of new webapp projects would want to develop an app at some point instead of just having a mobile optimized website. Especially b2b

3np 3y ago

While I think I'd agree with your argument for many projects out there (YAGNI), there are some cases where I think it makes sense. Consider a product or article catalogue with search/filtering/ordering/pagination. This is something that can make sense to do in a SPA while you want it to degrade gracefully and work for clients without JS (including SEO). Or for that matter, a Discourse/Reddit-like discussion board?

uryga 3y ago

> Apps (as in, mobile apps) cannot be rendered on the sever yes and no. sure, you can't do standard SSR like for websites. but i've seen a number of spins[1] on "Server-driven UI", meaning "server defines the app views as a big blob of JSON". usually, it's payload looking something like this: [ { "type": "Heading", "text": "Our cool products" }, { "type": "List", "children": [ { "type": "ProductCard", "id": 123, }, { "type": "ProductCard", "id": 456, } ... ] } ] the app "interprets" this and displays the corresponding components in the specified arrangement. the kicker is that, in a sense, RSC is just a less ad-hoc way to do this kind of thing! instead of `type` tags you get "client references", React handles the relevant parsing/serialization, and a lot of other good stuff on top. it's also quite seamless w.r.t writing components -- react does a very good job of abstracting away all the serialization business. and importantly, you can have an actual ecosystem of RSC packages around it, which a bespoke in-house method of doing this won't have. now, RSC for react native has barely even been teased, but i'll bet good money that they have at least a prototype somewhere. and yeah, of course this would require your app to be in React Native. but that's the selling point -- IF all your stuff is in react, you get a bunch of power and some good DX. --- [1] some examples off the top of my head: - Facebook (not public, described by an employee): https://twitter.com/acdlite/status/1632217463772393473 https://twitter.com/acdlite/status/1632217463772393473 - AirBnb: https://medium.com/airbnb-engineering/a-deep-dive-into-airbnbs-server-driven-ui-system-842244c5f5 https://medium.com/airbnb-engineering/a-deep-dive-into-airbn... - a Polish site called allegro.pl, though I can't find the conf talk about it right now...

EngVagabond 3y ago

Disclaimer, I’m one of the EMs for React at Meta, and spent many years directly working on React Native. > It is not useful, at all for building apps. Apps (as in, mobile apps) cannot be rendered on the sever. You need an api. Yet. React Server Components as a pattern and paradigm are not unique to web sites and the team has designed it with React Native in mind. We are just starting with web to flesh out the ideas and work with the ecosystem first. RSCs (and SSR) are both technologies totally possible to use with RN, theoretically, we just haven’t built out the support yet. At the most basic, instead of rendering to HTML that the server sends down, it would render to commands that React Native’s native code would execute. Similar to the distinction between React DOM and React Native. So we are excited about these technologies even though they are currently web only, and it’ll still be a while until we bring them to React Native. Evan Bacon from Expo also experimented with RSC for React Native: https://x.com/baconbrix/status/1629909713910480898?s=46 https://x.com/baconbrix/status/1629909713910480898?s=46