5 reasons to use AngularJS

I've been using AngularJS for about a year now, and I think it's safe to say that it's one of the best things to happen to me as a web developer. It's made UI development faster, safer (ie. testable), and more enjoyable for me then ever before. And by studying it's source code and taking up it's techniques and philosophies, it's made me a better programmer outside of AngularJS too.

If you haven't heard of AngularJS, go to their home page right now, read through the blurbs, have a quick toy with the demos, then come back. If you're not sold on it already, read on and I'll tip the scales for you with 5 reasons to start using AngularJS for all your web development work - especially if you're working with a legacy system.

1. Less work for the same result

The story behind how AngularJS went from a hobby project developed solely by +Miško Hevery to being a Google sponsored open source project is that Misko went to his manager, +Brad Green, and said "You know, I bet I could rewrite our current project in Angular in 2 weeks.". It took 3 weeks and the lines of code went from 17,000 to 1,500.

The key behind such a massive reduction in code is AngularJS's declarative approach to data-binding on the UI. Lets start with a simple example. I want a text input to update the message in another part of the DOM. Here's how I might do it:

<input type="text" id="messageInput"/>
<span id="messageOutput"></span>
<script type="text/javascript">
(function () {
  var input = document.getElementById('messageInput');
  var output = document.getElementById('messageOutput');
  input.addEventListener('change', function () {
    output.innerHTML = input.value;
  });
})();
</script>

Now compare to the same thing done in AngularJS:

<div ng-app="">
  <input type="text" ng-model="message"/>
  {{message}}
</div>

Done.

I have simply declared "Here's my application, here's an input that binds to 'message', and here's somewhere to output 'message'."
The "How" is left entirely to the directives to determine.

It's a contrived example, but it demonstrates the advantage of a declarative approach: Stating the "What?" and then letting the framework handle the "How?".

The same can be said for dependency injection. When I'm writing a controller, I don't tell it where and how to get the '$log' service. I just declare "I need the service called '$log'".

2. It thins out your server-side code

Angular takes care of templating and routing your views, which is generally a non-trivial chunk of your server-side processing and code maintenance. You can entirely decouple your client application, leaving the server to serve and consume JSON data.

This provides a great opportunity if you've been thinking of switching or experimenting with different backends. Lets say your backend is written in Ruby on Rails, but you're interested to see how it would perform with Groovy on Grails instead. You can write your front-end in Angular with a RESTful server API, then swap out your backend with something that serves that same API. It's no small thing to rewrite a whole back-end, but it's a hell of a lot easier when you don't need to worry about the UI.

3. Testing is trivial

AngularJS was written from the ground up to be testable. Dependency injections lets you slip in mock versions to work with. Directives can be triggered by using $compile on HTML strings. HTTP responses can be imitated with a mock $httpBackend service. And all of this without actually attaching anything to the DOM, meaning your tests run lightning fast.

The barriers to testing AngularJS applications are only as high as you choose to make them. You're writing less code, so you have the time to write tests from the start. Sometimes you may feel that writing your mocks takes so much effort that it's impractical. That's a sign that either you need to take a closer look at the documentation for Jasmine 'spies', or you need to rethink your design ("Why does this single unit of code need so much 'stuff'?")

4. Your user experience is more responsive

You don't always notice just how much time is taken changing from one page to another, on the web. Sometimes that's to be expected, such as when moving from a completely different 'site' to another. But when you're moving from one page to another, within the same site, with almost the exact same headers and footers, CSS includes and Javascript libraries, it should only take as long as is required to load the HTML which has changed.

With a SPA (Single Page Application), like Gmail, you have some initial load time on your first visit, but then content changes within that application are near instantaneous. You can manage this easily with AngularJS's built in URL routing and ng-view directive. And if that's not sophisticated enough for your needs, you can use ui-router to define your application in terms of a state machine with nested views.

5. Great community

Last, but far from least, is the AngularJS community. There's no shortage of resources for learning Angular (eg. egghead.io, yearofmoo), places to ask questions or just 'stay in the loop' (eg. Google Groups, G+ Commmunity, IRC Channel, Meetups), and open source projects for improving Angular development (eg. Angular UI, Yeoman generator, ng-boilerplate). Everyone I've interacted with in the community has been helpful and constructive with their criticisms. Angular would not be seeing the success it has without such positive community contributions.

If that hasn't convinced you - power to you, you must have a damn nice set up already.
If your curiosity is piqued, but you still have concerns, visit the G+ Community or IRC Channel.

Cheers,
Jason Stone

(Originally posted 22 January 2014 at legacytotheedge.blogspot.com)