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.

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:

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.

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.

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.

- by .