Some AngularJS pitfalls

Agreed. I tried to explore this issue a while back: http://branchandbound.net/blog/web/2012/11/unify-server-side...

Turns out that using script-tags is somewhat problematic, but as a comment points out, data-attributes could work.

You are somewhat misinformed: If you are using more than one template, this is a non-issue. Only the HTML from the initial page load will ever display template bindings, that being the purpose of ng-cloak, ngBind, etc. $templateCache can be pre-loaded with something like the ng-templates Grunt task, so excessive HTTP requests are not an issue either.

Nice writeup, here is my input on the points OP makes.

The flickering UI

A quick fix would be to extract the problematic markup, place in a separate template file and leverage ngInclude[1].

If you find yourself having many instances where this is a problem, chances are you aren't doing a good enough job of breaking up your application into controllers, page components, directives, etc.

jQuery and Angular

In my opinion the example is little weak in terms of demonstrating a pitfall of AngularJS.

Based on AngularJS best practices you'll find yourself only doing any sort of DOM manipulation in the context of a directive (much like your example). Bringing jQuery into your Angular app for the sake of using .hide here probably won't make much sense. Chances are pretty good you'll leveraging directives such as ngShow[2], ngHide[3], ngIf[4] (version 1.1.5). No need to bring jQuery in for that.

If there is indeed a valid reason to bring jQuery into the project, I'd say the responsibility lies more so on the developer ensuring the dependency is met.

Minification

With the addition of ngmin[5], this isn't necessarily a pitfall just something to consider in your workflow. There is a ngmin grunt task[6] that works as advertised! I've been using it for quite some time now and never an issue.

My thought overall though is if you've conceded minification is a step in your project workflow, you'll be using tooling to make that easier. Bring ngmin into the mix and all is well.

Directives are never 'done'

I would suggest looking into using $watch[7] within the scope of that directive or making use of compile post linking over the linking used in the example. Check out the compile section [8] of the directive guide for more information there.

[1] http://docs.angularjs.org/api/ng.directive:ngInclude

[2] http://docs.angularjs.org/api/ng.directive:ngShow

[3] http://docs.angularjs.org/api/ng.directive:ngHide

[4] http://code.angularjs.org/1.1.5/docs/api/ng.directive:ngIf

[5] https://github.com/btford/ngmin

[6] https://github.com/btford/grunt-ngmin

[7] http://docs.angularjs.org/api/ng.$rootScope.Scope#$watch

[8] http://docs.angularjs.org/guide/directive

Nice writeup! I'm using angular now on a work project for the first time.

My observation here is the same as what I've had for many "look how easy it is!" frameworks: A lot of frameworks sport "look how easy it is!" syntax, but using the easy/short syntax actually isn't adequate in some (sometimes most) circumstances, and often it isn't even "recommended." So you start using the longer, more explicit syntax, and all those short/sweet syntax features are out the window.

For example, the easy-to-read {{obj.prop}} data-binding syntax is basically dis-recommended here with three workarounds given (use ng-cloak, declare databindings on element attributes, externalize & `include` the offending markup). Once you have 3 different workarounds for what's basically the most fundamental framework feature, I can't help but wonder "why offer this short/sweet/brittle syntax in the first place? Most 'power users' can't really use it." The dep injection one in particular- basically any shop worth its salt is going to use a minifier on big JS applications- none of them (us) can use the short dep injection syntax. Why even teach it/include it at all?

I guess it gets people up & running faster, but eventually you have to deal with these pitfalls.

  Why even teach it/include it at all?

I fear that other developers will read a comment like this three months down the road and take it hook, line, and sinker. It is in line with the narrative that AngularJS and similar tools hide their complexity/inflexibility, and that the up-front examples are marketing fluff. I know I am guilty of this when I look to comments like this one for the "on the ground" perspective.

Real-world AngularJS applications use multiple templates and {{ o.p }}. {{ o.p }} is the recommended way to render scope 99% of the time.

ngmin[1] solves the DI minification/annotation problem transparently and is trivial to integrate into any existing build process.

[1] https://github.com/btford/ngmin