It’s Flexible
It’s possible to take almost any portion of Angular and use it on its own. For instance, my front end may not need a full router with the ability to access a REST API. Maybe I just need a single two-way data binding on a single view and don’t want the overhead of a full framework. This is a possibility with Angular, but not with frameworks like Ember.
It’s Easily Testable
Angular was built from the ground with testing in mind. Angular’s use of dependency injection makes it easy to replace any functionality with a mock or stub. This makes it easier to test a very specific piece of the application, instead of the entire framework or app.
It’s Customizable
The other advantage of Angular’s dependency injection is the ability to replace any piece of the framework. Any moving piece of Angular can be replaced simply by dependency injecting a custom or third-party piece of code, instead of the pieces that ship with Angular.
It’s Easy to Learn
The learning curve on Angular is gentle. A programmer can start with just a handful of built-in directives and simple controller functions, and add on the more advanced bits as needed. Unlike frameworks that require conventions to operate, Angular lets developers pick their own conventions. This can potentially be a blessing and a curse, but it jives well with my particular learning and coding style.
Also, Angular does not require a separate data model; it can use plain old Javascript objects. This means that data retrieved from an external source (such as a server) does not have to be converted to an Angular-only model structure before Angular can start using it. There are no new data models and functionality to learn.
It Just Works
Despite Angular’s flexible and customizable nature, all of the pieces work well with each other. A controller can easily access the view, a view can easily save new data to the model through the controller, and routing is as simple as specifying a view, a controller, and a URL. The only part that has to be explicitly defined by the programmer is the interaction with the server/REST API. I actually view this as an advantage because not all problems lend themselves well to the GET/POST/PUT/DELETE pattern for a single resource. I often find myself needing just a single endpoint for a resource, and Angular allows me to make that decision.
For me, Angular is a framework that places an emphasis on modularity, an iterative learning approach, and fine-grain testing. As a Node developer, I feel at home while working with Angular. While there are always trade offs, and the Rails developer in me wants conventions and structure, I prefer being able to establish them for myself, rather than have someone else decide for me.
