A useful pattern I discovered was fetching just what is necessary to render the page on the server. Then pass the state to the window object through a script tag and recover the data on the client side and rehydrate. Any additional data (or potentially slow returning), I fetch client side via `componentDidMount` [0] which isn't called on the server. This way, I can get a loading screen up as quickly as possible with a few elements custom to the user.

I should note that even thought the flux library I was using, flummox [1], works great for this, I can't recommend it as in the month and a half I was working on my project they've decided to quit and recommend a different library, so I'm not sure what to recommend now (the frustration I feel over this quick turnaround is an entirely separate topic, though).

0: https://facebook.github.io/react/docs/component-specs.html#m...

1: http://acdlite.github.io/flummox

2: https://github.com/acdlite/flummox#40-will-likely-be-the-las...

To the original point, you are still sending the data twice, once in rendered html, and once in that state that gets rehydrated.

The entire rendered source is 142K. I isolated the actual markup, and it weighs in at 31K.

In other words, your dehydrated state is 4x bigger than your html rendering. And that's not including your 750K main.js file that also gets downloaded.

That's almost 1MB of downloads (not including images and stylesheets) just to "app-ify" your 31K of markup. I tend to agree, it's not a problem. Or perhaps, it's not one of the biggest problems. But it's not "hardly an issue" either.

A harder fix is to walk the static DOM to inflate your store. It shouldn't be too hard since you can add hints to the DOM to guide your parser.