Hacker News Reader

Comment by setr | Hacker News Reader

I've never been fully confident in knowing what SSR refers to -- but its just the creation of static html on the server, right? As opposed to shipping a bunch of async dom updates contained in a js script executing on load, client side

But if I have it right, I have no idea why a JS backend would be required to do SSR; this is exactly the same domain of work php, rails, django have always done, without node.js needing to enter. For an SPA (which I believe is just a bunch of js fetching data from JSON apis and rendering client-side), you'd need JS to handle client-side rendering, but if you can replace that with WASM (when it has DOM support)... I don't see why you'd need JS anywhere

FYI I'm defining everything because I'm pretty sure there's a mistake somewhere in my understanding of the problem

View on HN

Nah it's used in two related, but kinda confusing ways, it's not just you:

Traditionally, it means rendering your HTML on the server. Exactly what you're saying.

It also refers to a specific technique that's used to implement rendering your HTML on the server by effectively running your client side app server side, then shipping its output. This requires some work to get right, and so it's presented as a feature of client-side libraries/frameworks.

The actual client code is being executed.

Wait thats just weird -- if you're effectively removing the work from the client to the server anyways, such that its only executing on the server... I don't see what you've achieved beyond the original writing of standard language-agnostic SSR -- that you can design everything client-side, and conveniently migrate the heavier work serverside without interruption/rewrite?

It gives you the best of both worlds - fast initial load, accessible, works without JS. But then also get all the client side goodness - highly interactive views, animations, and far less bytes transferred for subsequent page loads. Plus, writing a complex frontend is simply a far better experience in something like React than in Ruby, Python, PHP, etc.

Finally, it lets you also render them to React Native using a lot of shared code. And you can share code between your backend APIs, etc.

To be honest, I’ll take Typescript over anything, even if it wasn’t the default for the web. It strikes the perfect balance of flexibility, concision, safety, debugging ux, and has a huge ecosystem to boot. I think client side JS these days if anything is underrated and the WASM hype won’t change much - if you want a lightweight, accessible app then doing a SPA in JS (with SSR) is actually not even a compromise, it’s truly superior to any alternative. Now, with a big caveat: you need to invest to get it all set up properly. No one has really “railsed” it yet, as far as I can tell.

> such that its only executing on the server

It's not, it can run on both. You render on the server for the initial page load, and then on the client for every page after.

Or not! The point is, now that you've unlocked both, you can use either one, in the way that works best for your application, in whatever ratio makes sense.

A significant consideration here is SEO and crawlability. Rendering the page server-side will serve a page with content even without JavaScript running on the client, yet for clients that do have JavaScript they still get the enhancements of an interactive JavaScript app.

> I've never been fully confident in knowing what SSR refers to

https://developers.google.com/web/updates/2019/02/rendering-... is a great resource on the subject.

You can be fully Server-side (regular php), you can do full JS client-side rendering, and you can have hybrids that mix both.

SSR typically refers to server side rendering of a single page app. I.e. render the HTML for a given route of an SPA. For that to work, you need to be able to execute your SPA code on the server which will be JS. You are right that WASM will change all of this, but the ecosystem is not mature yet.

Reply on news.ycombinator.com