Marco's Blog

All content personal opinions or work.
en eo

PIcking Your Javascript Mobile Framework: Part 2 - The Field

2014-11-16 4 min read Comparisons marco

Right on the heels of the first instalment, here the second, where we will consider the options we have in mobile frameworks.

First of all,** the number of frameworks out there is simply staggering**. There are literally hundreds of them, from industry behemoths like jQueryMobile to one-man projects already abandoned by the creator.

Variety is the spice of life, but too many options make for big headache. Unfortunately, the web has zeroed in on the predicament of mobile developers and offers even more click-bait articles about the “Best Mobile Frameworks 2014” than you can possibly read. Most of them, sadly, consider it a “comparison” when you simply put up the name and the first paragraph of the web site description.

What to do? I decided I needed some general criteria before moving forward. Here they come:

  • Availability as open source with no licensing restrictions: I am not going to pay a fixed per-download fee, a per-app fee, or even a per-developer fee when there are hundreds of free options available
  • Cross-platform and mobile design: Many of the frameworks out there are rooted in one particular development paradigm, operating system, or use case. I wanted something that would handle anything from a tiny phone to a large tablet – and the desktop, too.
  • Easy to learn: That doesn’t just mean that the technology is easy to grasp, but also that there is good documentation, both for the novice (tutorials) and the seasoned user (reference)
  • Fast: Fast, Fast, Fast. Loading, running, responding. That turns out to be a killer feature – as in a feature that kills many otherwise solid contenders. They are great frameworks, it just takes forever to load even a Hello World
  • Adaptable: iPhone or Android? Tablet or phone? The framework should handle them all gracefully, and should give me the option of picking what to do when in doubt.

So, with that list in mind, I started going about evaluating. After about 20 alphabetic picks, I started doubting myself. This was going to take forever.

I did what anyone in my situation would do: I fired up Steam. ☺

Then I got back and thought: there’s got to be a better way to do this. Which is when I found the TodoMVC Project. There you find a list of implementations of a very simple app that shows you how different frameworks handle the task.

The name hints at two things: first of all, the app all the frameworks had to implement was a ToDo task manager. It was supposed to be a CRUD application, where CRUD stands for Create-Read-Update-Delete. The single todos were just text, and you could set them active or completed, so they had one single attribute.

MVC in the name of the project stands for another abbreviation: Model-View-Controller. That’s the (current) gold standard for application implementation. You have a model, which is the abstract entities (a todo would have a text and a flag completed). You have the view, which is the buttons and fields and labels and menus on the page. And you have the controllers, who mediate between the two. So when you click on a button in the view, the corresponding controller would, for instance, delete a todo in the model.

There are tons of frameworks that don’t follow that paradigm, but luckily the TodoMVC Project is not too picky about MVC-ness. In fact, there are implementations in non-MVC and even non-framework environments. Turns out they are not half bad, either.

I liked this project, because it did many things at once:

  • It listed those frameworks that someone cared enough about to do actual work in, instead of simply dumping it into the field thinking it a good idea
  • It showed how different frameworks would handle the exactly same task
  • It gave a vague idea of the performance of each framework
  • It showed structure and limitations

It was free to download and easy to install. In fact, you just run:

git clone https://github.com/tastejs/todomvc/tree/master/examples

and you are done.

The master tree shrinks down the number of contenders from a few hundred to a much more manageable 77. That’s of course still way too many to fully evaluate, but here is the rundown:

agilityjs
ampersand
angular-dart
angularjs
angularjs-perf
angularjs_require
ariatemplates
atmajs
backbone
backbone_marionette
backbone_marionette_require
backbone_require
batman
canjs
canjs_require
chaplin-brunch
closure
componentjs
cujo
derby
dijon
dojo
duel
durandal
emberjs
emberjs_require
enyo_backbone
epitome
exoskeleton
extjs_deftjs
firebase-angular
flight
gwt
jquery
kendo
knockback
knockoutjs
knockoutjs_require
lavaca_require
maria
meteor
mithril
montage
mozart
olives
plastronjs
polymer
puremvc
ractive
rappidjs
react
react-backbone
sammyjs
sapui5
serenadejs
socketstream
somajs
somajs_require
spine
stapes
stapes_require
thorax
thorax_lumbar
troopjs_require
typescript-angular
typescript-backbone
vanilladart
vanillajs
vue
yui