Hacker News new | ask | show | jobs
by jamil7 2276 days ago
Isn't SSR React notoriously slow? Whats the benefit here over a standard templating language?
6 comments

It can be, but I’m not running a server in production: I’m using the static site generation feature in Next (comparable to Jekyll or Gatsby). It takes an input (Markdown in my case) and spits out a bunch of HTML files that are later deployed on a CDN. No server-side runtime required.
If you're not running the SSR server in production, then wouldn't that just be a static website and not SSR at all?
Understood, I didn't catch that part.
You can use the same components in server and client-side rendering, which can be very useful in many cases.
I think it says Next generates a static site - in that case the cost of SSR is only incurred when compiling the site, so speed isn't really that much of an issue unless it's a gigantic site.
In the way it's being used here it is rendering out every page to a bundle to be served as a static site - there is no server side rendering to speak of really.
TypeSafety is a big one.

Most “standard” template languages default missing variable references to empty values and would only throw an error due to dereferencing an empty value. This would catch all those errors in advance at compile time.

Never used SSR React, but one possibility comes to mind: It makes easier for single page JS apps to have compatibility with browsers that have JS disabled by allowing more code reuse between JS and no-JS versions.