Why Angular 2 (4, 5, 6) sucks
Artem Golovin

Though Angular certainly isn’t perfect I don’t agree with many of the opinions and consider some claims to be false or outdated. Overall I think Angular is heaps and bounds better and easier to learn than Angular.js, I honestly miss nothing from that framework and hope I never have to work with it again. Though small apps might be smaller in Angular.js I think they very quickly become a lot more bloated just due to the fact that lazy-loading is so hard to do with Angular.js. While Angular.js itself doesn’t necessarily become too big there are plenty of other big dependencies.

Nonetheless it’s interesting to see a different perspective. Here comes more specific feedback.

It is written in Typescript

Think the developer experience in general is much better with TypeScript even for smaller projects. And the types etc you actually need to learn to use Angular really isn’t that much imo.

It is at the very least a big improvement from Angular.js with how you created controllers, components, services etc. That was a mess of strings and duplicated variables you somehow needed to write and differed greatly depending on the build setup for your project.

Angular-made HTML is not a valid HTML anymore

Angular.js had a compiler in the same way that Angular has, it was just always in JIT mode, and was needed since Angular templates wasn’t really proper HTML either. Regardless I think Angular syntax is a lot better and more simpler in the way it’s tied to the DOM.

It is however true that error messages can suck, they could suck a lot in Angular.js as well though. And with Angular you can now catch some of the errors directly in your IDE.

Regardless some errors are still bad but looking at the recent ng-conf they presented a new version of the compiler, Ivy, which will both reduce the final output substantially and finally be able to give better error references directly to the template code.

Angular takes an infinity to hot-reload your code

This is indeed a real problem being worked on both on the Angular side, TypeScript side and Webpack side. Where the old gulp/grunt and npm script solutions definitely often used to be faster than the current solutions. One big caveat is however that we can’t have a lot of things with only gulp/grunt/npm scripts. We lose at the very least proper ES2015 modules, lazy-loading, latest JavaScript/TypeScript.

So I think this is a more inherent problem with the entire JavaScript ecosystem and not something you really can be without. If you have a really small project this is however not really a problem, at least not if you’re on the latest angular-cli, react-cli or whatever.

Hopefully all the current efforts can come together through webpack, typescript, babel and angular-cli or just through switching to bazel. Which scales linearly, or closer to linear but with a very hard configuration and lacking a lot of features inherent to Webpack.

Huge size of the initial app

Think that number is a bit lower for a completly empty Angular project with angular-cli, especially now 1 year after this was posted with angular-cli 1.7.x.

You however definitely very easily reach and cross 1 MB threshold and think this is definitely a pain the entire Angular and JS ecosystem is feeling. It is also something that’s definitely been improved through efforts accross the entire build chain and is going to at least continue to improve throughout this year as the new compiler, Ivy, rolls out. Which seems to be able to hit a 2.7 kB gzipped target with “hello world”.

Believe this will become radically better first with Angular 6, RxJS 6 and Webpack 4, which will be able to improve the tree-shaking of those libraries and other libraries that use ES2015 modules, like Lodash-es. While the new renderer, rolling out properly in 6.x or 7 later this year will be able to specifically reduce Angular by a lot.


Think a year ago I definitely would agree more with that the tooling was a bit too hard. However with angular-cli progressing and maturing to the degree it is today (angular-cli 1.7.x). I would instead now say that it’s easier than ever to create and maintain a small angular project.

At least now, you don’t necessarily need to understand the tooling anymore. I understand it as the tooling has matured enough to handle 90% of the use-cases (using the numbers from keynote day 3 at ng-conf). I can see this from our own workflow, where we used to require a webpack config that I spent a lot of time to maintain, but where we now have been able to rely on angular-cli and abstract the config a lot.