5 ms·

Some people here seem confused why SSR is not the optimal solution for heavy web apps, so let me explain. Such web apps can be downloaded to the client the fir

Some people here seem confused why SSR is not the optimal solution for heavy web apps, so let me explain. Such web apps can be downloaded to the client the first time you open the page, and after that (basically every day), caching strategy makes sure you don't have to download that thing again. Which means you only need to transfer pure data at that point, and you can have a very responsive web page. SSR rendering on the other hand, you will get some kind of PHP website (OK, this is exaggerated, but you get the point). Requests go back to the server, and the server renders the page. Totally ludicrous. SSR: for landing pages, SEO optimization, showing the same page to a lot of users, etc. CSR: for heavy apps that you use regularly, basically "real" applications, not web pages.

underwater 5y ago
In theory, yes. But is anyone actually effectively writing apps in that way? I can't think of a single good example I've seen in the wild. Most of the time the app is either large and sprawling, updated frequently, or XHR fetches are written in an inefficient way. All of these nullify the benefits from the model of having cached application code. For example if you're waiting for your JS app to initialise, then fetching XHR in a serial way you're probably slower than an SSR page that is sending a data blob down inline. I'd say SSR is a good rule of thumb, and the few people who build SPAs who can make use of this will know when to break that rule.
- deleted 5y ago
  [deleted]
ihuman 5y ago
> SSR rendering on the other hand, you will get some kind of PHP website (OK, this is exaggerated, but you get the point). Requests go back to the server, and the server renders the page. Totally ludicrous. NextJS only renders (or gets the static HTML) and sends you the HTML for the first page you navigate to. When you click a link on that page, it just sends you the data (and JS if needed).
TechBro8615 5y ago
This comment is highly misleading. It implies that SSR vs CSR is an “either or” proposition: > SSR rendering on the other hand... Requests go back to the server... Totally ludicrous. For Next.js, this description of routing and rendering is “Totally” incorrect. I don’t know about other SSR frameworks (except maybe PHP, which does actually work as the parent comment describes), but with Next.js, you get SSR on first page load and CSR on subsequent clicks. Thats the whole point of next/router and the <Link> component. Hovering a <Link> will download (“pre-load”) the tiny JS file required to render the next page. Clicking it will trigger client side rendering, without any new server side page load. The complexity that causes this kind of misunderstanding is the best argument against SSR.

underwater 5y ago

In theory, yes. But is anyone actually effectively writing apps in that way? I can't think of a single good example I've seen in the wild. Most of the time the app is either large and sprawling, updated frequently, or XHR fetches are written in an inefficient way. All of these nullify the benefits from the model of having cached application code. For example if you're waiting for your JS app to initialise, then fetching XHR in a serial way you're probably slower than an SSR page that is sending a data blob down inline. I'd say SSR is a good rule of thumb, and the few people who build SPAs who can make use of this will know when to break that rule.

deleted 5y ago
[deleted]

ihuman 5y ago

> SSR rendering on the other hand, you will get some kind of PHP website (OK, this is exaggerated, but you get the point). Requests go back to the server, and the server renders the page. Totally ludicrous. NextJS only renders (or gets the static HTML) and sends you the HTML for the first page you navigate to. When you click a link on that page, it just sends you the data (and JS if needed).

TechBro8615 5y ago

This comment is highly misleading. It implies that SSR vs CSR is an “either or” proposition: > SSR rendering on the other hand... Requests go back to the server... Totally ludicrous. For Next.js, this description of routing and rendering is “Totally” incorrect. I don’t know about other SSR frameworks (except maybe PHP, which does actually work as the parent comment describes), but with Next.js, you get SSR on first page load and CSR on subsequent clicks. Thats the whole point of next/router and the <Link> component. Hovering a <Link> will download (“pre-load”) the tiny JS file required to render the next page. Clicking it will trigger client side rendering, without any new server side page load. The complexity that causes this kind of misunderstanding is the best argument against SSR.