Day: November 16, 2014

PIcking Your Javascript Mobile Framework: Part 3 – Minimum Functionality

If you are joining us now, this is a multi-part shootout of mobile Javascript frameworks. In the last instalment, we got a series of candidates, 77 long. In this instalment, we will look at functionality.

The Todo app pushed by the TodoMVC team is very simple, but pretty complete. In it you:

  1. Create new todo items by entering them into a box
  2. Display all available todo items
  3. Alternatively, display only the active ones, or the completed ones
  4. Mark a todo item as completed by checking a box to its left
  5. Delete a todo item
  6. Delete all completed todo items
  7. Edit a todo item

Bindings and behaviors were refined further:

  • Aside from clicking on the box to the left and the delete button to the right, a double click on the item would allow you to edit it
  • Typing text into the edit box at the top would allow you to create a new item; hitting “Enter” would add the item to the list
  • Three links at the bottom would route you to the list of all items, active items, and completed items
  • A button on the bottom would allow you to delete all completed items
  • When in Active mode and an item is cleared, the item should automatically disappear

(more…)

PIcking Your Javascript Mobile Framework: Part 2 – The Field

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

PIcking Your Javascript Mobile Framework: Part 1 – Preliminaries

Part 1 in a series that also includes:
Part 2 – The Field
Part 3 – Functionality
Part 4 – The Code
Part 5 – Performance
Part 6 – Elimination
Part 7 – Activity
Part 8 – Documentation
Part 9 – Ampersand
Part 10 – AngularJS
Part 11 – Backbone
Part 12 – CanJS
Part 13 – Durandal
Part 14 – jQUery
Part 15 – KnockoutJS
Part 16 – Mithril
Part 17 – Ractive
Part 18 – React
Part 19 – Stapes
Part 20 – Thorax
Part 21 – Vue
Part 22 – Conclusions and My Pick
So I recently decided to switch from native mobile development to Javascript in a browser. What changed is that I needed something that works on more than just Android, and I faced the steep curve of dipping into iOS development. That’s a pretty steep one, because it doesn’t just involve getting into a completely new paradigm, but because you have to own dedicated hardware and pay an up-front fee to Apple.

But what do you know, Steve Jobs was right: the future of the web is in the browser. When the first iPhones came out, in 2008, the brilliant man said we didn’t need native toolkits. He said so mostly because he didn’t have one to offer, since back then mobile browsers were super-crappy and the web just wasn’t ready for them, anyway. Today, a startlingly short 6 years later, the mobile browsers are not only on par with their desktop cousins, they start becoming the default targets of development.

Instead of creating apps on the mobile device, you could simply send mobile users to your site. That would require no download, which means no headaches with old versions and no complaints from users that can’t make it work on their phone. On the other hand, you become unavailable when there is no internet connection, you are as slow as that very same connection, and you have no access to device internals – like the GPS or the accelerometer.

(more…)