Category: Comparisons

This was a long journey, for sure. We went through 77 Javascript frameworks (including combinations) to find the ones most suitable for the development of a mobile single page application, to be used as the foundation of a cordova app.

We went on a tangent to see how there was a seminal year, 2012, where a great many frameworks suddenly sprung up. Before that, the selection was small. After that, things got quiet again.

We saw different approaches to the integration of HTML and Javascript. They ranged from a completely programmatic approach, where there virtually is no HTML coding (Mithril) to one where the Javascript injects itself into a stand-alone HTML page, and everything in-between.

We have seen frameworks that require tons of external dependencies (React) and others that are proud to do what they do completely stand-alone (again, Mithril). Some require you to write tons of code (Thorax), while others are perfectly happy to do all the work for you (Vue).

We have also seen how mobile app development differs from mobile web development, and how that in turn differs from web development more in general. Mobile app development stores most of the information on the phone, while it needs to be downloaded on every new tab in the mobile web. Thus, mobile web apps can load a lot more dependencies on startup than mobile web sites. Desktop applications, on the other hand, have to worry a lot more about supporting all kinds of different browsers, which the mobile web doesn’t (since there are no old web browsers on smartphones, since smartphones are new).

(more…)

Vue occupied a special place in my heart when I saw it required the least code to write. That’s a feat of its own, especially considering how lazy I am (despite being a terrific typist) and how error-prone (strike the part on being a terrific typist).

The vuejs.org web site has no clear tag line. This is what I liked best about their self-description: It is not a full-blown framework – it is designed to be a view layer that is simple and flexible.

The main trick is MVVM, or model-view/view-model bindings. What that means is that the model (coming from storage) determines the view, but when you change the view by interacting with it, that automatically changes the model. That is slightly different from MVC, because there is no explicit controller. Instead, it is always assumed that the model and the view are faithful reproductions of each other. Derived quantities are generated by listening to model and view changes.

(more…)

The tag line of the ThoraxJS.org (yes, .org) site reads, “An opinionated, battle-tested Backbone + Handlebars framework to build large scale web applications.“

I mentioned that our mobile needs don’t particularly require large scale web applications, but at the same time it’s hard to deny a candidate that has done well enough in the Todo challenge.

The fundamentals of Thorax, as the tag line states, are Backbone and Handlebars. Additionally, Thorax on its down did pretty terribly in the performance challenge, so we have to add one more dependency, Lumbar. Since Lumbar is “with” Thorax (as they both come from WalMart Labs) it’s not a stretch to think that most projects will use both.

Reading on the home page of the site, it is quite obvious that Thorax is meant for traditional web site browsing a la Amazon or WalMart.com. Indeed, there is an extra section on server-side rendering, where part of the content in the template is injected by the site. We have no use for that in our mobile app, of course, but that shouldn’t disqualify the project.

(more…)

The alphabet has a way to balance the universe. While React was on the pointlessly complicated (not complex) side of the equation, Stapes is really minimalistic. Indeed, you wouldn’t know the index file belongs to a reactive app, or an app at all.

Our example has four Javascript files: a model, a controller, a view, and a store. That’s it. They each do what you’d expect them to do. There is an additional app.js, but all it does is start the controller and make it run.

The controller, in turn, initializes the other components and binds the events.

The view is where the DOM tree gets touched, and that all happens with Zepto  selectors. The role Stapes plays is minimal: it provides class facilities and a general approach to MVC.

Performance and code length were acceptable, and it appears that integration with other frameworks would not be a problem.

On the downside, the project is from the Cambrian explosion but hasn’t really reached the popularity you would expect. It gets about as many Google hits as Ractive, but is twice as old. Also, it has a paltry 2 tags on StackOverflow.

There really isn’t a whole lot making React stand out in a positive way in this comparison. Both performance and code length are towards the maximum acceptable, and the framework comes with its own language you have to learn, JSX.

I’ll spare you the internals of JSX. Let’s just say it’s Javascript made to use XML syntax. I guess you can get the hang of it, and maybe Mithril’s Hoarie should have a glance, but all in all you really have to be hardcore if you accept learning a new language (however little it is different from Javascript) just to code in a new framework.

Especially because that doesn’t really buy you anything. You get a hybrid between two languages with incompatible syntax – like writing Java code mixed with Python – just “because it is a concise and familiar syntax for defining tree structures with attributes.“

To be fair, JSX is just optional, not mandatory. So what other benefits does React offer, if we want to count JSX as a benefit? According the home page, the key benefits are that it’s Declarative and Simple. Like, I don’t know, all the other frameworks in this comparison.

Frankly, the main reason to use React is because someone tells you to. It’s a Facebook project, which means it gets lots of love and ongoing development. It’s also very popular on StackOverflow, despite being only a little older than a year.

(more…)

Ractive was developed by The Guardian, the UK newspaper. That makes it probably the only framework in this group not created by a technologist (if we don’t want to count out WalMart Labs).

If Mithril is the framework I wanted to love the most, Ractive is the one I wanted to love the least. The performance was not exciting, while the code length was at the far end of what we’d consider acceptable. I didn’t realize it was made by a news organization, but it seemed far removed from the needs of an app developer.

Instead, Ractive captured my attention. It is by far the sanest of all these frameworks, with conventions that are intuitive and plausible. For instance, instead of decoupling templates and data, Ractive brings them together in a visible way: you pick a template, generate the model, and choose the DOM element into which you’ll pour your wisdom. Then you create a Ractive object that contains all that, and tell it to go shakin’ and jivin’ and come back with HTML.

(more…)

Ah, I so want to love Mithril! The guy that created it, Leo Horie, is one geek I can understand. The way he presents Mithril on the home page of the project speaks to my heart.

Mithril is around 5kb gzipped thanks to its small, focused, API. It provides a templating engine with a virtual DOM diff implementation for performant rendering, utilities for high-level modelling via functional composition, as well as support for routing and componentization.

The goal of the framework is to make application code discoverable, readable and maintainable, and hopefully help you become an even better developer.

What I love is the matter-of-factness of it all. There is none of the hyperbole (yet) that makes other frameworks sound boastful. There is none of vacuous throwing around of buzzwords. Discoverable, readable, maintainable. This guy wants to help me, the developer, in my development lifecycle experiment.

The code of the Todo app agrees with the general tenor. It is the only framework that manages to be fast and not use Require. I wonder what Mithril would clock in as, if Requirified. Instead, the index.html file has six script elements for each of the supporting files. It’s as if they hadn’t even tried.

(more…)

The main site for Knockout, knockoutjs.com, is a fantastic resource. Maybe it errs a teensy bit on the garish side, but it’s more informative (and exciting with that information) than any of the other sites on here.

I highlighted the outstandingly easy and comprehensive tutorials before. The structure is the same as that of other tutorials on jsFiddle, but it looks better and is more… structured.

Let’s look at the main claims on the home page. Knockout has:

• Declarative Bindings – another word of saying you can tie values in the model to elements in your DOM – both directions
• Automatic UI Refresh – changes anywhere in the model are pushed back to all the DOM elements that need to know
• Dependency Tracking – not only does the DOM follow the model and vice versa, but changes in the model can percolate throughout it (and back to the DOM)
• Templating – yes, you can have templates…

(more…)

What can be said about jQuery that sounds even remotely interesting? The whole world is using this framework, by far the oldest in our list.

jQuery started small. The most famous “thing” about it is the dollar sign, $. It’s what popularized the framework, as it made selection of elements in an HTML page extremely easy.

It’s not that it was hard before, but the W3C spec for HTML and DOM is a terrifying mess of incoherence. Let’s just look at selectors.

If you want an element with a specific ID in a page, you ask the function getElementById(). It takes the ID as argument and returns the element with that ID.

If you want an element with a specific class, you ask for getElementsByClassName(). You have to spell it just so, with the uppercase N or you will get an error or, worse, nothing. Instead of an element, you get a list of elements. You get a list of elements even if there is just one element. If there is no element, you get back an empty collection.

(more…)

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.

That’s all a lot of boilerplate, it seems. The one focus that is interesting is mentioned in the tag line of the site: “Single Page Apps Done Right“

What went without mentioning so far in this entire roundup is that the current model of app development is the Single Page App. What that means is that you don’t jump from link to link to get through your screens, as you would in a typical web site. Instead, your entire application (no matter how many screens) lives in one single link. There is one file (typically called) index.html, and the various pages are just cleverly hidden and displayed elements in your tree.

(more…)