Hacker News Reader

Comment by yodon | Hacker News Reader

Genuine question: what's wrong with a client-side SPA and a server-side backend for 90% of small-to-midsized SaaS apps?

I see why Vercel would want everyone using SSR and their opaque server-side caching, but why do generic non-FAANG-scale web apps want it on day one?

When Next became a Vercel sales tool, I switched to React + Vite + backend, and everything just got so much easier.

View on HN

Frontend devs were largely bullied into imitating traditional MPAs by people posting memes about SPAs and loading spinners. A huge percentage of pages could simply be pre-rendered (e.g. static landing pages and documentation sites), or they're behind a login wall in which case SEO no longer really matters. Deploying an SPA used to mean uploading a few scripts and html documents to an S3 bucket, and with CDN caching it was fast enough for many organizations. Instagram is still a mostly 100% client side SPA.

I’m probably going to die on the hill of building either:

1. SPA with html css and a bunch of js hosted on cdn, talking to pure REST api. (For apps behind login)

2. Php style Server rendered pages with a sprinkle of inline jquery-ish JS. (For websites)

Hybrid of both of them is a Frankenstein monster I ain’t touching.

> what's wrong with a client-side SPA and a server-side backend for 90% of small-to-midsized SaaS apps?

I'm not a frontend dev and what I like about SSR is that you don't have to code frontend visual effects that indicate that "something is loading", you just get the hydrated page back without too much frontend logic.

That's a lot of complexity to bring in just to avoid adding a <suspense> tag

If SEO is not important there is nothing wrong with this approach.

Stop building products that get their income from advertising and SEO worries go away in a hurry

It's actually wonderful

It’s not about ads, it’s about distribution. If people find your product via google then SEO matters (at least for the page they land on).

Your marketing website should be SEO'd up the wazoo

It also shouldn't be part of your product codebase.

You should not need to worry about SEO in your product itself

It's crazy how people want to combine everything together such that adding some padding to a button on their pricing page redeploys their entire backend...

Typically I have a backend server written in a good language, an SPA for the app itself, and then some marketing pages written in plain html and js sprinkles, old school. It's great for SEO.

this is the way

I use Next.js for marketing websites too though. It's the easiest way to set up SSR (or send pure HTML and CSS) in React, ie use JSX/TSX as a typed templating language with the additional ability to bring in React packages for certain things if needed.

Reply on news.ycombinator.com