Battle Royale, September Update!

Ok. So, new plan. Eliza happened, and work happened, and as it turns out the app I had planned doesn’t really cut it for the comparison. However, I’ve got something even better: real-world comparisons.

See, I made Chesapeake Bay Field Guide using AngularJS, and I’m working on the upcoming site using Backbone and ReactJS. The latter is taking up quite a bit of my time. However, I’m learning some interesting things about working with Backbone vs working with Angular that tell me what I need to know about Backbone and Angular. I’m using ReactJS (Facebook’s javascript library centered around UI) for a dynamic navigation menu, and I’m using Backbone along with the incredible ChartJS to create dynamic charts from an ExpressionEngine endpoint that serves JSON. So far, I’ve been able to draw some conclusions.

tl;dr: Backbone is awesome.

The nice thing about working with Backbone is that it does so much data organization automatically. Without forcing you to into a particular design paradigm, Backbone makes it very easy to set up a data model and wire up views in a pub-sub structure. It lacks Angular’s boilerplate, but I’m finding that I don’t really miss that too much. I suspect that if I were working on a true RESTful app I would be even more impressed. It makes coding to the data architecture you’ve got so, so easy, and in an environment where I have limited control over what users on the back end are doing, that’s invaluable. I love that Backbone offers me tools to use without getting in my way.

Now, where Angular has Backbone beat cold is in UI development. Angular’s native UI stuff is fantastic, and in a more comprehensive app I might be inclined to lean towards Angular. But for building an app (or a widget maybe?) to fit into an existing site, Backbone is working out perfectly. I wouldn’t go so far as to say that Angular would be unsuitable, but I would definitely start any similar projects using Backbone in the future.

Having said that, I came across, a service that essentially creates a back end for your web app (intended for Angular, but probably useable for anything) using a simple web-based UI coupled with stellar support, and I’m going to be building an Angular app to track my homebrewing using that service. While I love Backbone, Angular offers so much native functionality and good, solid software design guide rails that I really believe it’s the best option for a new single-page app.

Ember’s gonna have to wait.

So, I think that means that the Battle Royale is over, with no clear winner. And it’s the ref’s fault.

Two postscripts.

First, I will never not use RequireJS in a project ever, ever again. It’s just so damn useful. Once you get the hang of it–and there is a little bit of a curve if you haven’t used it–you’ll never want to not use it. It makes modular development so easy.

Second, ReactJS. I was dead set against it when I first started reading about it, because I just didn’t see a need for it. To some extent, I still don’t. What I will say about React is that it makes organizing your view code much easier. It’s somewhere between Angular and Backbone as to constraining your design, but I’ve found that it’s forced me to write much cleaner code. I’m not 100% sold, but I’d probably use it again, especially in conjunction with Backbone.

Leave a Reply

Your email address will not be published. Required fields are marked *

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    Markdown is turned off in code blocks:
     [This is not a link](

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see