Yesterday, the team here at WP Ninjas watched the State of the Word address from WordCamp US. Most of us had been keeping up with the event via Twitter, but it was nice to watch Matt give the State of the Word as a team. We couldn’t have written a more affirming State of the Word. His homework assignment to learn Javascript, and his assertion that Javascript UIs are the future of WordPress, validated many of the decisions we’ve made around Ninja Forms Three. In case you haven’t heard, Three is a total re-write of Ninja Forms with a completely JS UI. Eventually this will include using the Rest API extensively both in the form builder and form display. When it comes to creating JS-first applications for WordPress, we’re a bit ahead of the curve. (You can keep up with all the Ninja Forms Three alpha releases here.)

backbone vs react

So, quite a bit more JS is coming to WordPress in the future; I can understand the trepidation of developers who have worked mainly in PHP. When we made the transition to a JS UI, I had to learn a new language. Like most WordPress devs, I had written my fair share of jQuery spaghetti, but that felt quite a bit different than jumping wholly into Javascript. I began to have nagging doubts about my abilities. What if my architecture wasn’t efficient? What if I just flat-out wrote bad JS? After a bit of self loathing, I came to the conclusion: I’ve never written perfect PHP, so why worry about starting now? At the risk of sounding like I’m pushing bad practices, code that functions and ships is 100% better than perfect code that never gets completed.

How, then, should we prepare? What should our JS education focus on? When Matt was asked which framework or JS library that developers should pick up, he mentioned React, which is what Calypso is built upon, along with some others. I’d like to make the case that Backbone is a great fit for WordPress developers.

Before we go any further, let’s be clear: the title of this post is totally misleading. Comparing React and Backbone is really like comparing apples and oranges, if apples were solely responsible for displaying information and oranges contained all the data. React is simply a view layer. Instead of wholly replacing Backbone, it takes the place of the Views portion of the framework. React doesn’t force you to abandon Backbone completely, but it does change the way that you work with it.

The Case for Backbone Views

First, let’s talk a bit about more about React. It’s fast. Like. Stupid fast. A race between Backbone Views and React would be like the tortoise and the hare, except that the Backbone View can’t cheat its way to victory. Part of this speed comes from React’s use of inline markup; it doesn’t have to interpolate or compile any templates. It can also be a bit easier to read and follow because methods contain the markup that they are going to inject into the DOM.
If Backbone Views aren’t as fast or as easy to read as React, why would we consider using them?

Backbone is an open-source, community project

Much like WordPress, Backbone is a community-driven project that can be contributed to and forked. It’s hosted on GitHub and accepts pull requests and issues from users and developers. Before you say, “Hey! Wait! React is on GitHub too! And it’s open-source,” let me say: “You’re absolutely right.” It is both of those things. The difference, I think, is that Facebook can steer the project in whatever direction they need. That’s not necessarily a bad thing but knowing that Backbone is completely community-driven makes me feel that radical changes are less likely.

Backbone has native support for views

You don’t have to create any custom connections. When you use Backbone and React, you have to write the code that connects React to your models so that it can…wait for it…react to changes. Yes, I am a dad. This might not seem like a big deal, but I’ve found it easier to hit the ground running with Backbone Views because they are baked into Backbone.

Backbone is more mature

Backbone has been around longer and has a larger user-base, along with more in-depth tutorials. This will obviously change as more people pick up React, but for the moment, I prefer the breadth of docs and tutorials available for Backbone. I also think that Backbone has the potential to be more stable. Because it’s been around for a longer period of time, there tend to be less radical changes.

Backbone Views can be more extensible

Because Backbone works natively with templates, it can be much easier to extend or change, even from other applications. While there are libraries that add templating to React, like React Templates, They feel a bit messier than thoes available for use with Backbone. Underscore and Handlebars are two good examples. Although I really like Handlebars, we’ve decided to go with Underscore templates for Ninja Forms Three, because it’s included with WordPress. This helps minimize the chances that we’ll have conflicts with other plugins or themes. Using templates on the front-end allows plugins and themes to easily modify how fields are rendered. If you wanted to use Bootstrap, for example, you could write your own field templates.


Just realised that I forgot to mention an add-on library for Backbone that has made a big difference in our rebuild of Ninja Forms: Marionette JS. Amongst a host of helpful features, which we’ll cover in a future post, Marionette extends Backbone Views and gives you Collection, Composite, and Layout Views. These make it trivial to render collections, handle collections that are nested inside of models, and create complex screen layouts. Saying that these new types of views have been helpful would be a gross understatement. I’m not aware of such a library for React.

React isn’t a bad library. Quite the contrary, I think that React is awesome. If we were building a stand-alone, closed-system app, we’d highly consider using React. But we aren’t. We’re building a WordPress plugin, and we want that plugin to be as extensible as possible. For our current project that’s more important than pure loading speed.