5 ms·

Reading about SSR feels like we went full circle.

techdragon 4y ago
We did… in arguably the dumbest way possible… it’s getting slightly better now as frameworks innovate on various ways to improve SSR … but when SSR first started being a thing it was literally stuff like “how do I run a j entire desktop browser, headless on my web server (or wedged in between with weird reverse proxy setups…) to pre-render the page HTML using the my Client side JavaScript of my single page app because I want to do things that my client side only framework wasn’t designed to do” It wasn’t universally that bad but at its worst it was totally this bad.
vbezhenar 4y ago
My understanding is that you're using a single codebase for rendering both on client and on server. And, of course, after loading server-rendered page, client code continues to work in the browser as expected. So it's kind of best of both worlds and it makes perfect sense.
pacificmint 4y ago
Full circle make it sounds like we’re doing it only once. :) I like to think of it as a Pendulum! Back and forth it goes.
bsaul 4y ago
it would be interesting to understand what is different now. Because IMHO it's never 100% full circle. It looks like we're back at the same point, but there are usually crucial differences in the implementation details that makes it quite different.
- BurningPenguin 4y ago
  Yeah, i guess the tooling around it got way better. No need to download scripts from hundreds of websites. Just npm install and off you go. I'm just not a huge fan of SPA in most cases. I had to commute a few years ago everyday and it was near impossible to read any news website, because their stupid React or Angular SPA toy just decided to stop loading. Mobile reception isn't that great in Germany, when you're sitting in a train. The weirdest thing was to watch the content load and then like 10 seconds later going blank, because the connection timed out.
- jasode 4y ago
  >Because IMHO it's never 100% full circle. It looks like we're back at the same point, but there are usually crucial differences in the implementation details that makes it quite different. Your intuition is correct. The "SSR" looks confusing because people are using that in 2 different ways: (1) Server-Side-Rendering means using Client-Side frameworks like React on the server : https://en.wikipedia.org/wiki/Server-side_scripting#Server-side_rendering https://en.wikipedia.org/wiki/Server-side_scripting#Server-s... ...or... (2) Server-Side-Rendering means _any_ dynamic page generation on the server side regardless of programming language or framework. That has been done since the beginning of the web with Perl+CGI, PHP, ASP.NET, etc. For this mindset, SSR means "we've gone full circle" because it ignores the Javascript evolution from clients to servers. The 2 groups are talking past each other. For people using "SSR" definition (1), it's doesn't look "full circle" because a language like PHP was never in a runtime in browsers so there was never a client-side-to-server-side re-use of the rendering code. "SSR" is probably a bad name to describe that trend.
  - deleted 4y ago
    [deleted]
  - dmix 4y ago
    Correct but it’s even more (1) is more like using the client side code on the server AND the client at the same time, significantly reducing duplication of effort and offering the best of both worlds So you have one view library (and routing/models etc) and the innovation is that a) it very intelligently only delivers the bare minimum JS of what’s needed to make a fully interactive front end app (which is why you needed React/Vue in the first place due to limitations of pure server side code) plus b) using the same patterns and awesome libraries everywhere on your site, not just specific interactive components but blog, about pages, admin panels, etc. So you’re not doing python jinja or Ruby ERB templates/helpers/routes/etc on the server mixed with tons of duplication with React/Vue on the client.
  - rambambram 4y ago
    > The 2 groups are talking past each other. For people using "SSR" definition (1), it's doesn't look "full circle" because a language like PHP was never in a runtime in browsers so there was never a client-side-to-server-side re-use of the rendering code. Exactly. As a PHP guy I'm not thinking in terms of SSR or CSR, but backend and frontend. PHP never had to do things on the client side, that is what HTML and CSS are for (and some JS). JS apparently has to go from client side to now also server side. I don't think it's necessary an advantage to have one and the same language doing both the backend and frontend. I also don't know of any disadvantages, I have no experience with JS frameworks. But everybody is hitting some very interesting points in this whole comment thread. You have some smart remarks about talking past each other. And I also think your observation of PHP never having to run in the browser is a sharp observation. Thx.

We did… in arguably the dumbest way possible… it’s getting slightly better now as frameworks innovate on various ways to improve SSR … but when SSR first started being a thing it was literally stuff like “how do I run a j entire desktop browser, headless on my web server (or wedged in between with weird reverse proxy setups…) to pre-render the page HTML using the my Client side JavaScript of my single page app because I want to do things that my client side only framework wasn’t designed to do” It wasn’t universally that bad but at its worst it was totally this bad.

vbezhenar 4y ago

My understanding is that you're using a single codebase for rendering both on client and on server. And, of course, after loading server-rendered page, client code continues to work in the browser as expected. So it's kind of best of both worlds and it makes perfect sense.

pacificmint 4y ago

Full circle make it sounds like we’re doing it only once. :) I like to think of it as a Pendulum! Back and forth it goes.

bsaul 4y ago

it would be interesting to understand what is different now. Because IMHO it's never 100% full circle. It looks like we're back at the same point, but there are usually crucial differences in the implementation details that makes it quite different.

BurningPenguin 4y ago
Yeah, i guess the tooling around it got way better. No need to download scripts from hundreds of websites. Just npm install and off you go. I'm just not a huge fan of SPA in most cases. I had to commute a few years ago everyday and it was near impossible to read any news website, because their stupid React or Angular SPA toy just decided to stop loading. Mobile reception isn't that great in Germany, when you're sitting in a train. The weirdest thing was to watch the content load and then like 10 seconds later going blank, because the connection timed out.
jasode 4y ago
>Because IMHO it's never 100% full circle. It looks like we're back at the same point, but there are usually crucial differences in the implementation details that makes it quite different. Your intuition is correct. The "SSR" looks confusing because people are using that in 2 different ways: (1) Server-Side-Rendering means using Client-Side frameworks like React on the server : https://en.wikipedia.org/wiki/Server-side_scripting#Server-side_rendering https://en.wikipedia.org/wiki/Server-side_scripting#Server-s... ...or... (2) Server-Side-Rendering means _any_ dynamic page generation on the server side regardless of programming language or framework. That has been done since the beginning of the web with Perl+CGI, PHP, ASP.NET, etc. For this mindset, SSR means "we've gone full circle" because it ignores the Javascript evolution from clients to servers. The 2 groups are talking past each other. For people using "SSR" definition (1), it's doesn't look "full circle" because a language like PHP was never in a runtime in browsers so there was never a client-side-to-server-side re-use of the rendering code. "SSR" is probably a bad name to describe that trend.
- deleted 4y ago
  [deleted]
- dmix 4y ago
  Correct but it’s even more (1) is more like using the client side code on the server AND the client at the same time, significantly reducing duplication of effort and offering the best of both worlds So you have one view library (and routing/models etc) and the innovation is that a) it very intelligently only delivers the bare minimum JS of what’s needed to make a fully interactive front end app (which is why you needed React/Vue in the first place due to limitations of pure server side code) plus b) using the same patterns and awesome libraries everywhere on your site, not just specific interactive components but blog, about pages, admin panels, etc. So you’re not doing python jinja or Ruby ERB templates/helpers/routes/etc on the server mixed with tons of duplication with React/Vue on the client.
- rambambram 4y ago
  > The 2 groups are talking past each other. For people using "SSR" definition (1), it's doesn't look "full circle" because a language like PHP was never in a runtime in browsers so there was never a client-side-to-server-side re-use of the rendering code. Exactly. As a PHP guy I'm not thinking in terms of SSR or CSR, but backend and frontend. PHP never had to do things on the client side, that is what HTML and CSS are for (and some JS). JS apparently has to go from client side to now also server side. I don't think it's necessary an advantage to have one and the same language doing both the backend and frontend. I also don't know of any disadvantages, I have no experience with JS frameworks. But everybody is hitting some very interesting points in this whole comment thread. You have some smart remarks about talking past each other. And I also think your observation of PHP never having to run in the browser is a sharp observation. Thx.