/ Life at SC5

What we learned from React Europe

ReactEurope is a European sibling conference for React.js Conf, a conference about Facebook’s React. Organised the first time, the European version of the conference gathered some 700 coders to Paris including a strike team from SC5.

You may ask why a couple of years old JavaScript library should have its own conference? First of all, React has seen some quick and wide adoption even in big companies doing big things. And second, the conference showed that people are doing some quite interesting and sometimes crazy things with React, all worth sharing.

What is this React thing anyway?

One theme of the conference was exploring what React is, and what it should be in the future.

Sebastian Markbåge started with the observation that React packages like React Native and React Canvas don’t render to DOM and took it to its logical endpoint: maybe React should bypass DOM, and the browser, and render straight to GPU.

React’s new version 0.14 shares the philosophy to a degree and separates React and React DOM into separate packages:

We think the true foundations of React are simply ideas of components and elements: being able to describe what you want to render in a declarative way.

Even the Flux Architecture lends itself to very diverse implementations that cover a wide range of needs. The conference showcased several architectures based on Flux, each with a specific design goal. One particularly wild idea is to run Flux over the wire using socket.io (see video of Elie Rotenberg’s talk).


The previous React.js conf in January unveiled React Native which allows creating native iOS apps with React. Some were expecting Android support for React Native to be announced at this conference but it remains still a couple months away.

The biggest news in the conference were the releases of a specification draft for GraphQL and a reference implementation for GraphQL in JavaScript. GraphQL is a query language which allows client software to specify the data it needs and the data structure it should be returned in. GraphQL combined with Relay forms a powerful tool: Relay allows individual React components to specify what data they need, and handles all data fetching logic behind the curtain. See video of Joseph Savona’s Relay presentation

GraphQL has been used internally at Facebook for several years now and Lee Byron did a great job explaining the benefits they’ve seen so far building Facebook’s native apps. Here’s a video of Lee’s talk. To sum it up, GraphQL further decouples servers and clients: the server exposes some data, and each client can pick and choose what data they need.

The promise of GraphQL is to make client data requests much more simpler than using a REST API. With a REST API the client might need to request data from multiple endpoints, keep track of all requests, and manually combine the received data to form the final data structure. The client would also receive data it might not need.

API changes should also become more manageable. A GraphQL server can add new capabilities without the need for versioning the API because old clients can keep asking the data they want. Clients requiring new data in new formats might not impose any changes on the server if the needed data has been exposed.

Existing REST APIs could potentially be wrapped inside GraphQL, making it the back-end’s responsibility to query the data from different sources and to form the needed data structure for the response.


If we had to name a buzzword for the conference, Developer Experience would be it. One clear goal of the React project is to make the developer’s life easier. This benefits the end-user too: a developer not fighting their tools has more time and energy to build things that matter.

“If you have great developer experience, you are much more likely to get to a great UX” –@jedwatson

One crucial part of DX are the build tools. The React community has largely adopted Babel to the point that Facebook recently deprecated their own JSTransform tool. Sebastian McKenzie described how in the future Babel could be used to perform code optimisation and linting, and analysing code for bugs.

Dan Abramov’s talk demoed a developer experience beyond live reloading: React Hot Loader reloads your app after a code change but keeps the app’s state. Dan achieved this using immutable data structures, Webpack, and his own Flux implementation Redux which looks very promising.


Overall the conference was a good review of “what’s new in React”. The topics were diverse but didn’t cover every possible aspect of React and luckily didn’t spend too much time on React basics. If you want to see for yourself you can watch the React Europe sessions on Youtube where they are being uploaded one by one.

React Europe 2016 is already being planned and will happen on 2nd and 3rd of June in Paris. We would recommend going if you work or would want to work with React.

Learn with us, join us!