Hacker News Reader

Comment by trollied | Hacker News Reader

> There was a time, several years ago, when React was pretty much the only game in town when it came to server-rendered content

This is actual nonsense. Creation of a fully-formed HTML document server-side is performed by countless platform combinations.

View on HN

It is a hilariously naive statement. Everyone’s PHP CGI bin on their basic free web hosting did/does SSR. Every Rails and Django app does SSR. SSR has been norm since forever.

PHP CGI, Rails, and Django can server-render a client app that gets rehydrated on the client? Because that's what the blog post is talking about.

Let's be a bit more charitable when we pull quotes out of context.

What does rehydrated actually mean? Honest question.

In PHP the server computes the full HTML and sends it to the client browser. What would need to be added here to have “client side hydration” for example?

They mean not having to write any client-side JS. So, having a mechanism to use the backend language for both the content that gets displayed when the page/component first loads AND any interactivity thereafter. It’s easy to populate a <select> with values with (traditional) SSR, but then you’d often have to write some JS to make additional requests when the user makes a selection, for example.

Seems weird to me to use “SSR” as a term for both SSR + hydration, but I’m not in the web dev lingo bubble so what do I know? The author doesn’t use the term “hydration” until the blurb at the end talking about Quik

The whole blog post is about React and client-side development, so the context should be clear. If it weren't clear, the other SSR-capable frameworks they list in the SSR section are client-side frameworks with the same SSR feature.

SSR when talking about React is very clear jargon.

Let's start in the other direction.

You have a client-side web application. You want the initial-state HTML to come over the wire on the first response rather than wait for the client application to load, make a request, and then render the result.

So you use a tool like those listed in TFA (like Next.js) to run your front-end app logic on the server to generate the HTML and send it to your client where your front-end app mounts to that HTML and takes over (cutely named rehydration).

This is relatively cutting edge stuff which is why it's weird to assume OP is an idiot who never knew about PHP or CGI when he wrote an article that is obviously talking about client-side applications and rendering them on the server.

Server-side rendering doesn't actually mean server-side rendering though. It's a term of art for a paradigm where applications are written in a single code base, and certain elements are rendered on the server and cached and other, more dynamic ones are rendered by the client.

The older platforms for this had you essentially write two separate backends - the one which renders HTML, and the other which returns a JSON or XML API for your hand-written JavaScript (or CoffeeScript or JQuery etc.) embedded in your HTML.

Not a front-end dev, but I think (correct me if I'm wrong) the usual way of SSR were things like returning a plain HTML web page in Spring/ASP.NET/whatever and that the main invention of Next as far as SSR goes is that you can write your server's HTML docoment in JSX.

So I would say the author's point (if I was asked about it) would be that these other new front-end frameworks support similar things, instead of sending plain HTML over the wire.

Am I wrong?

We had that discussion here in the past, I’ll just repeat my point of view: When someone says “SSR” today, especially with a Javascript context, they are specifically referring to Javascript SPAs (pre-)rendered server-side.

So, considering this, is it still nonsense? (I honestly don’t know.)

Reply on news.ycombinator.com