I have dived into AngularJS a bit to find out why everyone is talking about it. The fact that Misko Hevery has his hands in it is probably a point in its favor, but I never got the time to experiment with front end libraries since I live in the back end.
I'm still in an early part of the learning curve, playing with about controllers and directives, but here are my first impressions and how I approached my study.
I am following the wonderful A Better Way to Learn AngularJS , which links particular chapters of the official documentation and Egghead videos (a screencasts series). The guide explains why each new concept is important and provides a series of boxes to tick when you have finished to read each link or watched the videos.
Learning a library from its documentation is much more difficult: due to the curse of knowledge the information contained is written and reviewed through the lens of experts. You're probably better off with this kind of external guides written by developers who have followed the same road you're taking now (although the information contained in official documentation can be more accurate at times, especially with boring topics such as version differences and browser peculiarities such as IE 7 requiring a special form for the ng-app directive).
What strikes me is that Angular introduces several higher level abstractions, and forces them onto the programmer without excessively pinning down your code with dependencies. For example:
- When it comes the time to approach more complex concepts such as transclusion, it's clear the developers have encountered these problems time and again in the past and have thought up a reusable solution (even giving it a fancy name, which is necessary to easily talk about the problem).
The approach followed is declarative as much as possible, but there is a clear separation and API between the engine and the components that can be plugged in. In other frameworks you learn that there is a Grid or Form component first, and when you need some tabs they have either to be provided by the framework itself or you're screwed. In Angular you learn the API of the directives engine first, and after that you can look at existing implementation of directives and decide if you like them or if you need to write your own.
(This comparison is not totally fair because Angular does not provide front end components like Ext JS and such.)
Forget about the tools ... buy a decent book and type in the programs by hand. One at a time thinking as you go. After 30 years you will get the hang of this and be a good programmer. -- Joe Armstrong
I can't stress this enough: go and build something with a new tool, even if you throw away it afterwards. Going through the motions of picking up the library code, writing some of your own and running/debugging it in the browser will make what you learn stick in your mind.
Perosnally, I built a cat generator with infinite scrolling that generate new cats selecting their names from a long array and their photo from an external API (nothing fancy). This simple example forced me to learn directives, controllers and some basic usage of the scope; at the same time, it gave me a goal which is more motivating that making two "foo:, bar:" forms talking with each other.
Angular is focused and humble: the documentation itself tells you to build CRUD screens, not application in need of huge customizations such as WYSIWYG editors or browser games. It augments your toolbox providing an engine and several patterns to build components on top of it.
Two-way binding is a fundamental feature of Angular, but it's difficult to get it right due to the plethora of events generated by browsers that have to be reconciled (I found a bug in the online examples of Angular that happened on pressing backspace twice in a modern version of Firefox within minutes.) That said, it will definitely make your life easier to have this feature extracted inside the framework instead of having to wire all events manually.