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

AngularJS

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.js

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.

Ember.js

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!