Frameworks are an essential supporting structure of the code we create, because it helps us build sites faster. Backbone and Angular are client-side application frameworks that provide ways for users to interact with data from a server without having to refresh the page.

This decreases the amount of time users have to wait after making a change before they can continue, and it decreases the amount of information sent over the wire because the browser doesn’t need to send duplicate information over and over again. Overall, this creates a much more positive user experience than a traditional multi-page application.

While both of these frameworks provide tools for creating this kind of experience, they have a number of key differences that ultimately led us to switch from Backbone to Angular.

Backbone makes no assumptions

Backbone is a fairly un-opinionated framework, and while it provides some tools for making a client-side web application, it leaves most of the details up to the developer. This provides a lot of freedom when it comes to choosing third-party tools with which to work. Found a great jQuery validation plugin? Plug it in. Want to use AmplifyJS to simplify local storage? Have at it. Backbone makes very few assumptions about the tools you use and it offers a lot of flexibility.

However, this comes at a cost. While Backbone doesn’t place many limits on a developer, it also doesn’t do much out of the box. For example, it doesn’t provide enough of a decent framework for creating modular, reusable components; this can lead to a lot of code duplication, which hurts performance and eats up development time. It also encourages tight coupling between the template — the document that the application injects data into — and the logic that does the injecting; leading to code that is messy, confusing, and hard to maintain.

Angular assumptions can be very beneficial

Angular, on the other hand, assumes a lot about the way you structure your application, but we found that at the end of the day it produces a leaner codebase and cuts down on development time.

For example, one of our recent e-commerce sites featured a multi-part checkout form with validation and the ability to save the form to return later. It was all written in Backbone and took a little over 600 lines of code. Later, we wrote a seperate form with an identical structure, but because Backbone doesn’t provide a way to package code for re-use, it took an additional 650 lines to get the new form working.

The same form in Angular took a paltry 150 lines of code, and all of the non-checkout-specific code was put into its own module for reuse later. So, using Angular we wrote 75% less code and because the code conforms to Angular conventions, a new developer could come in tomorrow, have a look at the multi-part form, and know what it does right off the bat. Pretty sweet.

While we’ve created some great sites and user experiences with Backbone, we think it’s time to give Angular a chance. It provides great value to developers, and because it lets us develop more features faster, it provides great value to our clients as well.