Not surprisingly, given the popularity of the MVC pattern, there are a number of adherent JS frameworks to choose from. Angular JS, Ember, and Backbone are among the most popular, and will be the focus of this article. Your choice here can drastically affect your team’s ability to meet deadlines and maintain your project in the future. Each of these frameworks will give you a set of tools for writing code that follows the separation of concerns ideology. For the most part, they each have thriving online communities that offer support and tutorials to developers.
Backbone is highly compact, extremely versatile, and excels when used on simple projects. Backbone itself is very minimalistic, containing only the base components necessary to structure a web app according to the MVC pattern. Simplicity is both a blessing and a concern here, as a developer must be experienced enough to fully utilize all the available libraries and plugins that are compatible with the framework.
In other words, in order to build a rich web app with Backbone, you must do your research. Since it does not support two-way data binding, your code is liable to contain lots of boilerplate for updating the model whenever the view changes.
Angular JS is backed by Google, and possesses by far the largest community, with the most support and tutorials. As such, there is a very strong feature set out of the box. For example, two-way data binding allows both the Model and the View to update the data, reducing the amount of code needed to build complex UI elements.
Unfortunately, two-way data binding can also deteriorate performance in complex apps, as well as incite debugging chaos. Directives are another popular feature which let the developer attach special behaviors to the DOM, beyond what is described by basic HTML, contributing to a greater flexibility in designing UI behaviors.
Another feature, dependency injection, lets the developer quite literally “inject” a service into a function, by listing it as a parameter. The ability to make a service persistently available to a function contributes greatly to the significant testability of Angular apps.
Ember is rather large, but it comes with a plethora of features. It contains largely everything needed to construct a web app, freeing up the developer to focus on the more prominent issues. This high level of structure can also be a drawback, as any deviation from convention might cause the code to break.
Furthermore, due to the high level of control that Ember maintains over your app design, it can be hard to code features that are not natively supported by it. Ember is notorious for having outdated examples and tutorials circulating the web. As such, it can often be difficult to find help with a particular issue.
Backbone can be very useful when designing simple, single page apps. On the other hand, Ember was designed to enable complex app design, as it handles routine, redundant procedures, leaving the developer free to work on the more challenging, application specific aspects of the code. Its complexity, however, makes Ember much more challenging to learn than Backbone. This can be important if your team of developers is not familiar with the particular framework, or if your project is time sensitive.
Angular, on the other hand, is an enigma. Although it has the largest community, and an impressive feature set, it may not be a good choice with respect to the lifespan of the project. It is important to consider that Angular JS II is in the works, and it will be a serious overhaul of the framework, with no backwards compatibility. As a result, mastering Angular now may prove to be futile, as Angular II may require developers to re-learn the framework. Thus, any web app built prior to the release will be utilizing a legacy framework.
Your choice is your future.
The decision to use one MVC framework over another should not be based solely on what the developers on your team are most comfortable with. It is imperative to the success of your web app, to make an educated decision regarding the most appropriate framework for your project. In order to do so, you must consider both the present and long term lifespan of the application.
That is, how difficult will it be to get the project moving as a result of your framework choice, and how easily maintainable will your app be down the road. The only way to address this, is by considering both the needs of your application, and what you stand to gain from each framework. If you make a hasty decision here, influenced by other factors, you very well might be committing your application to failure.