Ask HN: SPA vs. SSR in 2024?
8 comments
What are you building? You should be able to articulate the pros and cons of choosing an SPA, SSR, SSG, or some combination of the above based on your user needs and team resources and constraints and the purpose of the app.
Most of the app can be statically built, first rendered on the server and then cached on a CDN as static files. Then certain rerenders and calls can be clientside and others can go through the server if needed.
It shouldn't just be a fashion choice, but a measured analysis. Like what is on your backend and what is on the edge, how would consistency work, what are the regional considerations, etc.
I feel like asking which infra to build without knowing the app is putting the cart before the horse. A dashboard is different from a chatbot is different from a marketing site is different from a graphics app, etc., and each has different architectural considerations.
Most of the app can be statically built, first rendered on the server and then cached on a CDN as static files. Then certain rerenders and calls can be clientside and others can go through the server if needed.
It shouldn't just be a fashion choice, but a measured analysis. Like what is on your backend and what is on the edge, how would consistency work, what are the regional considerations, etc.
I feel like asking which infra to build without knowing the app is putting the cart before the horse. A dashboard is different from a chatbot is different from a marketing site is different from a graphics app, etc., and each has different architectural considerations.
My 2 cents
The SSR game is peak frontend fashion.
The players in this space sell hosting solutions and getting you onto their platform and spending money is their primary goal (i.e. increasing the amount of server side compute and ancillary "services" needed to deliver a frontend solution). Regardless even if you go SSR the backend elements should just be used for SSR, and potentially things like auth, but otherwise just go with a data API as normal that provides the SSR backend with data. Rule of thumb, the SSR solution should never be considered "backend" even if it is running on a server and not the client.
SSR means it is way more difficult to open the network tab in developer tools and understand how your frontend is driving your API. I don't think I fully appreciated looking at the JSON sent over the wire in this tab until I did some SSR work.
If you go with SSR expect ridiculous churn in your technology space.
In the end I have latched onto vanilla React (e.g. no framework like Next) SPA that lazy loads components so you don't have a huge download on the first page load. I use wouter for routing and am pretty much trying to minimize all other deps where possible. I've gone with Preact but am questioning that a little now since it feels like I'm going off-road a bit on my simple setup.
I'm no expert on the frontend but thought I'd share my experience walking down this same path over the last 3 months or so.
Edit: how ironic that I'm calling React "my simple setup"...
The SSR game is peak frontend fashion.
The players in this space sell hosting solutions and getting you onto their platform and spending money is their primary goal (i.e. increasing the amount of server side compute and ancillary "services" needed to deliver a frontend solution). Regardless even if you go SSR the backend elements should just be used for SSR, and potentially things like auth, but otherwise just go with a data API as normal that provides the SSR backend with data. Rule of thumb, the SSR solution should never be considered "backend" even if it is running on a server and not the client.
SSR means it is way more difficult to open the network tab in developer tools and understand how your frontend is driving your API. I don't think I fully appreciated looking at the JSON sent over the wire in this tab until I did some SSR work.
If you go with SSR expect ridiculous churn in your technology space.
In the end I have latched onto vanilla React (e.g. no framework like Next) SPA that lazy loads components so you don't have a huge download on the first page load. I use wouter for routing and am pretty much trying to minimize all other deps where possible. I've gone with Preact but am questioning that a little now since it feels like I'm going off-road a bit on my simple setup.
I'm no expert on the frontend but thought I'd share my experience walking down this same path over the last 3 months or so.
Edit: how ironic that I'm calling React "my simple setup"...
It sounds like you're weighing the trade-offs between a traditional SPA with a CRUD backend and SSR with edge compute. SSR (like SvelteKit with Cloudflare Workers) offers benefits like improved SEO, faster initial load times, and better edge caching, but it can add complexity and cost. Hosting on services like Cloudflare Workers can be efficient for serverless execution, though it might increase your hosting bill compared to a simple VPS. If your team values simplicity and you don't need extensive SSR features, a separate backend with FastAPI/Svelte might be the more cost-effective and maintainable approach. The choice depends on project scale and team preference.
> SPA vs. SSR in 2024?
Are you asking what was popular last year, or advice on what should be done today (2025)?
Are you asking what was popular last year, or advice on what should be done today (2025)?
I forgot it's 2025 already hahahaha
2024 is soo last year :)
It’s 2025 btw lol. You use SSR when you have public product catalog pages or something like that which needs to be reliably search indexed and up to date. Think an e-commerce site or LinkedIn.
You use SPA when you have a private b2b or even b2b client app, like a CRM or file manager for a particular user or organization, whose data and pages will never be publicly available or indexed.
You can do hybrid if you have mixed use cases too.
Anyone who tells you otherwise is a noob and has no idea what they’re doing and should be ignored because they’re chasing hype or optimizing something dumb.
We live in a lazy load world you don’t need to load 25mb of JS. If you’re doing a private client side application look into lazy loading JS so you load only what’s necessary and load more as needed. Saving 50ms max when adding more revenue is better is dumb.
Build for your customers (solve their ACTUAL problems) and your use-case.
Source: was a UI lead back in the day leading on both SSR and SPA, collectively serving billions of dollars of value to millions of people. Trust me bro.
You use SPA when you have a private b2b or even b2b client app, like a CRM or file manager for a particular user or organization, whose data and pages will never be publicly available or indexed.
You can do hybrid if you have mixed use cases too.
Anyone who tells you otherwise is a noob and has no idea what they’re doing and should be ignored because they’re chasing hype or optimizing something dumb.
We live in a lazy load world you don’t need to load 25mb of JS. If you’re doing a private client side application look into lazy loading JS so you load only what’s necessary and load more as needed. Saving 50ms max when adding more revenue is better is dumb.
Build for your customers (solve their ACTUAL problems) and your use-case.
Source: was a UI lead back in the day leading on both SSR and SPA, collectively serving billions of dollars of value to millions of people. Trust me bro.
Use v0 to generate your frontend
It seems marginally more convenient for a large team to have a unified front/backend and people seem to like sveltekit, but it doesn't personally bug me to have the two separated. I could also see advantages to typescript/prisma/zod for instance over sqlalchemy and pydantic; pydantic improves python a bit along with mypy/pyright but typing is still very much hacked-in. It also seems like I'd increase my hosting bill a bit, both because SSR shifts work to the server and because workers or similar services generally have markups over a VPS. Thanks :)