Angular 4: a Great CLI and a Treat for TypeScript Enthusiasts

Recently, I’ve dived into Angular more deeply, that is I’ve created a relatively straightforward project using Angular as the center of the technology stack.
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 CLI
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.
TypeScript
I must admit that I’ve always been very skeptical of TypeScript. Frankly speaking, I’ve never seen a case where it may be superior to plain JavaScript… yet Angular recommends (though doesn’t force it upon you) that you use TypeScript. Many tutorials and code examples are coded using TypeScript, and since my project was quite short, I decided to code in TypeScript. TypeScript wasn’t anything new to me, as I had some background in C#, so I didn’t have to learn a lot. I would lie if I were to tell you that TypeScript is perfect, because it’s not.
For instance, if you use the latest stuff (e.g. stuff that isn’t part of the official specification), you can encounter difficulties. Yet, usually, this is not the case, and there is a working solution/workaround available. What I love about TypeScript is that it’s very straightforward to keep your code fast. TS performs a type-checking, so if you don’t define many fields/arguments as optional, your code will look statically typed. It is easier to keep property access site monomorphic, and your feedback should match. Since I started to use WebStorm, where TypeScript is quite well handled, my efficiency has been higher in comparison to plain JavaScript.
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
Plenty of people compare Angular to React or React to Angular, but it’s a very unfair and plainly wrong comparison. React is just a library for creating views, while Angular is a full MVC framework with routing or network support built-in. React becomes powerful once you add third-party tools, but provides few features itself. I believe that Angular isn’t the most popular choice right now, but this may lead to improved code quality. Previously, when all the hype was on Angular, there was a tendency to learn Angular as the first step in one’s career. As a result, we had so-called ‘Angular devs’ with no knowledge of JavaScript. If you looked for tutorials, examples, or help about AngularJS, you could easily found a working code, but it could have been a terribly written solution. As of now, this might not be the case anymore. We would probably experience this phenomenon in the React world, which is producing lots of ‘React devs’.
Testing
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.
Conclusion
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!