4 ms·

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

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

by jasode 4y ago

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.