36 ms·

Server side rendering mounts your application in the server and sends down html along with an initial state. The client receives this initial state and uses it

Server side rendering mounts your application in the server and sends down html along with an initial state. The client receives this initial state and uses it with the html to glue together a working UI on the client. This removes the massive JS bloat into raw html and split JS for each component. Instead of sending 3MB of JS, you send only the JS needed to render the current page... and send additional JS as a user navigates through your website. Here's an example with Create React App: https://github.com/cereallarceny/cra-ssr https://github.com/cereallarceny/cra-ssr

kerkeslager 8y ago
Okay, but that's an even worse idea than what I've seen Redux used for. Now you're splitting the UI between client and server in a completely custom way, that adds even more complexity. Worse, the performance is likely to be worse because now you're paying the bulk JS load cost of loading Redux AND the latency cost of loading small parts as you go: the worst of both worlds. I doubt this is what the Redux folks had in mind, but if it was, it's even worse than I thought.
- s_y_n_t_a_x 8y ago
  Redux is tiny. And with HTTP2 it's better to send multiple small resources than one large payload, especially when it's JS which will lock up when parsing.
- kalcode 8y ago
  >because now you're paying the bulk JS load cost of loading Redux Gonna have to quantify that. Cause I imagine if you did, you'd redact that statement. Redux is a very straightforwards and SMALL library that handles global state. Its concept can be difficult to follow at first which may cause some to think it way more complex under the hood than it really is.
- WrtCdEvrydy 8y ago
  > you're paying the bulk JS load cost of loading Redux Redux is small. > the latency cost of loading small parts as you go The components are static JS split into files. Pop those into a CDN and you get the best of both worlds.

kerkeslager 8y ago

Okay, but that's an even worse idea than what I've seen Redux used for. Now you're splitting the UI between client and server in a completely custom way, that adds even more complexity. Worse, the performance is likely to be worse because now you're paying the bulk JS load cost of loading Redux AND the latency cost of loading small parts as you go: the worst of both worlds. I doubt this is what the Redux folks had in mind, but if it was, it's even worse than I thought.

s_y_n_t_a_x 8y ago
Redux is tiny. And with HTTP2 it's better to send multiple small resources than one large payload, especially when it's JS which will lock up when parsing.
kalcode 8y ago
>because now you're paying the bulk JS load cost of loading Redux Gonna have to quantify that. Cause I imagine if you did, you'd redact that statement. Redux is a very straightforwards and SMALL library that handles global state. Its concept can be difficult to follow at first which may cause some to think it way more complex under the hood than it really is.
WrtCdEvrydy 8y ago
> you're paying the bulk JS load cost of loading Redux Redux is small. > the latency cost of loading small parts as you go The components are static JS split into files. Pop those into a CDN and you get the best of both worlds.