❮ Back to index

A tour of modern frontend with React and Flux

We are available for Go/Python/Haskell/Data Science projects. Drop us a mail at [email protected]!

Reading time: ~10 minutes.

In this article we are going to have a look at my preferred set of tools for writing React/Flux web apps. If you don’t know React or Flux, you can finds their documentation at their respective websites: React, Flux.

Tools of the trade

The React community is embracing ES6 — and sometimes ES7 — through Babel. For those not doing any frontend, ES6 is the new Javascript standard and ES7 is the one that should become the standard next year. Most browsers only support up to ES5 though so we need to compile our “future” code to something current browsers can understand, which is Babel’s job. I personally like Typescript but recently decided to go with Babel for a few reasons:

  • A constant changes in libraries and their sheer number were making it very hard to keep up-to-date definitions
  • Typescript is still lacking support for some things, making some libraries like ImmutableJS and its records very hard to use in a type-safe way
  • Getting tired of casting things to because of the compiler not picking up the correct things

I do very much like types though and since they are not in the horizon of ES standards, so I will have a look at Flow when it fully supports ES6. Flow differs from typescript by only being annotations that you can strip down and inferring as much as possible from the context instead of being a language like Typescript.


If you look at most React/Flux boilerplates, you will notice they often use different tools than you might be used with Angular for example.

Firstly, as mentioned in the previous section, Babel is omnipresent along with its linter of choice, eslint.

A good number of projects eschew tasks runners such as gulp in favour of a tool called Webpack and npm tasks. Webpack is a module bundler like Browserify but while Browserify takes the Unix philosophy of having small modules working together, Webpack comes with a lot more out of the box. Both works great though, so choose the one you like the most.

One feature that made Webpack stand out early on with React was hot reloading using react-hot-loader but is now available as LiveReactload for browserify.

Testing wise, I have seen lots of repos using jsdom which seems backwards to me as we can run tests in actual browsers using Karma for example.


In terms of actual dependencies, we obviously need React. Since 0.14, you will also need the react-dom package to actually render.

In terms of Flux implementation, my favourite is Redux which actually deviates of the Flux reference, leaning towards a FRP (look here for a nice introduction on Functional Reactive Programming) approach like Elm and having pure functions.

The documentation of Redux being first-class, I will not write about it and invite you to read it, even if you aren’t planning to use it. Bindings for React can be found under the react-redux package.

A very nice thing about having pure reducers in Redux (the equivalent of stores in Flux) is that you can easily build time-travelling tools, replay actions and testing become trivial. Look at redux-devtools for the official one.

Lastly there is another optional dependency I like: ImmutableJS. Reducers in Redux are pure but using ImmutableJS gives us a faster shouldComponentUpdate (more info) as we can compare our props by reference rather than inspecting their values deeply.

A boilerplate

Looking at that list may appear daunting at first and plenty of boilerplates exist but they didn’t fit my own needs as I was first writing it in Typescript.

Switching to Babel was pretty trivial as it only involved changing loaders in webpack and the linter.

You can find the boilerplate on github and you can have a look at this example for a toy project made with that boilerplate.


Combining live reload of components and reducers with the simplicity and easy testing of React and Redux makes for a very good developer experience. Some may wonder why not use Elm, ClojureScript or PureScript when looking at what we end up (and we would get types in some of them too!). This is a good point and we are going to look into Elm more seriously in the coming weeks so expect a post about our experience soon.