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

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.

Ah

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.

To some extent, that is true regarding my personal preferences, but being in tech and writing code for over 20 years teaches you a few things. Developers should be more picky about tools they adopt without becoming too cynical or dismissive of new technology. Every so often you have to go through your technology shed and be sure you aren't being biased towards existing comfortable tools. It's nice to work out of your comfort zone and learn new things, but it's also nice to be very efficient at problem solving. When I feel a new tool or technology crosses a threshold from hype to having proved its value I tend to take it seriously and learn it. I try to avoid getting sucked into tech stacks that I don't think will make it. Some times I am wrong, but usually not. I could have made my description of technology more generic, but in general, things like Django/Rails/Postgres/MySQL/NodeJS/Redis are battle proven technology that won't let you down. IMO that is the hardest part about being a lead engineer / CTO -- knowing when to say Yes and No to given technology stacks :)

I agree with everything you've written here, particularly your process of tool evaluation and refinement. My only push back is with respect to the way you characterized the merit of "overhyped" tools (in your previous comment) that didn't line up with the productivity profile of your personal experience. I agree that Django/Rails/Postgres/MySQL/NodeJS/Redis are all reliable tools, but I am not a fan of the philosophy that labels other people's work as unnecessary or harmful simply for existing outside the pantheon of worthy tooling.

In isolation of any constraint new things are always worth playing with and trying. I know I am certainly more biased (hopefully in a mostly good way) now than I was when I started in tech. Your thought strikes me as Very similar to when someone shares some hobby project they are working on and someone else doesn’t get it and states: “wow, you must have a lot of time on your hands”. So I do try to take new projects seriously while at the same time balancing time constraints. It’s hard :)

> If it were me, I'd prefer rails to django any day of the week, that's a personal preference

This is totally not what the parent is getting into. It seems like your comment reads much more like "my personal preferences are good" than the parent

They complain about Javascript and Kubernetes then praise Django and Redis, all in the abstract without any consideration for the totally different problems these tools actually solve. I injected my own personal preferences in-kind but labeled them as preferences instead of slamming other tools as overhyped and without merit.

> if we're talking about building an SPA you're typically going to be building a worse solution if you can't SSR your client views, which you need a js backend to do.

I have not used React with Rails and maybe I'm misunderstanding your comment, but the react-rails readme includes a section about SSR via ExecJS and integrated with Rails:

https://github.com/reactjs/react-rails#server-side-rendering

ExecJS functions as a JS backend in this case, its just a ruby interface for node/rhino/v8 that's a little bit clunkier to utilize.

That is obvious (it's in the name). The way your comment is phrased reads to me like you are saying that one can't use Rails and has to switch to a full JS backend for SSR. If that's not what you are saying, then it's unclear what you are actually saying and why you juxtaposed Rails / Django against a JS backend.

My point is that you literally cannot SSR your client js views without a js backend, so node has a clear engineering purpose in this respect. Yes, you can import a second backend into your main backend to avoid writing node, and that's fine, maybe your team is mostly made of rubyists or maybe your existing code base is ruby, there's nothing wrong with this approach, but it is more complication and layers of abstraction than just using a js backend if you must build an SPA.

> import a second backend into your main backend

This is not typically how the term "backend" is used in this context. Most mature apps will use a variety of tools and services built in a variety of languages, but this is not referred to as "importing a second backend." In fact, your comment is apparently the first use of the phrase "import a second backend" on the entire internet: https://www.google.com/search?q=%22import+a+second+backend%2...

I'm speaking metaphorically. When I say "import a second backend" I'm saying that the thing being imported into the ruby backend is literally a wrapper around the exact same runtime that is typically used to run js backends, the corollary being that the "ruby" part is unnecessary added complexity from an engineering perspective unless you have some other compelling reason to use ruby (which is certainly possible).

but if we're talking about building an SPA you're typically going to be building a worse solution if you can't SSR your client views

Is not worse, is fine. Mostly depends on the requirements, why go the extra complexity of SSR if you don't need it?

Most of the time SSR gives massive web accessibility benefits. Ignoring web accessibility because you don't want to implement SSR is likely a worse solution for a large portion of your userbase.

That's why I said "typically". One of the biggest complaints about SPAs is the perceived slowness due to the app loading and rendering assets in the browser, as well as the typical HN noscript complaints, as well as accessibility issues, SEO issues, and other problems related to back button behavior and url routing. SSR solves all of these troubles.

I'm not sure exactly what you're referring to, but being able to run Rust both on the server and client should allow SSR, no?