4 ms·

> 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. Creati

> 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.

foooorsyth 3y ago
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.
- hombre_fatal 3y ago
  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.
  - tacker2000 3y ago
    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?
    - foooorsyth 3y ago
      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
      - hombre_fatal 3y ago
        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.
    - hombre_fatal 3y ago
      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.
zogrodea 3y ago
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?
deleted 3y ago
[deleted]
seabass-labrax 3y ago
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.
deleted 3y ago
[deleted]
fuzzy2 3y ago
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.)

foooorsyth 3y ago

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.

hombre_fatal 3y ago
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.
- tacker2000 3y ago
  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?
  - foooorsyth 3y ago
    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
    - hombre_fatal 3y ago
      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.
  - hombre_fatal 3y ago
    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.

zogrodea 3y ago

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?

deleted 3y ago

[deleted]

seabass-labrax 3y ago

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.

deleted 3y ago

[deleted]

fuzzy2 3y ago

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.)