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.
That's ridiculous. Browsers exist for a reason.
I'd rather see them do 1 method very well than 2 methods haphazardly
Or gate-kept app stores?
But even then, it ignores the technical hurdles an individual or organization must leap to build an app. Languages and ecosystems to learn, full of idiosyncrasies and best practices. Complexities of deployment pipelines, seeking incompatibilities between devices. I’ve worked with Android before and lemme tell you, I’ll move to a different industry before I do that again. (Kotlin is wonderful, at least!)
Compared to web, where you pick the browsers you want to support and it works. Where there is constant warfare between vendors to improve performance and get closer to the native experience. Where you have a massive pool of talent and a low barrier to entry. How is this even close?
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.
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.
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.
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.
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.
https://nextjs.org/docs/app/building-your-application/data-f...
Spoiler: you don’t get an api.
https://nextjs.org/docs/app/building-your-application/routin...
https://nextjs.org/docs/app/building-your-application/deploy...
Pretty sure that's the whole point of htmx.
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.
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.
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.
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.
over
database -> server side program -> HTML -> network -> browser renderer
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?
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 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
- AirBnb: 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...
> 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
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.