This story was written by Keith Dawson for UBM DeusM’s community Web site Develop in the Cloud, sponsored by AT&T. It is archived here for informational purposes only because the Develop in the Cloud site is no more. This material is Copyright 2012 by UBM DeusM.

JavaScript Framework Overload

Selecting resources for client-side development of greenfield Web apps.

Those just starting out on the client side of a Web app project face an all but overwhelming choice of JavaScript frameworks around which to structure the work.

Over the last several years, as Web apps have grown increasingly complex, more and more developers have come to realize that they need more structure and organization on which to hang the app than that provided by the DOM, jQuery, and a few supplemen­tary utility libraries. Numerous frameworks have grown up to serve as starting points for JavaScript client-side development. Most of them have settled on some form of MVC (Model-View-Controller) pattern -- or, to be more general, "MV*" for "Model-View-Something."

Consider this bare listing of JS frameworks, with one-sentence descriptions. At the moment it contains summaries of 78 libraries or frameworks: 23 listed as "Full-stack Frameworks / Toolkits," 12 as "Architectural Frameworks," and a further 8 as "Supplementary Libraries." Other lists organize the existing toolkits into different categories.

This profusion of developer tools is more than sufficient to keep an unprepared developer in analysis paralysis for an indefinite period as s/he tries to evaluate project requirements against the capabilities of 20 or 30 toolkits -- and that's the short list!

How do you even begin?

A couple of resources stand out to help you cut through the clutter. Both of them came together in the summer of this year.

Head-to-head implementations
Smashing Magazine mounted an ambitious project to implement the same simple app -- a to-do list manager -- in a large number of JavaScript frameworks. The thinking was that this will facilitate head-to-head comparisons of the more popular frameworks, albeit in the context of a rather trivial app. Any real-life app is going to have detailed requirements that you are going to have to think hard about in terms of what candidate frameworks can offer. Still, the ToDoMVC project should give you a feel for the coding styles and conventions represented by the different frameworks, and demonstrate in practice some of their philosophical underpinnings.

The article describing this work, Journey Through The JavaScript MVC Jungle, also presents a list of 8 criteria to be used in doing the final due diligence, once the field has been narrowed to two or three candidate frameworks.

A conference
The organizers of the Throne of JS conference had the interesting idea of gathering together into the same room the principals of eight of the most popular JavaScript frameworks, and inviting developers to come and listen to their views and interact with them. One such principal, Knockout's Steven Sanderson, wrote up a detailed post-mortem on the conference.

The frameworks represented were AngularJS, Backbone, Batman, CanJS, Ember, Knockout, Meteor, and Spine. Of special interest in Sanderson's account are the lists of the points on which the frameworks generally agree, and those on which they differ. The major areas of agreement included the MV* pattern and a bias in favor of data binding. The major divide is between the "frameworks" and the "libraries" -- i.e., those toolkits that offer an architectural structure into which projects are expected to fit, and those that provide instead a set of tools to plug into your existing architecture.

To those embarking on the journey of selecting a JavaScript framework, one can only say "Good luck." These resources should give you at least a place to push off from.