In mid-2013 I fell in love with AngularJS. This is an important fact for me to mention before going further. I am absolutely biased towards this framework. As with all technologies, I do however encourage readers to carefully look at alternatives (Ember, the Backbone economy of tools, Knockout, etc.) before making a decision for any production code. This purpose of this post is not to convince you that AngularJS is the right tool for you; rather, the purpose is to explain why AngularJS is the right choice for us - and possibly for other people who find themselves in a similar situation! If you’re looking for a rundown of each framework, check out any of these resources:
Some years ago, very intelligent thinkers began to bring aspects of MVC sensibilities to client-side code. This resulted in a proliferation of apps with rich, dynamic user experiences, the technical functionality of which was largely unaddressed by previously existing frameworks. For a while, Backbone was probably the best-known of these libraries (and perhaps still is). It gave front-end programmers access to a rich data model and interacting with server data became that much easier.
Meanwhile, other tools were being built which encouraged JS-heavy projects. Node, of course, allowed web apps to be written entirely in JS for the first time. Today, JS apps come fully-equipped with test suites, scaffolding scripts, package managers, component libraries, and more. Some of the more popular tools include RequireJS, Bower, Yeoman, Jasmine, and the like.
Front-end developers were now in a position to choose from a variety of resources with which to craft interfaces. In the case of Backbone alone, front-end developers may choose from tools like Chaplin, Marionette, and more (https://github.com/jashkenas/backbone/wiki/Extensions,-Plugins,-Resources).
Enter AngularJS, a library which offers a common tradeoff: tons of rich functionality in exchange for flexibility.
So why AngularJS over other libraries? Isn’t Backbone the tried-and-true solution? Isn’t it preferable to be in a position to choose just the right tool for just the right use case all of the time? If not Backbone, why not Ember? For some developers and teams, those tools will be the right solution. For us, it’s AngularJS.
Developers, product managers, and other technologists are opinionated folk. Forming consensus is a challenge. Making the choice to use AngularJS means we can avoid conversations about solutions for data binding, dependency injection, and much more. We can spend more time engineering and less time in meetings.
AngularJS contains a rich set of functionality meaning we have to turn to fewer libraries to get the same amount of work done. When new features, such as filtering, are implemented in the front-end, AngularJS provides a predictable mode of implementation. One result is that when another developer touches that piece of code, it’s purpose and function will become immediately apparent without detailed investigation. Adding new developers to the team is also significantly easier, since they only need AngularJS as a prerequisite as opposed to a stack of JS tools.
According to many metrics, the popularity of AngularJS is on the rise (http://www.google.com/trends/explore#cat=0-5&q=angularjs,%20backbone.js,%20ember.js,%20knockoutjs&date=today%2012-m&cmpt=q). At the time of writing, Stack Overflow has a deep repository of AngularJS information, moreso than other popular clientside MV*’s (see: http://stackoverflow.com/tags). One might argue that AngularJS is simply trendy or that it incites the most ire amongst users online. Putting speculation aside, there is an indisputable bottom line: people are using it. This has many favorable effects, for example: 1) ease of hiring; 2) ability to hand off code and be reasonably certain that the recipient can work with it; 3) codebase longevity and overall community support; 4) availability of information online. Backing from Google doesn’t hurt, either.
AngularJS is an extremely powerful library to build with. Implementing things like real-time search, template caching, and data binding, can be done elegantly and sustainably in seconds. Features like directives and animations are also neat add-ons that are well-addressed by AngularJS.
Our full-stack and back-end developers spend a majority of their time writing Ruby on Rails code. It’s core to our business and, from a personnel-standpoint, institutionalized for now. Where other JS frameworks (I’m looking at you, Backbone.) only become very powerful when coupled to many other libraries while being managed by various JS-specific tools, AngularJS simply plays nicely with Rails. We don’t want to introduce additional technologies to do things like asset management when Rails already does that for us. Using AngularJS in a Rails project just requires a link to the Google CDN (although we use the AngularJS Gem). On a stack leveraging Backbone, other tools, such as Bower and Yeoman become much more attractive. For us, we want to stay within Rails’ ecosystem.
As a sidenote, I thought it might be relevant to include use cases we prefer not to use AngularJS for:
Stay tuned for Part 2, in which I discuss how we set up our AngularJS projects!