Day: November 17, 2014

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.

It’s a mess. The HTML is kept generic, with the main app area simply marked as header section, main section, and footer section.

The main.js file, then, starts with a list of requires that scared the heck out of me the first time I saw it: it includes underscore, backbone (duh!), marionette, jquery, and from backbone the localStorage package.

And you know what, we could all laugh it off, if it weren’t for the fact that this crazy combination loads lightning fast. As mentioned, nobody knows (well, I don’t) how the combo would work in actual deployment, but at least on this computer, at least this app, at least on startup is faster than anything else we have in the comparison.


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.

My favorite section of the app, the display of the single todo item, looks like this in the Angular example:

<div class="view">
    <input class="toggle" type="checkbox" ng-model="todo.completed">
    <label ng-dblclick="editTodo(todo)">{{todo.title}}</label>
    <button class="destroy" ng-click="removeTodo(todo)"></button>


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:

We <3 Backbone.js at &yet. It’s brilliantly simple and solves many common problems in developing clientside applications.

But we missed the focused simplicity of tiny modules in node-land.

We wanted something similar in style and philosophy, but that fully embraced tiny modules, npm, and browserify.

Ampersand.js is a well-defined approach to combining (get it?) a series of intentionally tiny modules.

I confess I didn’t know what to make of that description. It seemed vague and pointless, especially for mobile developers. The remainder of the documentation is similarly vague or hints at things you would know as a Backbone developer. In essence, Ampersand wants to be Backbone++.


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.

On the other hand, you never know what the next big technology is going to be. Sometimes a concerted effort by major companies that seems to carry momentum ends up nowhere; other times, a one-man project explodes out in the wild; and sometimes the predictable occurs, and the major project becomes a major success and the one-man project withers and dies.

But we have to make an educated guess. And we have a few ingredients for that guess:


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.

Second, we will remove all those that were characteristically slow to load. That was only three of them: React with Backbone, Enyo with Backbone, and EmberJS. They are marked with “zz.” I’ll let you guess why.

Third, we remove all those that have excessive coding length. That would be Enyo again, Flight, Lavaca, VanillaJS (which was never a real contender, anyway), and Closure. They are marked “vb” for verbose. Notice that adding RequireJS really doesn’t change code length by much.


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.

On the phone, tucked away in a neat little folder, you suddenly don’t care if the library is 50KB or 500KB. All you care about is how quickly the thing loads, and how long it takes to go from screen to screen.

That kills pretty much any comparison ever made online. They care about every single bit squeezed out the download, and will prefer a small library that does less if it means being able to download it less frequently.

On the other hand, the coder (you and me) has different priorities. We want something that is easy to write, concise, and does a lot of the grunt work for us. After all, if we write twice as much code, it’s not just that it takes twice the amount of time: it gives us twice the chances to make a dumb mistake.

So the first thing I wanted to look at is the total actual code size. That’s the code the developers of the Todo apps had to write, versus the total amount of code of the app. As we’ll see, that’s a much more important criterion than download size.