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.

Battle Royale, July update, now with 100% more babies!

Right, so, let’s just say that thinking I’d be able to get a bunch of coding done while on paternity leave was overly optimistic.

My brand-new daughter, Eliza Rose:

smiling baby

Eliza’s pretty excited about her shark onesie.

She’s adorable, but for the first few weeks of her life she wasn’t exactly conducive to getting much of anything done. Now that she’s a little over a month old she’s sleeping for longer, more regular periods, and we’re all sort of getting used to each other and how we operate, so it’s becoming easier to steal an hour here or there to do non-baby things like random development projects. I anticipate making more rapid progress in August, although I fear that beer production will continue to suffer until she can hold her pacifier.

Which is not to say I haven’t already made a bit of progress. Without further ado…

AngularJS: Foundation for Apps provides a pretty solid canned development environment, including Gulp and a local server setup. That’s very handy, with the caveat that, as with any new tool, it took a bit of time to get the hang of configuring Gulp to work the way I wanted. The nice thing about Angular, especially as packaged with Foundation, is that you can wireframe an app in no time flat–as long as you stay within Angular’s lines, of course. Currently, it looks pretty, although the page transitions are doing a funny thing where the incoming div stays off page but creates space in the DOM that pushes the outgoing page down before it moves. I suspect it has to do with how Foundation is handling the transition animation ( relative positioning, I’d guess ) and is probably a situation where I’ve gotten too cute too fast.

I’ve also run into an issue with actually getting the container values into the select menu without an initial blank value. I remember this same issue cropping up while working on Field Guide, and it has to do with the way Angular uses array comprehensions. A quick search of Stack Overflow shows that it’s a pretty common problem and it’s a function of the less-than-clear way comprehensions are written. They’re uglier than sin, frankly, and I hate them, just in case anyone’s asking.

BackboneJS: With some downtime at work I started the Backbone version, and I must admit that, compared to Angular, it’s a joy to work with. It’s much simpler and totally unopinionated, which is a real blessing on such a small project. Yes, you do have to hand-wire the linkage between the view and the model, something Angular handles automatically. In practice, however, I don’t find the data binding in Backbone to be too onerous. In my admittedly limited experience, the time you save by not having to do it in Angular is lost (and then some) to struggling against ( or refactoring for ) the “Angular Way” and having to do the occasional bit of hand-wiring to fix situations where the native binding isn’t working as it should. At this stage, I have a model and a view, but no calculations or functionality.

At this point it might seem like I’m leaning towards Backbone, and, honestly, that’s not entirely wrong. Backbone is a nice, simple library that makes it easy to model data and tends to stay out of your way. Collections will automatically create models with the appropriate properties if given an API URI as a source, which is really cool. Also, Backbone deliberately leaves the View components fairly thin so that you can swap its native functionality out for something like ReactJS, which shows a lot of promise.

But, lacking the opinionated structure of Angular, Backbone can leave you hanging a bit when it comes to structuring your app. This is by design, of course, and not without merit, but I do find myself missing the simple clarity of Angular’s explicit Model-View-ViewModel structure. Backbone lends itself to something like a Model-View-Presenter structure but leaves the implementation up to the developer. It’s not a deal-breaker, certainly, but I’ll admit that I missed Angular’s system of Controllers, Services, and Directives. There’s an aspect of Angular development that is almost like filling in the blanks. Backbone’s more laissez-faire approach isn’t a drawback per se, but, again, Angular automates app structure in a sense where Backbone puts the burden on the developer, which could be an issue on larger applications or in team settings.

In other news…

I’ve set up Linux Mint in a virtual machine on an external drive I had laying around and, so far, am pretty happy with the setup. With 16 GB of RAM I’m able to toss a healthy chunk to the VM without noticing it, and the external drive is about a terabyte running on USB3, so performance is actually pretty crisp and I don’t need to worry about running out of space. I’ll be using it as a development environment in the future, particularly for Meteor, which includes a Linux- and Mac-only utility to automatically convert code to an Android or iOS application, which is yet another reason why MeteorJS is so friggin’ cool.

AngularJS vs Ember.js vs Backbone.js: JavaScript Framework Battle Royale!

There’s gonna be a JavaScript framework showdown!

I’m a huge fan of JavaScript, and I love frameworks. Trouble is, there are a ton out there with new ones every day. How to decide which one to use? An app-off, that’s how!

I’m pitching the three most popular frameworks/libraries against each other in a single, simple webapp fight to the finish.

The Contenders


Angular is a Google product designed to add dynamism to HTML by extending its vocabulary. Unlike other frameworks (and conventional MVC design) which pull behavior out of the HTML, Angular uses custom DOM elements and data-bindings to express behavior and link display elements to the model. It boasts automatic two-way data-binding, a modular style, and detailed form validation.

Angular is known for being highly “opinionated”, for better or for worse, and experienced Angular devs talk about the “Angular way”, which broadly refers to using Angular’s native components and code style exclusively. Angular actively pushes a Behavior-Driven Development model, and includes a number of unit and end-to-end testing tools to that end.

Interestingly, Java developers seem to love Angular because it looks and feels like Java. Make of that what you will.


Backbone was created by Jeremy Ashkenas, creator of CoffeeScript, as a lightweight alternative to heavier frameworks like Angular. It’s popular, though not as widespread as Angular, and proponents favor its hands-off, laissez-faire approach to application development. Compared to Angular, Backbone doesn’t care how you structure your app or how you do development. Having only one dependency, it has a very small data footprint in its default state.

The main argument against Backbone is that, while it is indeed very small by default, most projects will require additional libraries, with the resulting app having more requirements overall. Backbone’s bareness allows for easy customization, but also means you’ll be writing a lot of boilerplate code for basic UI stuff that the other two frameworks handle in the background.

Backbone is typically considered the closest to plain ol’ JavaScript. They say you have to learn Angular and Ember, but Backbone is just a library, so it’ll play nicely with whatever JS programming style you prefer.


Full disclosure: this is the only one of the two frameworks I’ve never used. I’ve built a working site using Angular and have done a few prototypes using Backbone, but I have no first-hand knowledge of Ember whatsoever.

Based on what I’ve read, Ember is an even more opinionated framework than Angular. Its motto is “Convention over configuration,” which means it forces you to do things one way–convention–rather than allowing you to tell your app how you’ve decided to do things. The downside to this is that it constrains developers in ways that prevent or hinder customization and it forces them to conform to practices they might not like. The upshot is that it enforces standardization, which usually results in better stability, easier bugfixes, and a generally more pleasant workflow when working with larger teams.

Ember is famous for having the best router in the business, and handles nearly all of the MVC wiring automagically. It’s infamous for relying on Mustache for templating and for being the largest of the three in terms of download size.

One of Ember’s authors was an Apple dev, and the other worked closely on Rails and jQuery. Supposedly, it shows in the enforcement of the “convention” philosophy and a stylistic resemblance to Rails. Quite frankly, not being a big fan of Apple’s “why would you want to do things any way but ours?” philosophy makes me think I’ll not enjoy working with Ember, but I’m hoping I’m wrong, as there are a good many developers who love it.

The Setup

I’ll be making a simple webapp: Bottleday. Bottleday is a single-page app that, given a volume and a bottle size, calculates the number of bottles needed for, well, bottling. It will consist of a start page with a button which, when clicked, will transition to a second page with form inputs and a conditionally-displayed result. For shits and grins the result might be displayed in a modal. As these are all client-side frameworks, I won’t be doing anything with user accounts or data persistence.

I will be using front-end frameworks. My preference is for Foundation 5, but I’ll use whatever happens to work best with the JS framework in question. For instance, I’ll use Foundation for Apps with Angular as it is actually built on Angular and includes several helpful modules–ui-router and ngAnimate–along with Foundation-specific directives. Ember, on the other hand, allegedly works best with Bootstrap.

The Criteria

I’ll evaluate the three contenders on several factors. First and foremost will be the quality of the end product compared to the time and effort to produce it. However, I’ll also be looking at things like the learning curve, the amount of setup required to start developing, and the elegance of the code. Was development frustrating? How helpful was the documentation? Did I have to work against the framework to accomplish specific goals? Perhaps most importantly, would I use it again?

I’ll post regularly (I swear, this time I really mean it!) with updates on progress and host the resulting apps on this site.

Let the battle begin!

Automated deployment with git is awesome like a hotdog AND like the universe…

Incorporating version control into your deployment process (assuming you have one…), like regular exercise, balancing your checking account, and eating more green vegetables, is something you know you really ought to do but never quite get around to doing. In part because we’re going through a minor overhaul of our processes at work and in part because I’m interested in working with git and automation, I’ve started banging around with GitHub, webhooks, and various third-party deployment services.

I’ll say that I’ve learned more about Linux file permissions than I’ve ever wanted to know, and I’m growing disturbingly comfortable with vi. That’s not a bad thing, per se, but I’d like whatever process I finally land on to be as simple as possible, and, most importantly, to be portable. I’ve been doing some interesting things with server-side scripts, and while I’m fairly pleased with the outcome so far I’m not very confident that what I’ve come up with would translate to, for instance, a brand spankin’ new server without a fair bit of configuration. It’s definitely nowhere near a plug-and-play setup.

I’ve seen some success with third-party alternatives. FTPloy in particular has been relatively simple to set up and works pretty well. The big downside, such as it is, is that you’re basically just asking another website to grab the files from GitHub and FTP them to your site. The initial deployment is, as you’d imagine, fairly lengthy, but subsequent updates are fast. You gain the benefits of version control and it’s very portable, but you lose the speed of a git pull/checkout.

Spending so much time screwing around with logistics instead of working on the site itself is frustrating, but I’m banking on this paying off in the long run.

New Sites!

Finally deployed the site I’ve been working on since May: Not gonna lie, it wasn’t a completely smooth process, but it’s done and I’m pretty proud of it. Zach Friedman is responsible for the design, I’m responsible for the code, and Guy Stephens led the project and kept us out of meetings.

We’re using ExpressionEngine for the CMS, and I’ve got to say I prefer it to WordPress for everything but blogging. Lots of support on the back end for setting up a good, robust data architecture, fairly user-friendly, and uses a very flexible templating engine that fits right into standard HTML. It actually looks a little like EJS or Handlebars. Much nicer to work with than some other CMS’s (cough cough WP cough cough) when you want to have full control over the front end.

Ironically, I also just rebooted this site as a WordPress site. This was largely a result of my wiping out my existing site while working with some automated GitHub deployment strategies. At this point I’m content to just have the site up and presentable while I rebuild the content, but eventually I’d like to use this as an opportunity to do some work with WordPress theme creation.

In the course of the reboot I upgraded from a hosted site to a VPS, and have been fiddling with things like private nameservers and local mail, which has been instructive. Also, nice to have an email address at my own domain for stuff like using Outlook (don’t judge), PGP, and just general nerd cred.