Ask HN: SPA vs. SSR in 2024? | Hacker News Reader

Ask HN: SPA vs. SSR in 2024?

9 points_bin_8 comments

I'm working on a new project that has a reasonable level of content/processing done on the backend but nothing too heavy. My default approach would be a simple SPA served statically with a CRUD backend, probably fastapi and svelte. However, I've heard lots of people extoll the advantages of more SSR due to better edge compute technologies. Lots of people seem predisposed to throw their backend on cloudflare workers or something and handle it there. What are y'all's experiences between the two?

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 :)

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.

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"...

> SPA vs. SSR in 2024?

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.

Use v0 to generate your frontend

Reply on news.ycombinator.com