Backbone vs React: Selecting the Best WordPress JS Framework

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.

*Edit*

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.

Calypso and the Future of WordPress

Calypso!

Since the release of Calypso, I’ve been thinking about writing a blog post dealing with the future of WordPress and the Rest API.Is Calypso the herald of a coming WordPress apocalypse, or the long awaited saviour that will bring WordPress into the shining age of apps? I know that everyone seems to be writing about it, but hopefully I’ll have something helpful to add to the conversation. 🙂

The headless WordPress horseman

Headless Hecarim
The introduction of Calypso shows how powerful the Rest API really is; WordPress.com is no longer using WordPress’ admin interface. Let that sink in. WordPress.com, which is used as an example of how awesome WordPress is, no longer uses the WordPress admin. How long will it be before big players in the WordPress space create their own bespoke admin interfaces? GoDaddy’s managed WordPress hosting, for example, might create a custom admin UI that positioned them better to compete against the Squarespaces and Weeblys. It is indeed a brave new world.

Of course, if everyone and their brother has a custom admin, would that dilute the WordPress brand? At that point does WordPress become a “server thing” that end-users don’t care about? I’ve heard of users asking developers if they could use WordPress for their project. How many clients come to you and ask if you could use MySQL to store data? If every admin looks different, would anyone care about it being powered by WordPress? Heck, if we’re simply using WordPress as a headless CMS, why wouldn’t we consider using something a little leaner? There are lots of options for creating a database interaction layer, and installing all of WordPress to get that seems like it could be overkill.

To Javascript infinity and beyondToyStory-To-Infinity-and-Beyond!

Scott Bolinger wrote a great post about where WordPress might be headed; he envisions a future version of WordPress being 100% JS, making the point that plugins would be the largest hurdle in moving WordPress over to something like Node. While I don’t disagree that plugins would be extremely difficult to deal with, I think that a larger problem would be the development community around WordPress. Does the core contributor team have enough expertise to create a completely move WordPress to JS? I don’t mean to question anyone’s ability, and I readily admit that I don’t have any numbers to back this up, but I’d assume that most of the core team is made up of PHP developers.

I think that extends beyond core contributors to plugin and theme authors as well. It seems like a wholesale move would be the equivalent of saying, “we’re jumping the PHP ship; either learn JS or find another project.” A WordPress built on Node has a significantly different developer community than the community that currently exists around WordPress. That’s not to say that there aren’t contributors that have a deep understanding of Node, JS, etc., but the shift would mean that the community would have to shift as well. PHP developers who had contributed in the past might find that they aren’t able. I’m not saying that this is a reason not to explore a JS code-base, but it would have the knock-on effect of changing the community.

As I said above, because custom admin interfaces will be easier to create, I think we’ll see more of them. I don’t think, though, that WordPress will ever escape the gravity of PHP. It’s too entrenched. To mix my metaphors, the tendrils of PHP reach deep into the core of WordPress, and I don’t believe that it would be worth the effort to hack them all away. Any plugin or theme that modifies or does anything within the admin would need to change. The Rest API will allow you to use WordPress as a headless CMS, but moving all of WordPress over to Node (or something similar) would be a monumental undertaking. And, I’d argue, the benefits would be outweighed by the sheer amount of energy necessary.

Just as a thought exercise, let’s assume that we, the WordPress community, were able to achieve this Herculean task. WordPress is now completely powered by NodeJS on the server-side and has a fully JS UI/front-end. Would we still be using WordPress? This is a bit philosophical, but if we’ve stripped away all the code that has accumulated over the past decade or so, is it still the same project? If GoDaddy is using a custom UI to communicate with a Node version of a headless CMS, what part of that is WordPress?

TL:DR

At the end of the day, I don’t think that Calypso or the Rest API spells either the end of WordPress or the emergence of a WordPress golden age of app development. As with most things, the truth probably lies somewhere in-between. The Rest API will surely propel WordPress further into the world of apps and remotely accessible data, and Calypso is a great example of how both can be done successfully. I’d be very surprised if the WordPress.org default admin ever moved over to a completely JS-driven UI. Areas are certainly becoming more JS-intensive, but I don’t think that the entire admin will become a JS app. We’ll also probably see more headless CMS implementations and custom admin interfaces, and while there are a ton of slippery-slope arguments out there, I don’t think that WordPress will ever shift over to server-sided JS.

The AMD pattern – Part 1

If you were to go back to some of my earliest attempts at writing code, you’d likely find a handful of files with several thousand lines of code. Why break anything apart into separate files? What if I need to edit something? It’s so simple! Everything is right here in the same file! What could be easier than that? If you’re a developer, you can probably relate. Even today, much of my code is probably too verbose and too all-encompassing. I’m always learning the best ways to break down and extrapolate into the lowest possible denominator. For me, I feel like this is an eternal struggle.

jQuery Spaghetti

jQuery spaghetti at it’s finest! (Or worst!)

Recently, I’ve begun to do a lot of work in the Javascript space, and the temptation to create a bunch of jQuery spaghetti is very real. In fact, the last time I wrote the JS for Ninja Forms I created a really large pasta bowl JS file.

It was several years ago, and hopefully I’ve learned since then, but the desire to “make it work” is always present, especially in large projects. One of the newest code design patterns I’ve picked up has helped to keep my current work tidy and dry: the Asynchronous Module Definition, or AMD, pattern. It can be a great way to organize your code and keep it as readable as possible. It makes extensive use of the message bus we’ve talked about previously and, like the message bus, works much better with stateful programming languages. With JS it’s great; with PHP, not so much. That’s not to say that you couldn’t design a PHP application this way, but all of my experience has been with AMD JS.

In this pattern, we break apart all of the functionality of our application into small modules that can be modified without interfering with each other.

It looks something like this:

Japan Capsule Hotel

The AMD pattern

Ok. So, this is a Japanese capsule hotel, but it works as a good visualization of AMD. Each part of your code exists in small, focused, self-contained blocks. Each of the blocks has just one job. If it needs information, it just sends out a message asking for that information, and another block that is listening for that request responds. None of the blocks need to be aware of each other.

Once you’ve created the module, or block, to handle a specific job, you should be able to forget about it. Like a Roomba, it just works, even when you aren’t at home, keeping your living room cat-hair free. A well-designed module doesn’t require any modifications when you add or remove new modules, so unless you’re changing something major, there shouldn’t be any ripple effects.

By definition, this separation of concerns keeps any one file from growing too large. It doesn’t, however, automatically mean that our code is well-organized or easy to follow. When you’re trying to decide how much code to put into one module, ask yourself these questions:

  • Will this functionality be used in more than one part of my application?
  • Can I break this module down any further?
  • Can I easily draw a map or explain how my modules interact with each other? (Spaghetti modules aren’t much better than spaghetti jQuery.)
  • Is this module self-contained? (Apart from asking for data or something special from the message bus.)

So, that’s the theory behind the Asynchronous Module Definition. Next post, we’ll take a look at some code examples using RequireJS, a Javascript dependency manager.

Using RequireJS and Backbone Radio With WordPress Enqueued JS

When I began work on the newest incarnation of Ninja Forms, I decided that I was going to use RequireJS and the AMD design pattern for the front-end. (The anonymous module definition pattern is deserving of its own post, so we’ll come back to that another day.) One of the cruxes of my design was Backbone Radio, a plugin for Backbone that lets you create a message bus in your app. I grabbed a copy of the Radio plugin and began hacking away. I ran into a problem pretty quickly, however, when Backbone Radio began trying to load Backbone and Underscore as modules through RequireJS.

The Problem With RequireJS

requirejsbackbonejs

If you’re working with a JS library and it’s included with WordPress by default, you should use the copy bundled with WordPress. This helps to make sure that any plugins using these resources are on the same version and avoiding as many conflicts as possible. Most developers have probably experienced the mess that can result from enqueuing multiple versions of jQuery or another popular JS library. As I said, using the versions of Backbone and Underscore included with WordPress presented a problem with Backbone Radio, which was attempting to load Backbone and Underscore as modules. It was looking for files named “backbone.js” and “underscore.js” within my application. Of course, I didn’t have these files, because I was simply enqueuing the libraries within WordPress.

The Solution

After banging my head against the wall for much longer than I care to divulge, I came up with a very simple solution. I created two module definition files, named backbone.js and underscore.js, and saved them in my project. Rather than including a new version of Backbone and Underscore, I returned the definitions that were already added to the page by WordPress. You can see examples of these files below. Hopefully this experience will be helpful to those trying to get RequireJS and Backbone Radio working within WordPress.

Get on the message bus!

Ever play the telephone game when you were a kid? You’d give a message to someone standing next to you, and see what the words morphed into as it made its way back to you. Sometimes you’d say curse words just to see what your friends would say next. Message buses are a lot like that. Except they’re much better at remembering what you said than a room full of primary schoolers.

Message Bus Example

A very serious example of the message bus pattern.

A message bus is a way for discrete parts of a program to communicate with each other without knowing that any other components exist. Think of it like playing the telephone game with ghosts that respond sometimes. If one part needs a piece of data, for example, it sends out a request on the message bus. Other parts of the program listen for these messages and supply the requested data. Because all of the communication is handled via a third-party, each part of our program is free of references to another.

VW Bus

Good for carrying messages to the Grateful Dead.

What are the benefits of a message bus? The short answer is modular code. Since none of our methods/functions/classes contain direct calls to other parts of our code, we can easily swap out processors, responders, and requesters. If the specifications for our program change, we just modify the code affected by the change.

It should be noted that a message bus is different than a helper function. In PHP, for example, you might create helper methods or classes that pass and receive data, but in the end, the thing that calls the helper method is specifically aware of what it’s communicating with. If my code calls a get_all_fields() helper method, it has to know the name of the method. Changing the helper method name to something like get_all_fields_now() means that we have to change every reference to that helper method in our code. Using a message bus alleviates this, because the piece of code requesting the information from the helper doesn’t interact with it directly. It just sends out a message saying, “I need this piece of data.” In the very serious example above, the user view doesn’t call a database function for retrieving information, it sends a message out into the message bus. The database controller is listening for the request and responds anonymously.

Jerome “The Bus” Bettis

Jerome “The Bus” Bettis. Good for carrying American football (hand-egg) messages.

This concept may seem a bit foreign if you’ve only done web or server-side development. Message buses aren’t very feasible in state-less environments; if a listener doesn’t exist when its value is requested, it can’t respond. If you do any work in Javascript, though, this pattern can be very, very useful. In that vein, next we’ll dig into specifics by using the Backbone Radio plugin to create a message bus pattern in Javascript.