Hacker News Reader

Comment by SimeVidas | Hacker News Reader

If a website that is rendered in the browser using a JS framework adds SSR, does that mean that the client-side JS code will be delayed (not render-blocking) so that the first render can happen? How does that work?

View on HN

If I understand you correctly, then the answer is no. As strogonoff mentions in his comment[0], most of the frameworks that provide helpers to enable SSR also provides a way to "rehydrate" in the client side. React has to ways of rendering the app to a string, where one of them outputs html that can be used as the basis for rehydration[1], while the other one[2] drops any extra DOM attributes that the former adds.

[0] https://news.ycombinator.com/item?id=23446779

[1] https://reactjs.org/docs/react-dom-server.html#rendertostrin...

[2] https://reactjs.org/docs/react-dom-server.html#rendertostati...

The thing that I don’t understand is, how can the browser render the SSR content if the JS bundle is render-blocking? Doesn’t the JS bundle prevent anything from rendering until all its JS has been executed?

It's only render-blocking if put before the content! You can actually see this if you load up the demo[0] and reload the page. For some reason, I've made the mistake of putting the script-tag for the JS bundle _after_ the main content but _before_ the footer. The footer is also rendered on the server, but you'll see - especially if you throttle your connection - that the main app will appear instantly, but the footer ("Try without javascript :)", etc.) won't appear until the JS has finished loading.

This is why today it's common to put script-tags for external JS at the end of the body-tag.

[0]https://todo-react-redux-noscript.herokuapp.com/

Thanks. That explains it. I wasn’t sure if <script> at the end of <body> blocks rendering of the preceding content. Apparently not.

Reply on news.ycombinator.com