3 ms·

I used to think the same about server-side rendering until I more closely looked at React SSR. I think it makes a lot of sense and allows for faster initial re

I used to think the same about server-side rendering until I more closely looked at React SSR. I think it makes a lot of sense and allows for faster initial rendering of the page while automatically setting up the JS and interactivity in the background.

sublinear 9mo ago
Couldn't you just static render the parts that you're using SSR for? I am not trying to be dismissive, but a common strict requirement is static hosting from a CDN, embedded environments, etc.
- user34283 9mo ago
  If you static render, it won't be an interactive application. With React SSR you get the best of both: stream static HTML chunks immediately, and rehydrate with JS later, prioritizing components the user interacts with. It should load quicker compared to traditional React apps where the browser loads the HTML, then loads the JS bundle, and only then renders a loading skeleton while likely triggering more requests for data.
  - sublinear 9mo ago
    Static rendering has nothing to do with interactivity in a web app. I guess if you're already so deeply entrenched in writing all your application logic on the server side you need React SSR, but that sounds miserable.
  - DrammBA 9mo ago
    You seem to be confused about your terms, both SSR and SSG can rehydrate and become interactive, you only need SSR if you have personalized content that must be fetched on an actual user request, and with frameworks like astro introducing island concept it even let's you mix SSG and SSR content on a single page.
    - user34283 9mo ago
      That depends on how you interpret "static render". I did not interpret that as React SSG. SSG is the default behavior of NextJS unless you dynamically fetch data, turning it into SSR automatically. What I thought of is React's "renderToString()" at build time which will produce static HTML with event handlers stripped, in preparation for a later "hydrateRoot()" on the client side.
      - DrammBA 9mo ago
        > That depends on how you interpret "static render". It only depends if you interpret it incorrectly.
  - zarzavat 9mo ago
    > It should load quicker compared to traditional React apps where the browser loads the HTML, then loads the JS bundle, and only then renders a loading skeleton while likely triggering more requests for data. Then your JS bundle is broken. Promises exist. Modules exist. HTTP/2+ exists. You can load data while you are loading a small amount of JS required to render that data while you are loading other parts of your JS. If everything is sequential: load giant JS bundle -> fetch -> render, that's because someone architected it like that. Browsers give you all the tools you need to load in parallel, if you don't use them then it's not the browser's fault. You do not need SSR or rehydration. That's just Vercel propaganda. They saw that people are doing a stupid thing and decided to push a complex solution to it. Why? It makes them money.
    - user34283 9mo ago
      You cannot load any data in a regular React application before you loaded both React and your React components that trigger the fetch. If you use code splitting, your initial bundle size can be smaller, yes. That's about it. I guess in theory you can hack together static loading skeletons that you then remove when React loaded your initial bundle, but that's certainly far from a common approach. By that standard, the vast majority of JS bundles would be "broken".
      - zarzavat 9mo ago
        > You cannot load any data in a regular React application before you loaded both React and your React components that trigger the fetch. You totally can! Don't call fetch directly from a component - it's brittle. Write a hook to abstract that into one place. In your hook you can support prefetching by awaiting the promise you fired before you loaded your JS bundle (if you don't want to modify the server), or else take advantage of the browser cache. In this way your data and code can load in parallel. Is it common? Not really. But it's a technique that is in the toolbox of a conscientious webdev.
        user34283 9mo ago
        Hm, I guess with the new "use" hook and Suspense I guess you could more easily sync up the Promise from another bundle with React later. However, I have never seen such an approach recommended before.
williamcotton 9mo ago
React has always supported server-side rendering and there have been many tools over the years to "rehydrate" data from the server to the client for when the client-side React application "takes over".

sublinear 9mo ago

Couldn't you just static render the parts that you're using SSR for? I am not trying to be dismissive, but a common strict requirement is static hosting from a CDN, embedded environments, etc.

user34283 9mo ago
If you static render, it won't be an interactive application. With React SSR you get the best of both: stream static HTML chunks immediately, and rehydrate with JS later, prioritizing components the user interacts with. It should load quicker compared to traditional React apps where the browser loads the HTML, then loads the JS bundle, and only then renders a loading skeleton while likely triggering more requests for data.
- sublinear 9mo ago
  Static rendering has nothing to do with interactivity in a web app. I guess if you're already so deeply entrenched in writing all your application logic on the server side you need React SSR, but that sounds miserable.
- DrammBA 9mo ago
  You seem to be confused about your terms, both SSR and SSG can rehydrate and become interactive, you only need SSR if you have personalized content that must be fetched on an actual user request, and with frameworks like astro introducing island concept it even let's you mix SSG and SSR content on a single page.
  - user34283 9mo ago
    That depends on how you interpret "static render". I did not interpret that as React SSG. SSG is the default behavior of NextJS unless you dynamically fetch data, turning it into SSR automatically. What I thought of is React's "renderToString()" at build time which will produce static HTML with event handlers stripped, in preparation for a later "hydrateRoot()" on the client side.
    - DrammBA 9mo ago
      > That depends on how you interpret "static render". It only depends if you interpret it incorrectly.
- zarzavat 9mo ago
  > It should load quicker compared to traditional React apps where the browser loads the HTML, then loads the JS bundle, and only then renders a loading skeleton while likely triggering more requests for data. Then your JS bundle is broken. Promises exist. Modules exist. HTTP/2+ exists. You can load data while you are loading a small amount of JS required to render that data while you are loading other parts of your JS. If everything is sequential: load giant JS bundle -> fetch -> render, that's because someone architected it like that. Browsers give you all the tools you need to load in parallel, if you don't use them then it's not the browser's fault. You do not need SSR or rehydration. That's just Vercel propaganda. They saw that people are doing a stupid thing and decided to push a complex solution to it. Why? It makes them money.
  - user34283 9mo ago
    You cannot load any data in a regular React application before you loaded both React and your React components that trigger the fetch. If you use code splitting, your initial bundle size can be smaller, yes. That's about it. I guess in theory you can hack together static loading skeletons that you then remove when React loaded your initial bundle, but that's certainly far from a common approach. By that standard, the vast majority of JS bundles would be "broken".
    - zarzavat 9mo ago
      > You cannot load any data in a regular React application before you loaded both React and your React components that trigger the fetch. You totally can! Don't call fetch directly from a component - it's brittle. Write a hook to abstract that into one place. In your hook you can support prefetching by awaiting the promise you fired before you loaded your JS bundle (if you don't want to modify the server), or else take advantage of the browser cache. In this way your data and code can load in parallel. Is it common? Not really. But it's a technique that is in the toolbox of a conscientious webdev.
      - user34283 9mo ago
        Hm, I guess with the new "use" hook and Suspense I guess you could more easily sync up the Promise from another bundle with React later. However, I have never seen such an approach recommended before.

williamcotton 9mo ago

React has always supported server-side rendering and there have been many tools over the years to "rehydrate" data from the server to the client for when the client-side React application "takes over".