I’ve been in love with Angular since its first beta versions. It just feels right and makes my life as a web developer a lot easier. When I talk with people who think that Angular is bad, I always try to learn why they think so. Every time I’m struggling to find any value out of these arguments. The most common arguments include statements like ”it forces usage of TypeScript and I hate TypeScript” and ”Angular templates are hard to grasp”. Sure, learning Angular templates requires some work, just like I can’t infer everything about React syntax without looking up all the oddities in it. At least Angular has a clear, consistent meaning for all the extra symbols within the HTML in the templates and there is actually only a handful of them ((click), [disabled], #nameInput, [@animationState], *ngFor).
But the most common thing, by far, I’ve heard is that it is such a massive monolith which enforces you to do things the certain, opinionated way. This is mostly a misconception by people who haven’t really bothered to look into it more carefully. Surely it contains pretty much everything you need to craft a modern web, mobile or desktop application. That is the sole purpose of it as a platform. It still does not mean it would be monolith, big or slow. In this blog post I’ll explain why this is the way I see it. Let’s take a look at the claims one by one.
Incorrect: Angular is massive monolith
Angular’s code is divided into many npm modules, named @angular/* where * is core, http, forms etc. There are more than ten of these available and you won’t be needing most of them for your basic web application.
Incorrect: Angular bundles are bloated
Angular comes with an extremely powerful compiler, that gets rid of everything included in those modules that isn’t used by your application. You don’t use Angular’s awesome animation API included in @angular/core? Fair enough, let’s drop everything related to it for you from the production build. Angular’s hello world is around 30kB and core team isn’t even nearly ready with all the optimizations with more improvements coming in pretty much every release. Take a application generated and built with facebookincubator/create-react-app as in comparison. If we run the production build with it, it totals to around 50kB. So Angular is not that massive in that sense either.
Incorrect: Angular is slow
No, it most certainly is not. Its change detection outperforms even React in many cases. Change detection is the process of detecting changes in data and reflecting them to rendered view. This is the comparable subset of Angular with React since React is just a rendering library. React requires explicit call to setState for its change detection to be triggered and then does a comparison with previous result which is called virtual DOM. This is quite efficient. Angular, on the other hand, builds on top of newer concepts such as usage of Zone.js for noticing possibility of changes that need to reflected on the view and then uses the advanced, virtual machine optimized change detectors to detect these changes. We hope to release some kind of more accurate benchmark about the actual performance soon. It is anyway clear already, that Angular does excellent job performance-wise too.
Incorrect: Angular doesn’t allow tweaking
It does, actually, to great extent allow tweaking. We are going to next have a look at the things that can and cannot be changed in Angular. As it turns out, even though Angular provides you with everything you need, it is still totally manageable by you.
Incorrect: Angular forces me to use TypeScript
Even though usage of TypeScript is highly encouraged in Angular development, you can also use JavaScript to develop your application just as easily. There is also a Dart version of Angular. So yes, you can use Angular even though you hate TypeScript because all you’ve seen about it are those horrors made by old-school Java developers.
Incorrect: I have to use opinionated and heavy Angular CLI
For bootstrapping an Angular project, there are many viable options built on top of different bundlers. The most used one is Angular CLI which is also recommended by the core team and will provide migration paths for future Angular versions. Other solutions such as angular/angular2-seed and mgechev/angular-seed also exist. Angular CLI utilizes Webpack under the hood, but does not yet allow tampering with it. Also angular/angular2-seed uses Webpack, but the mgechev/angular-seed builds on top of SystemJS. Nothing of course prevents you from using whatever you wish since it is just TypeScript (or JavaScript, if you wish).
Incorrect: Angular’s router sucks and I’m stuck with it
Router was the last piece of the puzzle missing for Angular during the development. It was rewritten two times, the second time being during the release candidate phase. This last router was based on the great work on the @ngrx/router and has been actually really good to use and has support for essential features such as lazy loading. But once again, there is no forcing power to use Angular’s default router. It is distributed as @angular/router and is completely separated from the core parts of framework like @angular/http. You can easily roll-out your own solution. So far, I haven’t heard any complaints about the router nor have I seen any alternatives available as libraries.
Incorrect: Angular’s state management can’t be altered
Angular provides some basic building blocks for sharing the state within your application. It does not enforce any convention, though. Kyle Cordes does great job on describing the different approaches available for managing state in Angular applications in his blog post titled Managing State in Angular 2 Applications. It starts with simple approaches such as sharing data between components, using services and using observables. Beyond those there are still the most interesting options such as using Redux (via library called ng2-redux) itself within Angular application and using the ngrx/store which combines Redux concepts with killer API of observables.
Incorrect: You have to use dependency injection pattern
Angular has really powerful dependency injection built-in. It makes your life as developer really easy and I personally don’t see a reason why not to use it. You can, though, skip it if that pleases you by creating your dependencies manually and then passing them around. There is also a library called injection-js that is an extraction of Angular’s dependency injection mechanisms. It can be used for React applications to implement Angular style dependency injection. See this blog post by its author, Minko Gechev, for more details and explanation.
Incorrect: Form handling needs to be done ”Angular way”
Angular provides powerful APIs for managing forms in applications. There are two simultaneous ways to work with forms called template-driven and model-driven approaches. These do indeed cause a lot of confusion among the newcomers and are in my opinion one of the hardest parts of Angular. Still, nothing enforces you to use them as they are completely optional with their own module called @angular/forms.
Incorrect: Angular is forcing me to use evil decorators
Many people see decorators as addition to list of evil features taking JavaScript into wrong direction. They are on that list right after classes that were already added in ES6. Decorators are not available in JavaScript yet, though a proposal for adding them is currently in the stage 2 and TypeScript already has a support for them. The fear itself araises again from the Java world (see @Annotatiomania). The decorators are after all only function calls that manipulate the class, function or property somehow. But you know what, if that is what you wish, you are completely free to do it your way. Just check these blog posts from Angular GDE Pascal Precht: Writing Angular 2 code in ES5 and Even better ES5 code for Angular 2. Not maybe the prettiest thing, but now there aren’t those terrible decorators laying here and there.
Incorrect: Angular can only render to DOM with its template system
Angular is actually browser and DOM independent. Why this is important is that it allows us to use any renderer we wish instead of the default DOM renderer. This isn’t just a theoretical possibility since there is already for example NativeScript which implements its own renderer for Angular applications to work with mobile layouts in mobile applications. One is also available for React Native.
Incorrect: I can’t use native CSS animations with Angular
Angular provides animation support as core part of the framework with the functions available in the @angular/core. It is a flexible system which makes creating animations easier than ever. It also allows unique way to bind the animations to state changes within the component by hooking it up with Angular change detection. This does not mean you couldn’t use any other mechanism to do your animations and to also utilize Angular’s change detection for your own purposes.
Incorrect: Angular forces me to use the terrible XLIFF format for localization
The most enterprisey thing in Angular in my opinion is the localization. It is implemented with verbose and ugly .xlf files and static compilation of language versions during AoT. I do prefer @ngx-translate with simple JSON structure and dynamic loading over the Angular way. Luckily I have the option here too.
Incorrect: HTTP requests are only possible with Angular’s HTTP library
Angular has a core module called @angular/http which is a great tool for making HTTP requests in Angular applications. There is, though, absolutely nothing that forces you to use this module. You can remove it from your package.json and replace it with something like SuperAgent or axios. You can even use jQuery if that pleases you more. After all, Angular uses the revolutionary Zone.js beneath the surface to get notified about the possible changes.
Incorrect: Angular forces me to do component-scoped CSS
By default all the CSS associated with component is scoped to apply only within this component’s template. This is again configurable to for example use Shadow DOM or act as global styles.
Incorrect: Data shown in views can only be altered with pipes
Pipes allow modifying data when shown. They have custom syntax with pipe character (|) followed by the pipe name and the possible parameters. Luckily, if you have problem with usage of these, you can always react for (pure?) functions to modify the data shown.
Conclusions
Because of the things listed here, I’m still having hard time realizing the critique since I can’t see it applicable at all to what Angular actually is. The way I see it, Angular is elegant, performant, easy to get started and maintainable. The main problems relate to ecosystem not being stable enough yet (Angular CLI, looking at you) and poor level of parts of documentation.
Feel differently? Please comment below! I’d love to understand the problems with Angular better.
