There are plenty of fairy tales about Angular, and some of them present Angular as pure evil. While there are some aspects I don’t like about AngularJS, Angular is much different. As you might see, I use various namings where AngularJS is the so-called Angular 1 and Angular is any major release that has come out after AngularJS. I’ve selected a few reasons that convinced me to become fond of Angular.
Less painful two-way data binding
Two-way data binding is known as one of the most awful and annoying aspects in AngularJS. At the time it was introduced, there were no Proxies. In order to have changes propagated, AngularJS authors had to implement a dirty-checking mechanism. Basically, dirty-checking periodically diffs a shape and values of an object. It can take an unknown period of time, which makes observing changes a headache, as you have to either set a watcher or set an interval on your own. In Angular, they still use dirty-checking due to backwards compatibility reasons, because there is no way to implement ES2015 Proxies in an ES5 environment. However, it’s handled better and isn’t so annoying anymore.
Angular project maintainers forked ember-cli and adjusted it to Angular’s needs. Since Angular has a different stack, some changes had to be made, but its commands are still very similar to those in ember-cli, so if you’ve ever used ember-cli, you will feel at home.
What I like most about those tools is that they enforce a project structure, so it’s trivial to switch between projects.
Angular-cli also comes with a test-runner based on Karma, which I appreciated a lot, because I needed a custom Chromium launcher.
CSS Modules as default
Each component written in Angular has a separate stylesheet bound to itself.
Zone-js which is bundled with the Angular package ensures that there is no style leak and makes your components very flexible and reusable. Of course, you are free to use the traditional approach (and sometimes you even should, if you need to style something globally), but each component has its own style by default. Although Angular is quite close to Web Components, Polymer seems to be a better choice, because Angular only mocks the Shadow DOM and some styles may still leak. Polymer is also maintained by Google and used on YT, and it does have a support for Shadow DOM, even for older browser. It doesn’t support it fully though, at it isn’t technologically possible.
It’s a framework, not a library
The difficulty level of testing depends on what you use – there are known problems regarding observables and other stuff. My use case in the project was very specific, and Karma – which is the default test runner when creating a project using a CLI – was more than a good choice.
I had to run my tests in a real browser, because I made a benchmark with a bunch of lower-level helpers that needed V8’s runtime methods to be exposed. In Karma, it was enough to create a custom browser launcher for Chromium where I could set the needed flag (js-flags=’--allow-natives-syntax’) as well as add Chromium in a headless mode, which eventually could make my tests perform quicker.
So to wrap things up, Angular may be worth a try if you need a solid and established framework, is maintained by a big organisation, i.e. Google. Some breaking changes are introduced from time to time to Angular, but the same applies to React’s ecosystem (for instance react-router), so the problem is not specific to Angular. On top of all its advantages, Angular is a truly lovely framework with an awesome CLI, so you can easily fall in love with Angular, especially when you originate from the Java/C# world. That said, when you are in the process of choosing an appropriate framework/library for your project, you should always consider your project’s specifics – there is no solution that fits all cases. Sticking to one library is really harmful, as you don’t evolve, don’t see any other ways to achieve the goal, and so on. Be wise in your choices!