Thanks for the great article, I’ve been working with React for a while but have yet to use its server-side rendering capabilities.

A small note on the Webpack config: Instead of specifying the absolute path to the entry point, you can also use a correct relative path like `./client-render.js`. And if you call the file `webpack.config.babel.js` it will automatically be processed by babel before Webpack loads it.

One note: I had to install the ‘history’ npm package separately in order to get React Router to work. Not sure if that is a change between this article being written and now (the React Router docs do say to install it), or just an accidental omission on the author’s part.

I broadly agree with those who are saying there’s no real business case these days for users with JavaScript explicitly disabled. I’d also disagree with those who are saying you need server rendering for search engines; Google and others now support JavaScript.

However, for me the real strength with the server rendering is getting a readable/usable page to the user faster, particularly when that user is on a slow connection and/or an underpowered device , the combination of which might mean it would take 10+ seconds to download and execute the JavaScript and render the first view.

Going a step further, one could imagine doing a bit of client-side logic based on the aforementioned conditions to decide whether to load the JavaScript app at all or just let the server rendering handle it.

I’m interested to see where this goes with React, Angular and Ember over the next months and years. Great article, Jack.

Jack, brilliant article. This is a very gentle introduction to pretty much that’s how right now; I had never paired React and Webpack with server side rendering and I’m surprised at how painless a very simple implementation can be.

I do have a question, though. Naturally, the routing works perfectly well on the server when hitting /about directly. When running on the client though, trying to refresh a page from /about directly triggers a route: it’s expecting the hashbang. I was under the impression that react-router took care of this magic on its own but apparently it does not! How does one go on about making sure that seamless routes between server and client are handled correctly?

Once again, thanks for the very clear, concise and well written article!

Nice tutorial, very clean and easy to understand. But I agree with Greg Guepy, that disabled JS in browser is not a thing to care about today :).

My company has open-sourced a real project (that is in production already) https://github.com/webbylab/itsquiz-wall . It covers a lot of issues beyond this tutorial, like data fetching, working with styles, choosing components library etc. Maybe it will be useful. Moreover, several days ago I wrote a post about this issues – http://blog.koorchik.com/isomorphic-react/

This article is fantastic. Not only is it a great introduction to isomorphic JS with React, but also to writing node/express and other server-side JavaScript in ES6. There aren’t many resources out there yet.

Users with JS disabled on their browsers may not be an issue, but SEO certainly is.

Yes, Google may now index pages that are generated by JS on the client, but not all search engines do that.

And all other things being equal, Google ranks faster loading pages ahead of slower ones. So which page do you think that Google is going to rank higher? A page that comes down from the server with all of its HTML already in place, or one that has to download a load of JS to generate its HTML? Keep in mind that for the latter, the JS has to download, parse then execute before the user even sees anything!

For me, there is added value in rendering server-side. The whole point of React was for faster rendering on mobile devices. The less work a mobile device has to do, the better for its user. Devices are wide in spec and capability, but they all load content. Let the server do the grunt work, then the mobile device only has to consume the html.

Browsing the web on a mobile device remains – for many – a rotten experience. Not everyone has, or wants to, spend lots on a mobile. Think about parts of the world where data consumption can be very costly, or is subject to frequent bouts of dropped connections. Articles like this show a way forward to make the mobile web a better experience for all.

Thanks for the nice introduction.
I would also like to note that server side rendering can be very useful if many of your users use proxy browsers like Operamini where JavaScript is almost not supported.

I noticed the server side only handles GET requests. How would the above example be extended to support POST requests too.

This is awesome! Isomorphism is one of the things holding me back from diving into a framework. Have you used this technique on any projects which interact with an API for their data store? I’d love to see more complicated code samples :)