Thinking about Javascript MV* Frameworks

Lately, we are beginning to think about Javascript MV* frameworks. While we are not yet comfortable using these frameworks for public facing sites, we do think they make a lot of sense behind a login where the user is creating and updating content.

Our Audio Backpack application allows users to create their own classical music playlists. We built it in Ember.

I spent some time recently reviewing a few frameworks and came up with these bullet points in trying to decide which one to bet on internally long term. This is what I found:


– digest for 2 way binding can be inefficient as it uses dirty checking in a loop – computationally expensive
– Uses Plain old Javascript objects (POTS)
– More of an open ended tool set than a framework
– Directives let you bind behavior to DOM elements
– A few more edge case bugs
– Can filter expressions easily (ie an html table filter results for results that have a coomon value in a filed like show me all the results with city is St. Paul – not sql filters the markup)
– Custom services
– We have someone coming in new to our team with Angular experience
– Angular 2.0 coming out may not be backwards compatible


– A more opinionated framework that almost make you do things “the right way”
– Very Rails-like lots of similar concepts
– 2 way binding more efficient because you have to call accessors – getter and setter methods explicitly
– CRUD field generation based on models a la Rails allows for rapid development
– Powerful router that works just like the Rails router
– Better documentation
– Computed properties very powerful ie a circle object that has a user entered radius field can have a diameter filed that is calculated automatically
– is only just getting to stable APIs

– even less than a framework than Angular. A tool set where you do most of the work but is more light weight

– Really just concerned with the V in MVC but is very efficient with its use of a virtual DOM to shadow the Real DOM. Can be used as the V in Backbone.

At this point I am still leaning toward Ember for a few reasons. First we do a fair amount of Rails already and Ember is conceptually very similar to Rails. Additionally, an opinionated framework can be really helpful in a team setting where some of the team is new to the framework as it almost enforces good practice.

Comments are closed.