The frameworks discussed are the ones with the most traction at present AngularJS, Backbone, Ember, and Knockout. Batman, CANjs, Meteor, and Spine are also mentioned but not covered in-depth.
Each project is examined from several different perspectives including community, leadership, maturity, size, dependencies, interoperability, inspiration, philosophy, and features.
A good indicator of the health of any open source project is it’s community. The table below shows the number of GitHub watchers for each of the projects.
You wouldn’t want to make your framework decision on this data alone but it certainly gives you a sense of which frameworks are:
Experiencing the most growth (in the last year)
Small following but are growing rapidly
In particular it is worth noting the incredible growth of AngularJS (379%) in the past 13 months and taking this into consideration when making your decision. The chart below compares the growth of GitHub watchers (over that 13 month period) to provide an idea of how fast the community has been growing for each project. Meteor (130%), Ember (104%), Knockout (76%), and Backbone (64%) also have had amazing growth considering their previously sizable communities.
Jeremy Ashkenas and DocumentCloud
Image Credit: The Canadian University Software Engineering Conference
AngularJS was originally developed at Google in 2009 by Miško Hevery and Adam Abrons as the software behind an online JSON storage service. Abrons left the project, but Hevery, who works at Google, continues to develop and maintain the library with fellow Google employees Igor Minár and Vojta Jína.
Image Credit: Devoxx 2012
Steve Sanderson is the original creator of Knockout. Steve Sanderson is currently working as a developer for Microsoft in the team that brings you the ASP.NET technology stack, IIS, and other web things. Previously he developed .NET software as a contractor/consultant for clients in Bristol and beyond, plus wrote some books for Apress, such as Pro ASP.NET MVC Framework.
Image credit: Steve Sanderson’s Blog
The two most well-known and public of the Ember core team are Yehuda Katz and Tom Dale.
Yehuda Katz is a member of the Ember.js, Ruby on Rails and jQuery Core teams; He spends his daytime hours at the startup he founded, Tilde Inc.. Yehuda is co-author of the best-selling jQuery in Action and Rails 3 in Action books.
Image Credit: Ember Team
Considering how mature each framework is helps you understand how big of a risk you are taking when using these newer technologies in your project. New and unproven frameworks can have problems with documentation, scalability, stability (API changes), and support (finding developers to maintain the code who know the framework) that could cause an otherwise good decision to backfire. Some things to consider include: How many real-world production apps are using these frameworks and how many users do these apps have? How good is the documentation and how many examples/tutorials are available? Are the examples up to date? How stable is the API? Do other developers know or are getting to know this technology?
- Backbone (most mature)
- apps in production for 3 years now including GroupOn, FourSquare, USAToday, DocumentCloud, etc…
- good documentation
- good examples but many now out-dated
- API very stable
- lots of watchers on GitHub
- AngularJS (mature)
- in production now at Google but does not have as long a track record as other projects
- good documentation, getting better
- lots of examples
- lots of watchers on GitHub
- Knockout (mature)
- in production for 2 years now
- great documentation including jsfiddle like examples
- API stable
- lots of examples
- lots of watchers on GitHub
- first production release 1.0 on August 30th, 2013 after 2 years of development
- documentation improving but
- API had intentionally not been stable until 1.0 release
- good number of examples some outdated due to API changes prior to 1.0
- lots of watchers on GitHub
- still early in development used mostly in example apps
- documentation good but a work in progress
- API still evolving
- some examples
- lots of watchers on GitHub
It’s important to understand how big of a download each of these frameworks is and what you are getting for that extra weight in your application. The size affects performance but also gives you an indication of how ambitious a framework is and how long it might take you to learn this new technology as well as hint at how many ways it’s trying to help you build your application (i.e. how many features does it support and how robust are they). The more ambitious and feature rich a framework is the harder it will typically be integrate that framework with others particularly on the same page of an app. Lighter frameworks are more like a library and a smaller commitment to include it in your project?
Some of these projects such as Backbone and Spine pride themselves on how small they are and think of themselves more as a library than as a framework. Often these smaller frameworks leave room for “choosing your own” library to use for features, such as templates and routing. I’ll explore this in more detail when I talk about the features of each.
Other projects, such as Ember and AngularJS are more ambitious and are comfortable being called a framework. They often have more built-in features and depend less on external libraries.
Below is a list showing which projects I would consider more of a library versus a framework.
What other libraries are required to build a real-world application with these projects? The chart below takes a look at what the average number of dependencies each library requires for the developer to be productive and looks at size including these dependencies.
These numbers were gathered by downloading libraries from cdnjs. In practice, most projects will use jQuery with these frameworks to do DOM manipulation in a web application because they need animation and AJAX support as well. In a mobile application it’s not uncommon for projects to use Zepto.js which is a much lighter library for handling DOM manipulation but doesn’t support Internet Explorer which is not a common requirement for mobile applications. AngularJS already has trimmed down version of jQuery jQLite included but jQuery can override it if used in your project. The AngularJS team encourages developers to not add the full jQuery library unless needed. To help you make the right choice, the table above shows a mobile column which assumes Zepto.js and a web application column which shows jQuery.
This section discusses whether each framework is designed to control the whole page or if it can be used as a small part of an existing page as you slowly work this new technology into an existing project. The earlier library or framework discussion for the most part determines how interoperable each of these projects is…so the libraries tend to be more easy to integrate into existing projects while the frameworks do more for you but don’t play as well with others.
Works well with other libraries but developers are encouraged to see if they can do without jQuery and jQueryUI. In fact Angular has a subset of jQuery called jqLite. The rationale for following this practice is ease of unit testing as many dependent libraries and plugins weren’t designed with unit testing in mind and are subsequently more difficult to mock away in unit tests. In practice most developers end up using jQuery for something and including it.
Because of it’s small footprint and un-opinionated architecture it’s easy to include with numerous popular client-side libraries and server side technologies.
Intended to control your whole page at run-time so not suited for use on only part of a page.
Can be used as a small part of larger projects and doesn’t need to control the whole page.
A favorite question of journalists interviewing musicians is “what artists did you listen to growing up or who inspired you.” This often leads to insights or gives hints to their readers of what sound they can expect from that musician. Most of the ideas in these frameworks are not new to software development but come from technologies the creators had worked on in the past and enjoyed. This section summarizes what information I could find from interviews with the creators of these frameworks about their inspiration.
Declarative programming languages such as HTML and the rich internet application technologies (RIAs) such as Flex from Adobe and Windows Presentation Foundation (WPF) and Silverlight from Microsoft were technologies the creators of AngularJS where heavily influenced by in their work. These declarative technologies don’t have a “main” method and just express what needs to happen but don’t specify the implementation . Two-way data-binding in views to model objects is a canonical example of this declarative programming style in action. Also dependency injection and inversion-of-control (IOC) containers in particular Juice which is used heavily in server-side Java code by Google engineers is a stated inspiration for the creators as they value unit testing and need a framework that is designed to allow you to inject your dependencies so tests can be isolated from other application layers and run fast.
Tom Dale did a great job describing Ember’s influence on Quora see below….
With Ember.js, we’ve spent a lot of time borrowing liberally from concepts introduced by native application frameworks like Cocoa. When we felt those concepts were more hindrance than help—or didn’t fit within the unique constraints of the web—we turned to other popular open source projects like Ruby on Rails and Backbone.js for inspiration. Ember.js, therefore, is a synthesis of the powerful tools of our native forebears with the lightweight sensibilities of the modern web. –Tom Dale on Quora
This Hanselminutes podcast has some great background on Steve Sanderson’s inspiration. In summary, the Model View View Model (MVVM) Design Pattern and declarative technologies such as Microsoft’s WPF (Windows Presentation Foundation) and Silverlight were the biggest inspirations. You may have noticed that the declarative two-way data-binding that is the best feature of Knockout is very similar to AngularJS because they had some of the same influences.
The most open-minded of frameworks, extremely unopinionated allowing developers to make their own decisions sometimes to the point where things are done differently enough to make the code less maintainable. The only exception to this stance is the way Backbone assumes a RESTful service on the server which I discuss later in the features section. This assumption can be worked around by overriding the sync method on the model.
Pretty opinionated in particular their emphasis on testability and dependency injection. Also, the idea that declarative programming such as HTML is awesome are pervasive in the framework.
Ember: Extremely opinionated
Strives for developers to only make decisions about what is different for their application and take care of the rest through convention and scaffolding. This philosophy is similar to the Ruby on Rails and jQuery and is best expressed by the emberjs.com website:
Don’t waste time making trivial choices. Ember.js incorporates common idioms so you can focus on what makes your app special, not reinventing the wheel.
Ember standardizes files and url structures but does allow you to override these things if needed. Expect to get a lot more code generated for you and a lot more conventional ways of doing things such as file structure. Consequently, you’ll need to make less mundane decisions because the framework has already chosen a reasonable default and you can get down to the business of building the unique parts of your application.
Knockout : unopinionated
Leaves routing and data storage to the developer’s choice. Doesn’t dictate file or URL structure. Even allows declarative DOM-based templates to be replaced with string-based. templates
- View Templates
- Data Storage (local or through a web server to a database)
- URL Routing (keeping the back button working and search engines happy)
In addition, some of the frameworks provide common language services such as generic pub/sub event model and support for object-oriented inheritance.
Some people might argue Backbone and Spine have some support for data-binding but there is enough work left to the developer that I feel it’s safe to say it’s not a feature of these libraries.
String-based templates, of which the most popular is currently handlebars.js, take string or text templates and replaces the dynamic parts with data from your models. One of the frequently cited but debatable advantages to string-based templates is performance. The cons seem to be difficulty debugging flow of control type logic.
DOM-based templates embrace the declarative nature of mark-up and create an html on steroids experience where html is annotated with additional attributes to describe the binding and events needed. These libraries require substantially less code but do substantially more magic on the developer’s behalf.
Model (observable: change tracking)
These frameworks store data on the server by
- automatically synchronizing with RESTful services
- ask the developer to implement do-it-yourself ajax calls to web services returning json
- allow either of the above approaches
Connected or Disconnected
Backbone by default sends the requests before the data is saved client-side so the server and client stay in sync more easily. Spine, a very similar framework to Backbone, takes a different approach by saving records client-side before sending the request asynchronously to the server which provides a more responsive user interface and allows for disconnected scenarios frequently found in mobile applications. If your project requires disconnected scenarios be sure to understand how well the framework you’re using supports this feature.
These frameworks ask the developer to use $.ajax (jQuery) to make web services calls or add another complimentary open-source library to handle data storage needs.
Data Store Specific
See the table below for a summary of how each framework approaches data storage.
Apples to Apples
After looking at the projects by features it became clear to me that I wasn’t really comparing “apples to apples.” A more fair comparison might be to compare full frameworks like AngularJS and EmberJS with MV* Stacks that include great but less broad libraries like Backbone and KnockoutJS. To be more specific, the following comparisons would be more “apples to apples”:
- Backbone with Marionette
- KnockoutJS with DurandalJS, and HistoryJS or SammyJS
I’ll definitely get deeper into this idea in future posts.
Tell Me More