7 ms·

Knowing what it is now, describing it that way makes total sense... but it only works for people after knowing what it is... kind of like an inside joke. For a

Knowing what it is now, describing it that way makes total sense... but it only works for people after knowing what it is... kind of like an inside joke. For anyone wondering what it means: it ships only the JS for select components (usually ones that have some sort of client-side interactivity, such as the incrementing counter on their demo page), so it only has to hydrate that part (where hydration is reconciling the client bundle execution result with what is actually on the page). This is opposed to the standard way React works which is the entire JS used to render the page—even the static non-interactive bits like plain HTML—is shipped to the client and all your function component functions are run (just without the actual inserting DOM elements again if SSR is used). React is currently developing server rendered components that works with streaming SSR introduced in React 18 that delivers this same functionality. Basically your app can then be composed of server components and client components (essentially what all current react components are), and only the JS for client components is actually sent to the browser and hydrated.

vosper 4y ago
> React is currently developing server rendered components that works with streaming SSR introduced in React 18 that delivers this same functionality. Basically your app can then be composed of server components and client components (essentially what all current react components are), and only the JS for client components is actually sent to the browser and hydrated. Isn’t the difference here that with React Server Components you’re still fully rendering client-side, but you can ship the data alongside the JS? Whereas with Astro / islands of inactivity / partial hydration you ship actual HTML and then after it renders you make interactive (hydrate) only the relevant parts?
BurningPenguin 4y ago
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]
    - 4y ago
csmpltn 4y ago
I'm not an Uncle Bob fan by any stretch of the imagination, but he wrote a somewhat famous article about this phenomenon: http://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html http://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html With each new wave - we get people that either lack the time, the willpower or the conditions to understand what came before them (the ground they're standing on), and this is how we end up rediscovering things every 2-3 years. It's much more tempting to just discard old knowledge, reinvent from scratch. People were doing "SSR" with PHP on the server-side 30 years ago, and still do today (can you imagine just how much progress that platform has made, and how much collective knowledge has been developed around it?). It's just not hip anymore, because it wasn't invented within the past 36 months.
- thisiswrongggg 4y ago
  Yeah, he should know. There so much irony of this criticism coming from a guy that contributed to the max to the entropy of dubious and cargocult terms and "principles" in the field.
- zepolen 4y ago
  You can't compare JS SSR with PHP, SSR implies there is CSR which is not the case with PHP. Then having one language, no, one _shared code base_ for both client and server, which automatically can only send the minimum necessary over the wire? That's a _huge_ step forward. And I say this as someone who was developing CGI scripts before PHP came along.
  - csmpltn 4y ago
    > "Then having one language, no, one _shared code base_ for both client and server, which automatically can only send the minimum necessary over the wire? That's a _huge_ step forward." This is exactly the kind of non-nuanced, buzzwordy and handwavy advertising I was ranting about. 1. Why should having the client and server share the same codebase even be a goal in the first place? This should be a nuanced conversation with different trade-offs, there's no one-size-fits-all here. It's disingenuous to paint this as an ideal we all have to work towards on a whim. 2. I don't even know where's the innovation in being able to "send the minimum necessary over the wire". This is a pillar of decent software engineering. We've been severely regressing here due to the pervasive use of bloated abstraction layers, combined with a deep lack of understanding of how things work (ref. the Uncle Bob post I've linked earlier).
dheerajvs 4y ago
> it ships only the JS for select components So, even if the page has a single React component, does it ship the entire react + react-dom bundle?

vosper 4y ago

> React is currently developing server rendered components that works with streaming SSR introduced in React 18 that delivers this same functionality. Basically your app can then be composed of server components and client components (essentially what all current react components are), and only the JS for client components is actually sent to the browser and hydrated. Isn’t the difference here that with React Server Components you’re still fully rendering client-side, but you can ship the data alongside the JS? Whereas with Astro / islands of inactivity / partial hydration you ship actual HTML and then after it renders you make interactive (hydrate) only the relevant parts?

BurningPenguin 4y ago

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]
  - 4y ago

csmpltn 4y ago

I'm not an Uncle Bob fan by any stretch of the imagination, but he wrote a somewhat famous article about this phenomenon: http://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html http://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html With each new wave - we get people that either lack the time, the willpower or the conditions to understand what came before them (the ground they're standing on), and this is how we end up rediscovering things every 2-3 years. It's much more tempting to just discard old knowledge, reinvent from scratch. People were doing "SSR" with PHP on the server-side 30 years ago, and still do today (can you imagine just how much progress that platform has made, and how much collective knowledge has been developed around it?). It's just not hip anymore, because it wasn't invented within the past 36 months.

thisiswrongggg 4y ago
Yeah, he should know. There so much irony of this criticism coming from a guy that contributed to the max to the entropy of dubious and cargocult terms and "principles" in the field.
zepolen 4y ago
You can't compare JS SSR with PHP, SSR implies there is CSR which is not the case with PHP. Then having one language, no, one _shared code base_ for both client and server, which automatically can only send the minimum necessary over the wire? That's a _huge_ step forward. And I say this as someone who was developing CGI scripts before PHP came along.
- csmpltn 4y ago
  > "Then having one language, no, one _shared code base_ for both client and server, which automatically can only send the minimum necessary over the wire? That's a _huge_ step forward." This is exactly the kind of non-nuanced, buzzwordy and handwavy advertising I was ranting about. 1. Why should having the client and server share the same codebase even be a goal in the first place? This should be a nuanced conversation with different trade-offs, there's no one-size-fits-all here. It's disingenuous to paint this as an ideal we all have to work towards on a whim. 2. I don't even know where's the innovation in being able to "send the minimum necessary over the wire". This is a pillar of decent software engineering. We've been severely regressing here due to the pervasive use of bloated abstraction layers, combined with a deep lack of understanding of how things work (ref. the Uncle Bob post I've linked earlier).

dheerajvs 4y ago

> it ships only the JS for select components So, even if the page has a single React component, does it ship the entire react + react-dom bundle?