The following are a few of my thoughts about the two libraries and building applications.
What You Have to Learn
The learning curve for both libraries can be pretty steep once you “dig in”. Backbone is very straight forward and provides a good base to build on, but you do have to solve some problems on your own. The Model, View, and Controller concepts are presented clearly and allow for easy extension to build your own pieces and parts. You do however need to solve the problem of creating and destroying views, and object management. One thing I absolutely loved in Backbone were services. After spending some time learning about Backbone’s sync and how to work with it, creating and managing services and the requirements, like conditional requests that I might need to add to the service, became very, very nice.
AngularJS is very quick to get started with and create something “neat”. Once you need something real, the learning curve shows up. It takes a bit to get used to the different perspective Angular comes from. Once you understand that perspective, Angular seems very natural. Understanding the bootstrap sequence, modules, services vs. factories, how to manage data, the digest cycle and directive and how all of these pieces and parts fit together can take some effort. That effort is worth it though. Angular gives you the ability to create some very cool, very useful, easily shareable components and applications quickly. Angular solves a lot of the problems that Backbone doesn’t, but it is “larger” in the sense of the concepts and ideas that you need to grasp before using it effectively.
Keeping It D.R.Y.
Don’t Repeat Yourself – a programming mantra right? You’re going to encounter boilerplate with both libraries. In Backbone you have to solve some problems on your own. Based on how you do this, it can keep things more or less DRY. Views for example, creating a base view, that manages creation and destruction is a standard first step for a Backbone application. Just make sure anything you encounter that might make things less DRY has a fix for that. There are some libraries out there, like Marionette that can help with this.
In my opinion Angular does a better job of keeping things DRY. Fom the stand point of many of the standard problems have already been thought of and solved in a DRY manner. There is plenty of boiler plate code to set up the different modules, directives and objects. Angular also doesn’t prescribe a specific way to organize or assemble all these modules and objects. It is up to you to make sure it is done in an organized and sharable manner.
Admittedly I’m not a huge unit, behavioral, or automated tester. Don’t get me wrong, I’d love to be! I’ve researched, read about it, tried stuff out, talked about it and tried to implement it on teams and projects. It takes a discipline that I have yet to find for the types of projects and timelines that I’ve been working on. That said, Angular had Testacular which turned into Karma and now has Protractor. Karma was great to work with and I’ve yet to play with Protractor, but have heard great things about it. Backbone, being as straight forward as it is, allows you to choose your testing tools. Jasmine, QUnit, etc, should work with Backbone (you can keep me honest here. Like I said I haven’t done much in the way on testing with either library.).
Get Up and Running
How quickly can you get something up and running? The answer, very. There are plenty of tutorials and how-to’s out there to get you going with either of these libraries (there is a list of resources links down below). Angular is super quick, include the library in your page, add an attribute to a DOM tag and you’re off. Backbone takes a little bit more, but not much.
What’s The Point?
Or, maybe I’d go check out Kendo or EmberJS, who knows. What do you think? Let me know in the comments or say “hi” via email.