A quick comparison of modern client-side MV* frameworks

At the September meetup for CTFEDs (Cape Town Front End Developers), Hendrik Swanepoel of 22seven took us through three frameworks: Backbone, Ember, and Angular. He gave a great talk outlining the general principles of each, and gave code snippets to show how they work. His slides are available on SliderShare, and below are my notes from his presentation.

Introduction

Hendrik's talk was about choice. We think we're objective in our decisions, but really we're not. It's okay to be subjective, and to use what you like.

MVC stands for Model View Controller. It's a design pattern that was introduced in the 70s, and was about separating concerns. An example of a Model at 22seven is Transactions.

Robin Ward (Evil Trout) says that looking at the level of interactivity of your application will help you decide whether to use a client-side MVC framework or not. The more interactive your app is, the more likely a client-side MVC will be a good choice for you.

Hendrik said that looking at the popularity of a framework can be a good start for choosing one. Stars on GitHub, how recent commits to the repository are, the frequency of commits, and the number of pull request were mentioned as metrics to consider. All three mentioned have Chrome extensions that Hendrik says are very useful.

Backbone.js

Backbone provides a set of building blocks for developers. That's the best and worst of it, by design. A Collection in Backbone is close to a Controller. You can use any templating engine you like, but many choose underscore.

One criticism of Backbone is that it takes a lot of boilerplate code. You can bypass this to some degree by using community-produced plugins from BackPlug.io.

Ember.js

The official description is a dry, opinionated, feature list and that tells you a lot about the framework. Models used to be done with extensions of Objects, but now can be done in pure JavaScript. This was a big change in the API and broke backwards compatibility. In this case, however, it was for the best.

Hendrik showed four steps of putting together an app, demonstrating how easy it is to do a lot in a little time. You fill in the blanks in the code with details of your app. To make it work, you must use Ember in its totality.

It looks a bit like Ruby on Rails: some of the core contributors are also Rails contributors. Naming is important, and like RoR, Ember aims for convention over configuration.

Angular.js

Many say that Angular is what browsers will look like in the future. It uses Declarative code for UIs (e.g. HTML), and Imperative code (e.g. JS, Ruby) for business logic. It's Hendrik's favourite of the three.

As an aside: looking at Routes first is a good way of getting a feel for things.

Angular is declarative, expressive, and short. It uses the custom concept of Directives. There are no script tags: just attributes on normal HTML. There are also element directives, with data added to attributes. Filters are used as view helpers, such as uppercase, rounding, etc. Angular uses its own custom run loop, which is why injection using $scope is so important.

Conclusion

22seven had a large existing client side set of data, so Angular was the right choice for them. Hendrik recommends finding the one you like, that you are passionate about. They all have flaws, but you will find workarounds and fixes for the deficiencies for the one you like.

ToDoMVC is a resource that can help you decide which is right for you. It shows code for the same simple ToDo application is many frameworks.

Other important tools Hendrik recommends are Bower package manager and RequireJS module loader.