Fretless

React.js and Flux Made Me Like JS (Again?)
By Miles Z. Sterrett /

Chimera from Greek mythologyI made it known to those who work with me regularly - whether they wanted me to or not - that I hated JavaScript. Like everyone else, I had written jQuery-heavy monsters of knotted, warty code fit together like a failed experiment in creating a chimera. You know what I mean - all the horror of combining a lion, a goat, and a snake, but with obvious seams and too few legs. I had written Backbone, Knockout, and dabbled in others on the front-end - with good intentions and a positive attitude, I swear. I wrote a Node.js app in an early version of Express. All of these things piled atop one another and led me to the conclusion: I hate JavaScript.

I more or less gave up a couple years ago.

I recently began working with Kyle Shipley at Health Pro on an internal project using React.js. The framework was released well after I threw my hands in the air in disgust at the state of JavaScript and its ecosystem. It turns out a lot has happened since then, and it’s been overwhelmingly positive. Though I will always enjoy making jokes about a new JavaScript library appearing every second, I now see the quality and robustness in the community that I was missing before. React is a huge part of that - for me.

There are a few primary reasons React has me so excited to be writing JavaScript again. I am not going to talk about what React is, what it does, etc. You’re way smart, man. You can follow links, and probably search on the World Wide Web when other means fail you. I’m just going to tell you what I like about React.

Virtual DOM

When you are writing front-end JavaScript, you are typically manipulating the DOM directly. For instance, press a button, your code receives the event, and updates a counter somewhere on the page. Easy, at least in this small example. As the industry has progressed in to heavy single-page applications, there might be a myriad of different manipulations to do with each action taken by the user. Manipulating the DOM is expensive.

React added a layer between the code you write and the DOM itself, called the Virtual DOM. To oversimplify it: it maintains a virtual representation of the DOM. When a change is made, it compares this virtual representation to the actual DOM, and makes only those changes that must be made to reconcile the two. It effectively batches changes from an action, improving the efficiency of making those changes.

React’s architecture is also heavily influenced by this. When you are building a page in React, you are typically stacking Components on top of one another to build a coherent interface. Each component is primarily concerned with simply rendering its markup with what it currently knows (its state). Let’s say you’ve a button that adds 1 to a number displayed next to it every time it is pressed. In React, you would simply update the component’s when the button is clicked. React will check for a difference and handle the re-rendering. The result is a tidy bit of code that is easy to understand.

There’s a much better explanation of the virtual DOM than I could manage in Architecting Your App with React, Part 1. It compares the React to the Doom 3 rendering engine.

Conventions

Ruby drew me to Rails, but the conventions Rails forcibly suggested upon me were the glue on the flypaper that kept me there. (Well, here.) One of my issues with Backbone, and even to some extent other frameworks a couple years ago, was that they seemed to simply offer you some prototypes without much opinion as to how exactly you should use them.

Facebook’s Flux is the set of conventions that I think will stick me to React for a while to come. Flux is billed as “An Application Architecture for React”. That’s just fancy English for “these are the conventions with which we believe most people can be successful”. And they’re good.

Flux is basically the principle that data should flow in a single direction. This concept avoids the more-typical two-way data binding that makes your neck feel like you’re watching a tennis match between Superman and The Flash. You know - the thing that seems really sexy in every framework’s demo, but becomes a damned nightmare as the app grows.

With Flux, React becomes a full framework with conventions that keep you - that wayward, out of control railcar that each of us is at heart - on track, on your way to the terminus. (Not the one from The Walking Dead.)

Software Craftsmanship

Like an old brick farmhouse, React and Flux feel built to serve their tenants, to be comfortable, and to last. They feel as if they were very carefully constructed by folks with a passion for their craft. Built of individual pieces that seem simple and easy to reason about, they combine elegantly to build a complex entity that is still easily recognizable.

React starts with its components. You might have a TodoApp component, that consists of TodoLists, which have TodoListItems. Each one is self-contained (yes, HTML inside each class) and easily identifiable. A user adds an item, an action is dispatched, the TodoListItemStore adds the item, and notifies any component that cares that data has changed.

It goes deeper than that, though. Even method names seem carefully considered.

I’m waxing poetic at this point. Let me point you to a couple resources I think might help.

No, no. I don’t think you’re stupid. I think I am stupid. Or, at least, reading other people explain React and Flux made me feel stupid. I don’t want you to feel stupid, so I’m starting you out with someone’s explanation for stupid people. (Listen, it makes a sort of sense. Just give it a second.)

I could go on forever about things I enjoy about React, Flux, and - now - the wider JavaScript ecosystem. If you want to hear more, email me and we’ll go get some coffee sometime. I’ll tell you all about it. (If it gets boring, the coffee can be your warm, soothing distraction.)