Mastering server-rendered React

React Amsterdam, 16 April 2016. The talk is called Mastering Server Rendered React. I work at Inmeta. I had just published ReactJS Blueprints.

You may know it as isomorphic. Or universal. The name does not matter. It is about sharing code between the server and the browser, and about delivering content before the user has decided to leave.

A bit of history: PHP had Smarty and Twig. Java had JSP and Thymeleaf. JavaScript had Express with Swig or EJS. Then React asked whether the view could be the same function on both sides.

Page load is the moment you lose people. JavaScript is slow when the computer is slow, when the connection is slow, when the phone is slow, when the machine is not theirs (school, library), when they meant to read offline, when they are Google cache or the Internet Archive, when they run NoScript, when they run an ad blocker and you named a critical bundle after ads. All of those cases get better if you render before you serve.

The behaviour we want: write code you can use everywhere. Render the app so the client does not have to. Let the dynamic bundle take over for interactivity. There was a demo at http://reactjsblueprints-shared.herokuapp.com/.

The recipe is small. A Node/Express server. Import the same routes the browser uses. Import the same API methods. Fetch on route change, then render. Advantages: less work on the client, reuse of frontend code, the page still works if the JS bundle breaks, if the user has NoScript, if the visitor is a bot. Drawbacks: a more complicated server file, a fetch before render, and it is relatively slow until you add cache. Streaming helps.

Resources from the last slide: http://bit.ly/isomorphicreact, Fluxible out of the box, http://bit.ly/reactjsbook. Tweet with #reactamsterdam.

The archive already hosts these pages with renderToString and a hydrate in the browser. That is the same bet, later runtime.