Chris Pappas

Why Kindling Uses React.js

As a small but growing software company, we have to spend our engineering resources where they are most beneficial to our customers. Fortunately, there are many giants on whose shoulders we can stand through their contributions to the open source community, which allow us to be vastly more effective and efficient in developing our products.

As Senior Developer here at Kindling, one of my main undertakings has been to migrate our front end to React.js, a JavaScript library that was developed by Facebook. I heard about React in 2013, when Facebook announced it at JSConf, the premier conference for JavaScript developers, where new technologies and approaches generally debut.

Before React we had been primarily using Backbone, which a great majority of our current application is built on top of, but we also investigated other technologies, such as Angular and Ember.

The first (and most obvious, though not necessarily the most important) difference between React and other frameworks is performance. React ships with a novel approach to handling changes to the DOM (Document Object Model—or, in layman’s terms, the HTML that the browser renders) based upon “diffing.” With React, if one wanted to update, say, a section in the application view, rather than destroying the entire section and rebuilding it to show new content, React analyzes the old content and the new content and computes the minimal amount of changes necessary to make the update, and then only executes those changes. This leads to massive improvements in page rendering time.

DOM diff in react.js

A far larger and more important improvement is the way React enables developers to build applications. Prior to its release, the primary programming “design pattern” for building user interfaces was something known as MVC—Model, View, Controller. Changes to the Model would force an update to the View, with the Controller coordinating those changes. For small applications this pattern works great, but as things scale you end up with a lot of different wires crisscrossing throughout your code, with maintenance growing ever more complex. React throws this pattern entirely out. Rather than having independent components each listening to one another, React favors a unidirectional (or circular) approach that says: “Whenever there is a change to the data, destroy the entire application model and rebuild from scratch.” This design pattern is called Flux. And since React diffs the DOM and only updates what is needed, there is no performance penalty. This allows developers insights into the application’s behavior that were far more difficult to see when using the MVC pattern.

Flux design pattern

In addition to these and a vast array of other smaller advantages, React.js, as opposed to other frameworks, embraces simplicity. Rather than providing developers an entirely new toolkit they have to learn in order to build apps, Facebook said, "Let’s just provide what’s needed, and everything else can be written in pure JavaScript." The benefit of this cannot be overstated, and any developer who curiously browses the labyrinthine docs for Google’s Angular framework will immediately understand the implications. There is simply much less cognitive overhead.

Implementing React at Kindling has had an enormous impact on our development time. Before, there was a clear separation between UI Engineering and design / CSS, with our designers generally handing over their comps to engineering in order to implement. Now, engineering and design can work together because what we’re dealing with in the end is just HTML and markup. Additionally, since the inner workings of the application are now far more transparent, when bugs arise the time it takes to diagnose and fix them is much shorter.

Lastly, the thing that I personally LOVE about React is the confidence it inspires in building new features, regardless of what they may be. Every programmer and engineering team understands the anxiety that comes when introducing a large piece new functionality into an already existing codebase. With React, this anxiety is far, far less.

In sum, React enables our team to be vastly more nimble, with a newfound capacity for rapid iteration, experimentation, simplicity in A/B testing, faster responsiveness to customer feedback, testability, and more.

Interestingly, and for good reason, the React model of application development is spreading like wildfire, and is extending beyond the web. This is due to the fact that the “React Way” is fundamentally a concept or approach. By following the same pattern, one can look at building native applications in the same way (see the recently released React Native), or desktop apps, or even—as is the case at Netflix—entirely new Smart TV and video game console experiences. This list of potential future applications will only grow.

Keep a lookout for things that were just not possible before, and an in-general “leveling up” throughout the industry. Time to market is substantially decreased, and with that quality will increase. React.js—and all of the innovation it has inspired—was the missing link to the web renaissance that we’re now embarking upon.