To ReactJS and Facebook Flux

During the last 3 weeks we evolved our understanding of frontend stack.

LazoJS worked quite well in the cases that I dealt with. These were mostly simple feeds like news, inbox or conversation. However, it created some complexity and overhead for Tomas and Pieter as they explored encapsulation of UI elements and their reuse.

In short, in LazoJS it was quite complicated to create and apply a reusable component (e.g. avatar or like button).

While I focused on finishing features in LazoJS, Tomas and Pieter explored something else - ReactJS framework and Facebook Flux architecture.

In the end they discovered that Facebook Flux was a better fit for us in the long term (at least, better than the other previously explored options like custom PJAX, AirBnB Rendr and WalmartLabs LazoJS).

So we made a switch and then spent the last 2 weeks porting our frontend to isomorphic flux components from Yahoo. The investment of time was very worth it, I think.

What are ReactJS, Flux and Yahoo components?

ReactJS is a battle-tested javascript library for building user interfaces. It allows you to decompose your UI into very simple reusable components, which can then be composed together, rendered using Virtual DOM and then synced back to the HTML.

ReactJS is very fast and focuses on unidirectional data flow, which makes code much easier to reason about.

ReactJS is maintained by Facebook and also used by Instagram, Yahoo and Khan Academy.

Flux is a Facebook architecture for building User Interfaces out of predefined building blocks using one-way data flow. It looks very much like CQRS and is known to scale well in large organizations.

Flux architecture works very well with ReactJS. Here is what a developer from Facebook says:

From first-hand experience, I can say that React+Flux has scaled well to 8+ developers over 800+ JS files and ~60k lines of code in a large single page app here at Facebook.

At HappyPancake, we really liked how Flux helps us to decompose UI into components and also solve event cascade hell which is often present in apps based on BackboneJS or AngularJS.

Yahoo Flux components are a set of components open-sourced by Yahoo. These components implement various building blocks of Flux architecture for building isomorphic web applications: dispatcher, router and store.

Usually, single-page web applications render all HTML on the client-side. This means that the very first page load can take a few seconds or more: we need to load HTML, parse it, load all required JavaScript libraries, fetch the data for the current route, render it into HTML and then update the DOM. This doesn't work well for older browsers as well. Isomorphic web applications work around that by rendering first page on the server, so that user gets a user interface immediately. Javascript will be loaded later, turning the application into a usual Single-page application, with all its smoothness and responsiveness.

Why did we switch from to Flux?

The goal of the project is long-term. We don't simply want to build a new version of HappyPancake. Instead, we need to build a software that can continue evolving and scaling since the moment we release it. To achieve that, we have to iterate quickly through the possible development options as early as possible, while the cost of error is minimal.

HappyPancake is a unique project due to the number of factors, so we need to evaluate and pick the combination of options (both technical and design-related) which would be good enough for accomplishing long-term goals of the business.

Switch from LazoJS to Flux is an investment of time. In my estimates, it would pay off in 2-4 weeks already because of:

codebase is polished and supported by very large companies;
superior reuse of components;
code is simpler to reason about;
CQRS architecture is something that we know very well how to test.

There are a few technical challenges that we would need to solve in the upcoming days as well:

existing flux demos don't pay very much attention to solution structure; and we got very spoiled by the benefits provided by decomposition of the domain into focused modules. We already have some ideas, but would need to agree upon the conventions;
tooling for Flux is great, however there is no equivalent of gofmt/jsfmt for JSX files. We'll either need to wait for one or tweak existing solutions;
naming of some building blocks in Flux is very weird. For example, even Facebook developers frequently use interchangeably terms actions and action creators (equivalents of command handlers and command outcomes). We need to get used to that.

Despite these small drawbacks, I think that Flux is so far the best way to organize development of web user interfaces, where you need to manage the complexity and long-term development effort.

At very least, Flux works so in our specific case of rewriting an already existing (and most popular in Sweden) dating web site with a team of 3 developers distributed around the Europe.

So far we migrated to Flux a profile view, news feed (which is being renamed to discover, to match the purpose) and the chat. We need to do a proper 3-way team sync on the work accomplished before fanning out and working on the rest of the features. That's our plan for today and the rest of the week.

Published: October 27, 2014.

Next post in HappyPancake story: Project Complete

🤗 Check out my newsletter! It is about building products with ChatGPT and LLMs: latest news, technical insights and my journey. Check out it out