jects or scope variables. Any changes there effectively become visible at multiple locations throughout your code at much the same time, meaning the composability issues surface since different locations in your code are made aware almost simultaneously of changes that propagate backwards from the UI.

PH: Another problem is that you might have multiple bindings to the same data source. So then which piece of code is going to be treated as the authoritative source for determining what the value ought to be?

This is why, with React, we emphasize one-way data flow. As I said earlier, data in our model first goes into this application black box, which in turn emits a virtual DOM representation. Then we close the loop with simple browser events. We’ll capture a KeyUp event and command, “Update the data model in this place based on that KeyUp event.” We’ve also architected the system in such a way as to encourage you to keep the least possible mutable state in your application. In fact, because React is such a functional system, rather than computing a value and then storing it somewhere, we just recompute the value on demand with each new render.

The problem is that people sometimes want to have a big form that includes something like 20,000 fields that then bind to some simple keys and data objects. The good news is that it’s actually very easy for us to build an abstraction on top of a simple event loop that basically captures all the events that might possibly update the value of this field, and then sets up an automatic handler to pass the value down from the data model into the form field. The form and the data model essentially get updated at the same time. This means you end up with a system that looks a lot like data binding, but if you were to peel it back, you would see that it’s actually only simple syntactic sugar on top of an event loop.

TC: One of the things I’ve observed
about React is that it seems to be what
people would call fairly opinionated.
That is, there’s a certain way of doing
things with React. This is in contrast to
Angular, which I’d say is not opinionat-
ed since it generally lets you do things
in several different ways. Do you think
that is an accurate portrayal?

PH: It depends. There are certain places where React is very opinionated and others where it’s quite unopinionated. For example, React is unopinionated in terms of how you express your view logic since it treats your UI as a black box and looks only at the output. But it’s opinionated in the sense that we really encourage idempotent functions, a minimal set of mutable state, and very clear state transitions.

I’ve built a lot of stuff with React, and I have a team that’s run a lot of stuff with it. From all that experience, I can tell you that whenever you run into a bug in a React application, nine times out of 10 you’re going to find it’s because you have too much state in there. We try to push as much mutable state as possible out of applications to get to what I like to call a fully normalized application state. In that respect, yes, we’re very opinionated, but that’s just because a lot of React abstractions don’t work as well if you have too much mutable state.

I think Angular is actually less opinionated in that regard, but it certainly has opinions about how you need to compose your application. It’s very much a model-view-present-er type of architecture. If you want to create reasonable widgets, you’re going to have to use directives, which are very opinionated.

TC: Another thing I noticed right away about React is that it’s very component-oriented. What was the reason for going in that direction?

PH: We actually think of a component as being quite similar to a JavaScript function. In fact, the only

PAUL O’SHANNESSY
We end up writing
good code pretty
much across the
board since there
are fewer people
going off into
crazy land writing
CSS. Basically,
this just gives us a
way at the top level
to control all that.