This post contains the slides and associated commentary for a short presentation that I gave at the June 2014 Boston Front End Developers Meetup. You can also view the video of this event.
Hello, my name is Jeff Whelpley and I am the Chief Architect at GetHuman. A little over a year ago we decided to build our front end with AngularJS. In this presentation I will explain why we chose Angular over other alternatives like Ember or Backbone.
First, I think it is important to understand the three things that make Angular different than other frameworks and that make Angular special. Namely,
- Angular markup lives in the DOM
- Angular uses plain old JavaScript objects
- Angular heavily leverages Dependency Injection
Templates in most client-side JavaScript frameworks work like something like this:
- template with markup -> framework template engine -> HTML -> DOM
Angular, on the other hand puts markup directly into the HTML document and the flow looks like this:
- HTML with Angular markup -> DOM -> Angular template engine
Angular evaluates the markup only after HTML has been loaded into the DOM.
So what?
Well, this approach has three major benefits.
- Integration with Existing Apps – Since Angular only starts evaluating the page at the end of the loading process (i.e. once HTML is in the DOM), it is very easy to sprinkle small bits of Angular “magic” on top of existing applications.
- Simplicity – You can work with Angular in a basic HTML document from you local file system. Just open the HTML document in your browser. No need for any web server or template build process. I have found this very useful for creating quick mockups of a new website or piece of functionality.
- Extensibility – Using Directives, Angular allows you to create custom elements and attributes that extend the standard HTML vocabulary. For example, in this slide there is a my-custom-tag element. Using Angular you can define how that element is rendered and assign behaviors to it. This allows you to create a library of your own reusable components.
Angular is one of the only major front end frameworks that utilize plain old Javascript objects (POJOs) for the model layer. This makes it extremely easy to integrate with existing data sources and play with basic data.
Let’s say you make an AJAX call to get some data from an API. Before you can bind that data to the DOM, most frameworks require you to wrap the data in Model objects that have getters and setters. The getters/setters are how non-Angular frameworks propagate data change events.
Angular gets around this by using a process called dirty checking where snapshots of data over time are compared to see if anything has changed. While there are certainly some downsides to this approach (ex.$scope.$apply, data binding limits, etc.) I think the simplicity of using POJOs outweigh those downsides in most cases.
There are some people that love dependency injection and there are some people that hate it. If you are going to work with Angular, you sort of need to be in the former camp. I personally love it because it promotes better modularization of code and enables strong unit testing.
Unit testing front end code is usually hard because there are so many sticky dependencies. Angular’s DI allows you to mock out many of these dependencies and isolate individual components.
We don’t have enough time today to discuss every AngularJS feature, but I do want to point out a couple important ones.
- Scope management – If you are going to create non-trivial web applications with Angular, you will have to take time to understand the way in which Angular isolates and shares data between components.
- Animations – One of my favorite Angular features is the Animations library. Check out my buddy Matias Niemela’s blog on Animations. You will be amazed by how much you can accomplish with very little code.
One of the best things about Angular is that they made it very easy to build on top of the framework and to integrate with external libraries. This has allowed for the creation of very rich ecosystem. Here are some of the libraries outside of Angular that I use the most:
- jQuery – Angular does not require jQuery, but it is needed if you want to use any jQuery plugin.
- Angular UI – The UI Router and UI Bootstrap libraries are indepensible.
- AngularFire – Similar to GoAngular, an easy way to hook your Angular app up to a realtime backend.
- Ionic – A great mobile web app framework that works on top of Angular.
Why should you choose to use Angular on your current project?
Before I answer this, let me takes a step back.
Why you would choose any framework over another one? For me, the things on the left side of the slide are more important than the things on the right side.
Left side
- Ease of maintenance – When there is a problem, I don’t want to spend hours debugging. I should be able to make day-to-day minor changes with ease.
- Efficiency of building new features – When I want to build something new, does the framework help me or hinder me?
- Engagement of the community – When the community is large and strong, it can overcome many issues within the framework. The community contributes to the framework, but then also builds many complentary libraries that work alongside the framework and make it even more powerful.
Right side
- Current features – Features of course matter, but if you are making a decision for the long haul you shouldn’t be concerned about missing features if the current ones get you 80% of the way there and the stuff on the left side is all in place. For example, the Angular router is not that good, but the community built the UI Router which is a lot better.
- Current performance – I care A LOT about performance, but the reality is that most front end Javascript frameworks are plenty fast enough. I am sure the React is faster in certain use cases and CanJS can spin a graphical image faster than anyone, but most of the performance differences are marginal and won’t be noticable in a majority of web apps.
- Current learning curve – Everyone loves to talk about learning curves when comparing frameworks and I hate it. Look, if something is going to make you a badass, who cares how long it takes you to learn it?
My main point is this:
Near-term limitations are usually overblown. Focus more on empowering your team in the long term. Ask yourself, “which framework help my team be the most productive and happy over the course of the next couple years?”
The answer to that question is different for different organizations. My personal opinion is that for most organizations today it comes down to either Angular or Ember.
That does not mean, though, the other frameworks can’t be the answer. In certain situations, React, Backbone or another framework can make absolute sense. I just think right now, those use cases are the minority.
So, why did I choose Angular over Ember?
- Fun to get started – Let’s be honest. There are large learning curves for both Angular and Ember when you want to build large applications. When you first start out, however, you can get up and running with a simple Angular app very quickly. I have found that this helps lower apprehensions some people may have for moving to a new technology.
- Framework Abstractions – I like dependency injection. I like fact that you can create your own Domain Specific Language (DSL) within HTML using Directives. I like the way you can group your components into modules. This is one of those things that just feelsright for me.
- Note that Ember is working on a feature called HTMLBars which will have some Directive-like features.
- Flexibility – What is idiomatic Angular? No, seriously, what is it? I have no idea…and neither does anyone else. If you compare two large Angular projects from two different companies, they will almost certainly be very different because there are no well established standards for how the framework should be applied. This is in stark contrast to something like Ember where they live and die by well known standard best practices. The thing is, though, I have strong opinions of my own and I value the flexibility Angular gives me to define my directory structure and compose my app in the way that I want. You can of course do this with Ember, but you will definitely feel that you are going against the grain. Whereas with Angular it is totally OK for you to do things your own way.
- Focus on testing – Besides the ease of unit testing with dependency injection, the Angular team created two very good, robust testing frameworks in Testacular…I mean Karma…and Protractor.
- Note that while traditionally Ember has been behind Angular on the testing front, they seem to be making improvements with their recent Ember CLI initative.
- Fantastic Community – I have gotten to know many prominent members of the Angular community the past year including several members of the core team and outside of SEO, we share many of the same thoughts for how web apps should be built. The Ember community is also very strong, but I just feel more of a connection to the Angular community.
I don’t have time to go over everything in the list, but these include many of the common gripes people (including myself) have with Angular. Some of these items, like the Router, have good alternatives from the community (see the UI Router). I am currently working on the problem of Angular server side rendering with pancakes.js.
Even though I don’t think any of these issues are earth shattering, it would be nice if they were addressed someday…
I have good news and I have bad news.
Good news: Outside server rendering, every one of these issues should be resolved with the Angular 2.0 release that is due out later this year.
Bad news: In order to resolve these issues and make advances in several other areas, the Angular team has decided to rewrite AngularJS from the ground up. The 2.0 release will only support evergreen browsers and Angular 1.x components may not be able to integrate at all with 2.x components.
My organization is not that concerned about this issue, however, because:
- Assuming 2.x doesn’t come out until the end of this year we likely won’t think about upgrading until a full calendar year from now by which time the IE8 market share will almost certainly drop under 1%.
- Although 1.x components may not integration with 2.x components, you would still be able to use 1.x in some parts of your app and 2.x in other parts (side note: you should be building many small apps in Angular instead of one large one).
- I think there is a good chance that the Angular team or someone from the commuty will figure out a good upgrade path even though one isn’t clear right now (no evidence on this, just my gut feeling).
Here are some links to resources that you can use to learn more about Angular.
Videos
Guides
Third Party Libraries
Debates
Ref: http://jeffwhelpley.com/angularjs/
sudo man 