1. 05 Oct 2014

    How We Use AngularJS: Part 1

    By: Jason Bishop


    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:


    As a front-end developer and designer, JavaScript is one of the main programming languages I use on a daily basis. For the larger part of my career, I’ve had the luxury of great frameworks like Prototype and jQuery to smooth over some of the rough edges that come with executing JS inside of a browser environment.

    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.

    The Case For AngularJS

    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.

    #1. AngularJS makes choices for us and we like that.

    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.

    #2. Software engineering is a collaborative effort. AngularJS helps keep everyone on the same page.

    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.

    #3. AngularJS has traction.

    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.

    #4. We love its feature list and overall power.

    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.

    #5. We love Rails. AngularJS loves Rails.

    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.

    What We Don’t Use AngularJS For

    As a sidenote, I thought it might be relevant to include use cases we prefer not to use AngularJS for:

    • Anything we want crawled by a search engine, for example, brochure sites. These sites aren’t often that interactive from a UI standpoint and AngularJS introduces unnecessary complexity in a use case that has been sufficiently solved by other tools. And the reality is that many people want to use no-frills WordPress (and are good at it).
    • Simple, non-feature-rich interfaces. We’ll just use a generic ERB for that.
    • Widgets or other small, discrete, embedded interfaces. For most widgets, including a framework is probably overkill. If it is a feature-rich widget, is it really a widget? Sometimes the answer is yes; oftentime the answer is no.
    • Projects with other MV*’s already in use. We think it’s probably better to not inject AngularJS into a project already using another library which provides overlapping functionality. This is because AngularJS in many ways functions as a self-contained state machine and managing that state outside of AngularJS can become cumbersome. In short, a general rule of thumb is: make your other front-end JS subordinate to your AngularJS code.

    Stay tuned for Part 2, in which I discuss how we set up our AngularJS projects!