Every once in a while, I find that someone is interested in AngularJS, but not sure if they should stick to their jQuery comfort zone or make the plunge and learn the new thing. It's relatively easy to come across people singing praises to the paradigm shifts that Angular enforces, and there are plenty of tutorials out there showing how to get Angular to do cool stuff without much effort. There's also pretty good explanations out there for some of the more mysterious concepts (like $apply() and transclusions and animations).
The reason I'm writing this is not an attempt to rehash any of those. As it turns out, I've been knee deep doing some pretty neat stuff with AngularJS, RESTful web services, web sockets and other cool HTML5 techs at my job, and I think I've got enough experience to list out some very specific things that aren't that great about Angular. Don't get me wrong, it's a great tool for the stuff I'm doing, but I just feel like complaining a little :)
So, what is sucky in Angular anyways?
Documentation
Docs are a constant complaint in the community: despite being touted as a testable framework, the unit testing guide has been grossly incomplete for ages. Not only that, but most of the API documentation lacks code examples, and makes little to no effort pointing out arbitrary surprises (e.g. ng-selected takes a string instead of a boolean, .bootstrap()'s second parameter is an array, not a string, etc)
The page for directives is another (in)famous part of the docs that, despite relating to one of the most important aspects of the framework, is often derided as being overly dry, and spends more time talking about internals than how to actually create directives.
DOM integration and directives
Many common DOM actions are supported poorly, e.g setting focus on a specific element inside of a repeater, or setting the dimensions/position of an element based on the dimensions/position of another.
Directives - the blessed way of integrating to the DOM - have a lot of optional arguments that don't work well together, and others that break in subtle, hard-to-reason-about ways. For example, ngModelController.$render breaks once you add scope parameters. Transclusion also silently modifies the scope inheritance semantics if scope parameters are added.
Directives can also get stuck in infinite loops when two or more of them act on the same ng-model binding and there are change even handlers.
The problem is aggravated by compiled directives such as ng-repeat and the unstable-only ng-if, since those re-initialize child directives, and can cause event handlers to fire when things haven't really changed.
Another problem with directives nested in ng-repeats is that there's no easy way to control the lifecycle of a directive. Once a list changes (usually due to an ajax call), the redraw performance of a repeater can get unacceptably slow.
The fact that asynchrony is abstracted away in ng-include and the templateUrl argument in directives can also cause difficult to troubleshoot bugs.
I often find that I need to write large comments to explain some subtle side-effect that arises out of an $apply cycle when there are several things happening concurrently in a page.
Business Logic
In addition to the subtle errors that occasionally arise from asynchronous directives, I often run into problems with strictly business-logic ajax as well: for one thing, there's no equivalent to jQuery's $.when, which makes multi-request dependency management difficult (when you hit multiple web services to derive some conjoined information, for example).
It's even more difficult to reason about business logic when your app is big enough to contain nested controllers. You need to carefully manage when controllers are instantiated, what data is ready when, which variables hold promises and when they are resolved, and what is available where; all tied by the scope inheritance mechanism, which is unsettlingly reminiscent of global state.
Bidirectional bindings are two-edged: while they simplify some types of tasks, they make others surprising, e.g. some directives impose types on the variable bound to them, so you sometimes find yourself forced to cast booleans to strings for no seemingly good reason.
Also, I often find myself wrestling against bi-directionality conflicting w/ event-driven programming style, i.e. when calling http methods in response to user actions, as opposed to data changes. This closely relates to the infinite loop problem I mention above and it's a bit of a case of a "pure" system (in the side-effect sense) forgetting to account for the real-life need for non-idempotent actions.
Filter Caching
Repeater filters are not straightforward to cache: if I want to display the length of a filtered list, I have to either re-compute the filtered list (very expensive), or introduce assignment logic into the HTML view (untestable and ugly), or refactor the filter into the controller as part of the data initialization (not desirable for data required to compute derivative metadata).
3rd-Party integration
Calling Angular services, filters and controllers from outside of Angular is verbose and non-intuitive, making it a difficult sell for progressive adoption into a legacy codebase (read: most non-trivial codebases). More importantly, under those circumstances, it sometimes fails in inexplicable undebuggable ways (I'm looking at you, $http, and yes, I called $el.scope().$apply()).
Internal Complexity
I consider myself to be a reasonably good js developer, but the internals of AngularJS are overwhelmingly non-approachable. Even seemingly simple request changes like the ability to abort http requests require massive amounts of design discussion and implementation attempts because of all the levels of abstraction that need to be reconciled. My general feeling is that the API designers don't care much about orthogonality: several features are missing counterpart/complementary mechanisms (e.g. there's a handy `$timeout` but not a `$clearTimeout`, form.setPristine() was added in unstable, but it's not readily available in the controller and it doesn't have per-field equivalents, etc)
A lot of the complexity leaks from the abstraction prominently into developers' day-to-day: most Angular developers have seen the non-helpful "$apply() already in progress" error. Also, in my experience, bugs in AngularJS apps require a relatively intimate knowledge of several layers of abstraction simultaneously, and are much harder to debug than traditional jQuery ones.
Another semi-related note: The unstable branch is rightly named so: it introduces breaking API changes at every release, and new features often have integration problems when combined with other features. It does contain some incredibly useful features, but I'm not even sure how they plan on officially releasing this unstable stuff, since the effort required for developers to migrate from the current stable to the current unstable grows just that much more with every version increment.
Testability
There are no built-in mechanisms for testing directives.
Also, angular-mocks is incompatible with the ng-app directive (and .bootstrap(), for that matter), making in-page testing (using jasmine ConsoleReporter) impossible.
Integration testing can only be done when using ng-app, making multi-application pages untestable. This is a testability showstopper when your project involves a lot of legacy code that is ported gradually (like most legacy-laden projects are).
Parting Thoughts
This is a list of things that could be improved in AngularJS (1.2) from the point of view of someone whose full time job is pretty much to push techonology to the limit. It's not an attempt to promote Ember (which I haven't had the chance to look at) or Backbone/Knockout/jQuery/whatever, all of which have their own merits -- ok, Backbone sucks, but that's for another post :)
