These posts that detail the setup are great, especially with constantly changing API's like webpack version 4 and react-dom's hydrate versus render.
I really love getting server-side rendering to work, it's just so magical to be able to use the app's component code on both the client and server side. And it's great for sending over pre-rendered markup, which eliminates much of the initial wait time while the app is fetching data.
However, it's important to note that the performance gain is mostly client-side. Enabling server side rendering creates much more work for the server. The server becomes responsible (at least for the first load) to fetch the data to hydrate the initial state in addition to rendering the markup.
Performance and complexity is even more pronounced for web apps with non-Node.js backends. Most server-side frameworks have packages that let you render JavaScript on the backend, but they are typically bindings to the v8 JavaScript engine, which is a significant overhead to consider.
It would be interesting to see a post that describes a good strategy for splitting the routes in a react-router-powered React app that need rendering and those routes that do not (like public article/posts that want to be indexed versus a private profile administration page behind an auth wall).
These posts that detail the setup are great, especially with constantly changing API's like webpack version 4 and react-dom's hydrate versus render.
I really love getting server-side rendering to work, it's just so magical to be able to use the app's component code on both the client and server side. And it's great for sending over pre-rendered markup, which eliminates much of the initial wait time while the app is fetching data.
However, it's important to note that the performance gain is mostly client-side. Enabling server side rendering creates much more work for the server. The server becomes responsible (at least for the first load) to fetch the data to hydrate the initial state in addition to rendering the markup.
Performance and complexity is even more pronounced for web apps with non-Node.js backends. Most server-side frameworks have packages that let you render JavaScript on the backend, but they are typically bindings to the v8 JavaScript engine, which is a significant overhead to consider.
It would be interesting to see a post that describes a good strategy for splitting the routes in a react-router-powered React app that need rendering and those routes that do not (like public article/posts that want to be indexed versus a private profile administration page behind an auth wall).
Agree. Great comment.