Tuesday, October 29, 2013

Things that suck in AngularJS (a follow-up)

So apparently my last post made it to the HN front page last night. (For the curious, it got ~35k page views in the span of one day, mostly coming from Reddit. That's roughly the same amount of traffic from all other posts in this blog since inception. Heh.)

First, I'd like to thank the people who have pointed out some factual mistakes in my previous post (specifically, the existence of $q/$q.all and $timeout.cancel). I was not aware of $q.all, so the rant ended up being useful for me to learn new things after all :)

The point I was making when I mentioned $timeout though was about orthogonality - e.g. `ng-if` not having an `ng-else` or even an `ng-if-not` counterpart to match `ng-show/ng-hide` - so hopefully my silly mistake didn't detract from the argument.

Anyways, that post is now almost 2 months old, and a lot has happened both in terms of the progress of AngularJS releases, and my own understanding of the framework/ecosystem, so I figured I should add a little update.

What is better


In the documentation front, there's been a consistent trickle of PR pull requests on the github project to improve various areas of the documentation. Most notoriously, the directive guide is a lot more example-driven and beginner-friendly. Unfortunately, the old docs for directives are nowhere to be found now and it's now much harder to find explanations of what options are available. But it's definitely more approachable and hands-on.

Also, a variety of good 3rd party resources have been springing up. ng-newsletter.com, for example, hits the ground running with some basics and quickly ramps up to some real-world, in-the-trenches goodness.

3rd Party integration

In a similar note, there are also a growing number of projects offering support for Angular, e.g. KendoUI, the AngularCordova project, etc. This is turning Angular into a much more pragmatic pick for a vast range of projects than many of the newer slimmer frameworks in the data binding arena.


The latest two releases bring a bunch of fixes and pragmatic features (e.g. $interval). On the one hand I do appreciate the new features, but on the other, these are release candidates, which by most definitions, shouldn't include scope creep or major breaking changes...

Which leads me to

What still sucks


Regressions are still a very big weakness in AngularJS: the activity in the github issues list spiked after 1.2.rc3 was released, and many of the issues are somewhat serious integration-level problems. Their internal test suite seems to severely lack directive-interop tests, which are critical for a framework with so many interdependent components (I say they're interdependent because they all deal with $scope, often with subtle scope isolation/initialization timing related caveats). The end result is that upgrading Angular is nowhere near the plug-and-play experience of jQuery upgrades.

Other things I didn't mention before


If you haven't seen this term before in the context of AngularJS, components are basically organizational directives, i.e. self-contained ng-includes. They are a mostly useful when a page hosts many loosely related, complex widgets or panels.

One weird design wrinkle is the ambiguity of directive controllers vs regular controllers. Using a directive controller in a component yields less code and clearer modularity, but it breaks the general convention of being able to find all business logic in the controllers folder and DOM stuff in directives. On the other side of the coin, using a regular controller creates more boilerplate code and makes the scoping of inputs and outputs harder to follow.

A big problem with components (and directives in general) is that they can't be used recursively to build things like tree structures. In fact, doing so hangs the browser! The only workaround for this is to use ng-include and shadow variables, which is ugly and confusing from a maintainability standpoint.


YMMV here, but in Toronto, hiring an AngularJS developer is pretty damn hard. We've been looking for a while, but without much success (and we even have a dedicated hiring team). For comparison, another discipline where we historically had difficulty finding good candidates was for backend dev positions, and we've been able to hire 5 since the time we've started advertising for the Angular position. (and yes, we're still hiring for both positions and more).

But the bottom line is that, when the time comes to actually expand the team, the number of people with both a strong front-end background (to deal w/ Angular bugs) and the backend engineering chops to follow the AngularJS way (tm) of designing applications turns out to be surprisingly small.


Angular continues to improve its weak areas and gain momentum, but there are still some somewhat big technical issues and quirks that make development challenging. The unique positioning of the framework in the context of specializations within the industry also brings recruiting challenges to the table.

On a separate note, one commenter expressed interest in a post about backbone. Are people interested in analyses of other frameworks as well?


  1. This comment has been removed by the author.

  2. I'm surprised that you look specifically for "AngularJS" developers and not for the general category of "JavaScript" developers. Any framework can be learned.

    1. We actually are hiring front end developers w/ generic skillsets as well, and that position is a lot easier to hire for. In addition we have some people picking up AngularJS internally as well, but counter-intuitively, the backend devs have an easier time getting up to speed w/ it than the frontend guys. My theory is that this is because they're more acquainted w/ data modeling, whereas frontend dev is largely about putting libraries together these days.

  3. I would also like to read about your concerns regarding backbone!

  4. You can have recursive directives for things like tree structures. You just have to do the compile step manually.


  5. AngularJS is Javascript, but JavaScript is not Angular. I think you should rather focus on a good JavaScript Developer... Frameworks can be learnt, not forgetting just learning and using it but also, using it the recommended way (best practices)
    Tell me what you think about Backbone+JQuery in the same soup.

  6. I am definitely interested in similar analyses for both Ember and React.

  7. Curious to know your analysis of Backbone.