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.
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.
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!
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?
I agree, and yet a lot of users seem to expect apps. To them, if you only have a web site you look unprofessional. Even though we all know perfectly well that most apps are repackaged web sites.
I don't think I have ever felt that only a website feels unprofessional. Anecdotal, but still. A well built, well designed, responsive site is all I need to know that someone is on top of it.
I'd rather see them do 1 method very well than 2 methods haphazardly
Many of those websites don't even need to exist, as pure informational portals. They should just be boards in a (indeally decentralized, uniform) network of news source
Can you elaborate on this? In particular, the use of "everyone" -- do you really mean everyone? Can you describe some of the common arguments about why not everyone can have an app and explain why they are logically wrong?
Yes, I mean everyone. What we currently deal with are artificial limits imposed by gatekeepers (app stores), and web developers (particularly ones that want to use backend as collateral control). Neither of these are technical problems that should exist.
That reads quite differently from your statement. The limits imposed by app stores are real challenges that keep people from building apps. That’s a very logical reason to avoid it. It seems your original statement would be better phrased, “There is no logical reason why there should be so many boundaries preventing everyone from having an app.”
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?
Obviously they're arguing from a pragmatic point of view, as opposed to one in which we (some) software engineers somehow control reality and successfully impose that's ideal to them.
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.
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.
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.
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.
> 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:
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.
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.
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
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.
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.
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.
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.
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.
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?
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.
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.
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
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.