Why Choose React? (Part 1) An atmail Perspective

We’ve made a number of changes with the development of the latest version of atmail. Some of these changes have been more of a style or philosophy based change. Many have been more procedural. All of them have been based on function and need. I think the decision to move to React for our JavaScript library exemplifies all of these things and in a series of blog posts, I’d like to share why atmail chose React.

 

What is React?

React is an open-source JavaScript library for building user interfaces. It was created by Facebook and first deployed in 2011. In 2013, it was released as open-source and has since been implemented by heavyweights such as Netflix, Instagram, The New York Times, WhatsApp, Yahoo! Mail, Dropbox and Atlassian.

React.js is event-driven, stack independent and implements a one-way reactive data flow. It “allows developers to create large web-applications that use data and can change over time without reloading the page. It aims primarily to provide speed, simplicity and scalability.” Source

 

 

So, why choose React?

There are a number of JavaScript engines out there to choose from, so, why choose React?  There are a lot of things we like about React and as we’ve continued to use it, we like it more and more.  Some of the key things that stuck out to us at the onset were that:

• It’s just JavaScript;
• It promotes code reusability;
• It reduces coupling and increases cohesion; and
• It’s FAST.

 

Code Reusability and “It’s just JavaScript”

These first two are really tied together. React is designed around this idea of reusable components. Even if you are not writing code, you can see the advantage of reusing what you’ve already done. Basically, you define smaller components and use these to build larger components.

What is a component? In it’s simplest form, a component is just a JavaScript function. It’s just JavaScript.

 

Reducing coupling and increasing cohesion

Coupling is the degree to which each program module relies on each of the other modules. Coupling can be either tight or loose. This depends on how much one module relies on information from another. If a module requires a lot of other modules to work (tight coupling), it creates a program with more data paths to keep track of. This creates more chances for bad data to get passed from one module to another and an overall headache when it comes to maintaining your code. Consequently, if you can create modules that don’t depend as much on as many other modules (loose coupling), it actually makes modules easier to write, maintain and reuse.

Cohesion is the degree to which elements of a module belong together. In general, we want more cohesive modules, where all of the operations (the actual internal statements of the module) go together or are related and serve an actual purpose intended. These modules are usually more reliable and make programs easier to read, write and maintain.

I think most people can see the value of tighter coupling and more cohesion in a solution. To help you understand more, we’ll sit down with some of our development team this year and share more of the nuts and bolts of how we do this at atmail.

 

React is FAST!

One of the things I really like about React is the virtual DOM. The virtual DOM keeps track of what changes need to be made in the actual DOM. It then pushes these out faster and more efficiently. It basically re-renders the entire component each time there is a data change.

How does that work? Isn’t that expensive?

Nope, the beauty of the virtual DOM is how it works.

Basically on every update:

• React builds a new virtual DOM subtree;
• It then compares this with the old one;
• Next, it computes the minimal set of DOM mutations and puts them in a queue; and
• Finally, it batch executes all updates.

If you’re a video game player, you might best understand React by comparing it to the Doom 3 engine*…

Here, the game state (where you are on the map, character details, weapon, etc.) is passed into the “front end” of the Doom 3 Engine, which executes the game logic.

This then creates an intermediate representation of the scene.

This then gets passed to a “back end” render, which generates the OpenGL operations.

Finally these get pushed to the graphics card.

React works in a very similar way.

 

When something changes in the application state (either a browser or realtime event), the application takes the current state and passes it to your components to create an intermediate representation of your user interface (similar to the intermediate representation of the scene in the game) using the virtual DOM.

No changes are made to the actual DOM yet.

React takes the virtual DOM and calculates the DOM operations needed, then pushes these into a queue to be batched when it is most efficient.

The browser then takes the DOM and renders it to the screen.

 

The philosophy of change

I look at the decision to move to React in much the same way I look at the adoption of JMAP within atmail. Most of all, it is a great tool that fits in with many of the other changes we’ve made. It suits our style, our overall philosophy of design and even the overarching philosophy we adhere to as a company. This change was good for us and it has helped us create a better product that I am proud to be a part of.

This has been a very quick glimpse into why we decided to make a change, a fairly major change actually. While looking more closely at this decision (and others), I’ve had a number of great conversations with our development and management teams about other reasons we’ve decided to go with React and I am working on sharing more of those conversations with everyone in some follow-up posts on React. (If there is a particular topic or some way you would like to see this shared, please leave us a comment or suggestion below. Thank you.)

 

* Pete Hunt did a great job of explaining this in his presentation on React: Rethinking best practices at the 2013 JSConf in Berlin. Video here:

 

 

Interested in ‘Why Choose React (Part 2)’?

If you’d like to read (or listen to) the next instalment in our React series, we invite you to click on, Why Choose React? (Part 2) A conversation with Brad Kowalczyk. (Added 4 April 2018)