PIcking Your Javascript Mobile Framework: Part 13 - Durandal

Durandal is very opinionated. It has a clear idea on how to structure your application, what best practices there are, and how you should go about your business. Instead of promising flexibility, speed, and safety, it tries to entice you with “Comfortable, Feature-rich, and Versatile!“

it’s comfortable because it follows the conventions of other frameworks (and makes them requirements) like jQuery or Knockout. It’s feature rich because it follows different conventions, so that you can go whichever way you like. And it’s versatile because you can write apps for phones, for desktop, for anything.

PIcking Your Javascript Mobile Framework: Part 12 - CanJS

Maybe it’s because I was so overwhelmed by the dozen files that made the previous combination tick, but I was ready to kiss CanJS when I saw the directory tree contained a grand total of four files. Yes, I know, four large files are not better than a dozen small ones, but it seemed that an application as simple as this Todo list shouldn’t need such granularity.

The CanJS homepage is a hoot. You can go to the download button, and instead of just sending a giant file your way, it asks you what kind of templates you’d like and what modules you’d like to include. Then it gives you the option to minify the download. So you get exactly what you’d use in production.

PIcking Your Javascript Mobile Framework: Part 11 - Backbone

The odd thing about our Backbone/Marionette/Require implementation is the sheer number of Javascript files that litter its directory structure. There are 6 view files alone – one for the ActiveCount, one for the CompletedCount, one for the Header and one for the Footer, and one each for the the TodoItem and one for the list. There are four templates, a router, a controller, a file for the collections, and one for the mode, plus an app and a main Javascript files, and one that defines the templates used.

PIcking Your Javascript Mobile Framework: Part 10 - AngularJS

AngularJS is a Google product. As with many things coming out of that company, it can be a little prejudiced and quirky. It also has to live with the fact the company has about a dozen Javascript frameworks running around, so it’s never clear which one is going to get most love.

What is special about Angular is that it tries to live within the confines of the HTML, giantly souped up. In particular, elements in the DOM are tagged with Angular attributes (all starting with the prefix “ng”). The Angular runtime then goes in and magically does things with those attributes.

PIcking Your Javascript Mobile Framework: Part 9 - Ampersand

Our alphabetically first contender has been around less than a year. Less than a half year, in fact, but it has already garnered quite a lot of attention.

There is a company behind it, &yet (read: and yet). They make development tools, so they say, so one would think Ampersand is their core offering. Unsurprisingly, they put a lot of weight and passion behind it.

The introduction to the framework says:

PIcking Your Javascript Mobile Framework: Part 8 - Documentation

What good is it to you if everybody loves a super-zippy framework if you can’t learn how to use it?

We know a few things about the remaining contenders:

• They are not slow (efficient)
• They don’t require a novel to bring a button to the screen (concise)
• They have people interested in them (active)

The next step would be to go into each Todo example and learn how each framework handles the task. But before i go into that, let’s do one last elimination round. Let’s look at the amount and quality of documentation and tutorial resources for each framework.

PIcking Your Javascript Mobile Framework: Part 7 - Activity

One of the big problems with technology is the rapid pace of change. It’s good for users, of course, but it can be a real challenge for developers. That’s not because it’s hard to learn new technology, but because you may end up creating something in a framework that becomes a dead-end. Then, as the Internet moves on, you have to switch your app to a different framework if you want to make use of new technology.

PIcking Your Javascript Mobile Framework: Part 6 - Elimination Round

Since the next few steps are going to be pretty expensive time-wise (on my part), it’s time to remove some of the options from the table. That should speed up the process, and I don’t think I left any real candidates out.

First, we are going to eliminate those contenders that have a much faster cousin. That means all the combinations with RequireJS will be kept, while their Require-less brethren are kicked out. These are marked as “rq” in the elimination table.

PIcking Your Javascript Mobile Framework: Part 5 - Performance

Well, here it is: the article about performance. I won’t leave you guessing: here is the chart with the results, and all the surprises it entails:

Cautionary tale: given the number of frameworks and the boredom of hitting refresh, I only did ten refreshes per framework. Given the spread of the results (not shown here) that could catapult any framework a few rankings up or down, depending on where it goes. So look at these numbers with enough salt to cause you heart trouble!

PIcking Your Javascript Mobile Framework: Part 4 - Coding

One of the differences between mobile development for sites and for browserified apps is that you don’t have to download the supporting files every time you start. That’s because they are typically packaged with the app and are right there with it on the device.

That’s a huge difference with respect to looking up mobile sites, because there every byte you can squeeze out is a byte you don’t have to download. While that’s not that important on WiFi or on 4G, it makes all the difference on 3G or heavens forbid 2G.