Why Angular 2 (4, 5, 6) sucks
Oh my gosh, such a clickbait title! But trust me, there are still a few valid points.
Angular team, I would like to thank you for the three years you spent on making the new and shiny Angular 2.0. But your new framework sucks. And I’ll tell you why.
I made a dozen of apps with Angular 1.x. Big ones like GoAbout website or real small ones like Sporteventa landing. I fell in love with Angular 1.x.
However, there is a very simple principle that I follow in all of my projects. The principle says:
Keep it simple, Stupid.
And that’s exactly where the new Angular has failed in so many ways.
Even though the learning curve for Angular 1.x was not ideal, the framework itself
was something more or less straightforward. It did not require TS, HTML compiler, CLIs, specific structure, webpack, Tree shaking, AOT compilation, and so on.
It just worked.
I was able to insert a bare angular.min.js in the file and start writing the code right away (even though I still used Gulp to livereload/build the app).
The whole idea behind a good framework is that you start with the simple stuff and make it more complicated only when you want it to be. The Angular team went in a completely opposite way.
Let’s discuss why Angular 2 is overly complicated in details:
1. It is written in Typescript
Don’t get me wrong, Typescript adds cool features to Javascript such as (obviously) types and much more. But do I actually need it? I’m not writing a software for NASA — I’m writing web apps, and I would like to be the one who decides what language I use. Not you. If I want to use TS, I will use it. But what If I simply wanted to make a simple prototype app where I don’t need TS?
Javascript became so popular because it was simple to learn, but with Types/Interfaces/Decorators, you're making it way too complex. Now I need to learn
more, to have an IDE for checking errors, and a compiler to make it JavaScript again. You made a Java out of Javascript.
P.S. I know that I can still kind of use JS with it. But in reality, it becomes close to impossible because I would have to deal with the fact that everything else around Angular is made with TS (like plugins or docs).
2. Angular-made HTML is not a valid HTML anymore
Just think about this next sentence: Angular 2 team had to write a compiler to
compile “Angular HTML” into HTML because some of the tags Angular uses are not
valid HTML.
No, that compiler does not make HTML more readable — Jade (aka Pug) does. The only purpose of the compiler is to change Angular tags into something more valid and to (also) add a bunch of garbage into your final HTML.
That's not it. The compiler gives an insanely useless traceroutes, if you ever have an error in HTML, well...good luck finding it. Oh, and should I add, the whole app won’t start until you find that mistake.
Also! You're no longer allowed to use Jade (Pug) in your new projects because, as I mentioned before, the HTML you write for Angular would not be valid for Pug (Jade) to compile it in github issue.
3. Angular takes an infinity to hot-reload your code
The thing I love the most about JS apps is that I can change a piece of code and see the results immediately in my browser.
With Angular 2.0, that is not true. Not anymore. I have a very powerful quad-core laptop and it still takes me 3–5 seconds to re-compile an empty Angular app. For already developed apps like ng2-admin, it takes roughly 10–12 seconds. You gotta be kidding me right?
Using our good old Angular 1.0 and a simple Gulp setup, I was able to concat all my code and reload the page in half a second.
The webpack configuration of Angular 2.0 is 300 lines long. It is so big and unreadable they had to make a separate config for a config. Nice, right?
4. Huge size of the initial app
This is something everyone has been moaning about for awhile now. Bare Angular 2.0 (+RxJS) weights around a megabyte. Yes, a megabyte. It is like 6 times more than previous Angular apps and 10 times more than what I expect my users to download over a 3G connection.
I know that Angular 4.0 will be smaller and I know that you can use Tree Shaking and
ahead-of-time compilation to make it smaller up to 3–5 times. But still.
Think about it. The initial Angular code was so big and complicated the team had to make it even more complicated just to make the code smaller! In other words, React and old Angular were both small enough that the team didn't have to deal with all these additional optimization techniques.
I can continue to add to the list but I think I’ve made my point.
Conclusion
Angular 2 is not that bad. It is completely modular, follows specific structure, uses types, and (in theory) allows you to write code with less errors.
But in my opinion, things should stay as simple as possible. Angular is far from simple. It just seems overly complicated.
I make web applications, not software for spaceships. The Angular team has introduced so much added (and unnecessary) complexity, which means:
- There are significantly more failure points. With the not-so-helpful traceroutes, Angular 2 becomes a headache that causes developers to waste their precious time.
- It is hard to adjust the framework for specific needs. Developers might start to fight the framework instead of writing the actual code.
- It has an extrememly steep learning curve. Sometimes I work with much less experienced developers — I want them to be able to make changes without going through 200 tutorial videos.
Would I need all these complexities in my small private projects? Ehm, probably
not. In my company’s medium-sized projects? No, I don’t think so. In a big enterprise-sized apps where 10 teams are working on the same app? Yes, maybe all of these complexity/modularity/precompilation would be good things to have. But then again,if these teams decide to use other frameworks, they might not need so many people in the first place 
I would be more understanding if it was impossible to make a good and stable webapp without all the complexities. But as we all know, it is possible and evit's a lot easier to make good apps without all the complexities. Just take a look on other frameworks like Aurelia, Vue.js (my current favorite), or on something React-based.
This tutorial was originally posted by the author here. This version has been edited for clarity and may appear different from the original post.
I'm available for hire & tutoring! Check the details [here (https://artemgolovin.com) or give me a message through Codementor | Javascript, Angular.js, Vue.js, React, Adonis, Express and more
This is clickbait title and Angular is terrible cringe.
Oh my, such nonsense. At least you’ve admitted that its a complete click-bait title. First off, let’s talk about Typescript. Let’s be really clear about this, Typescript is just Javascript with some added features. Features, might I add, that enforce best practice across the board. So many projects i’ve worked on, where sub-standard developers come along and spend their time writing the most shocking, error-prone code, and get away with it, because JS allows them to.
Type inference is fine, huh? Yeah, tell that to all the NaN errors all over the place. So, enter Typescript… const myNumber: number; Great, now your IDE can tell you you’re wrong before I have to on your merge request, and make you feel stupid, because you’ve just been told for the nth time to more careful with your assignment.
Despite that, it’s not a case of ‘kinda’ being able to use JS interchangeably, it’s a case of you can. Simple. I mean, you shouldn’t, because you lose all the benefits of Typescript, but you can.
Aside from anything else, how you can consider it complicated is beyond me. In standard JS, I have a variable, that’s meant to be a number:
const myNumber = 1;
Fair enough, until someone tries to assign “1”. It compiles, but it’s wrong. What’s so complicated about:
const myNumber: number = 1;
I added one word. ONE word. (And a colon). It didn’t take my hours to figure it out, I knew it was a number, so I gave it a type.
Now Mr JuniorDev can’t come along and assign “1”. Many hours saved. It wasn’t complicated, and it forces devs to write correct code.
To address interfaces, do you need them? Maybe, maybe not. You don’t have to use them, but it makes for far more readable, and maintainable code if you do.
As for ‘Angular-HTML’, yeah, i’m not even gonna go there, because that’s ridiculous. Angular html is no more invalid than JSX. It’s rendered in the same way as React/Vue etc, but I don’t have to shoehorn my HTML into the same file as my logic, I can use a template file. That’s separation of concern right there. Oh, and tracing errors? Yeah, Angular tells you exactly what line and column your error is on, right there in the console. So, that’s that one debunked.
Onward!
Code reload takes an age? No, wrong again. Angular bundles with Webpack as standard, with HMR enabled, so it recompiles changes only, and reloads almost instantly. That said, if it were a second or two, and you use that as a reason to not choose a framework, then you really need to take a good look at your priorities.
And finally, AOT and Tree-Shaking. “I can use…”.
No sir. You should. Not can. SHOULD.
Why? Because, they’re not just for reducing bundle size, AOT identifies potential run-time errors at compile-time, so you can fix them before you go to production, and don’t have to have days/weeks/months of back and forth releases to fix them.
And tree-shaking, i’m sure an experienced dev like yourself knows, removes dead code all over the show, making the whole application more efficient and stable. But that complexity to remove complexity is terrible, right? Except that it’s done as standard with a production build, with NO additional input from you, other than passing a --prod flag, which you would be doing anyway.
Add into that the ability to create an application with lazy loaded modules, and (if you so wish), server side rendering, and you’ve got yourself a pretty damn fast TTFP, with a modular, maintainable and scalable application that follows best practice and SOLID principles.
But that’s bad, right? Because you’re only building webapps. Not a NASA application. And those web apps are never going to scale.
Fair enough, that’s your call.
Angular is a garbage. Even in google seo support is disaster. Im trying F** Universal for pre-rendering and stuck in SyntaxError: Unexpected token import
at createScript (vm.js:80:10)
Angular is simply a one BIG mistake.
Baron, that’s an issue with your implementation, not the framework. As it happens, Googles SEO support for SPAs is very good, and has been for quite a while.
Granted, server-side rendered will always have better SEO support, and that’s the point of Angular Universal. You can’t just summarily claim that something is ‘garbage’ just because of your poor implementation. I have implemented Angular Universal many times, with no issues.
I haven’t worked with many (any??) frameworks that give you a language choice! if you use Symfony or Laravel, for example, of course you use PHP. if you’d prefer ruby, then you get ruby on rails. Angular2+ has decided to use TypeScript, so that’s the language to learn and use. (the fact that it compiles/transpiles to JS is incidental/not-my-concern in the same way that the fact PHP compiles to some kind of bytecode is incidental/not-my-concern.)
Angular1 adds non-standard attributes to HTML, too. it’s fine. purity of HTML is not important, as long as the HTML produced runs on all the platforms (browsers) we care to support.
okay, I agree on this one :P for small projects, the hot-reload is fast, but the time ticks up slowly, but surely, as the project grows.
I don’t know why it’s not the default, but definitely “ng build --prod --build-optimizer”. it cut the file size from 3MB to 300KB for me. this is still bigger than if I wrote it from scratch in vanilla JS, without npm, of course, but it’s not unreasonable. as another comparison: writing your desktop apps in assembly would yield way smaller & faster applications than using C#, Java, etc, but no one wants to do that unless they have to, and fortunately, we have powerful computers, so don’t have to! we have the luxury of being able to trade resource footprints (memory, filesize, whatever) for faster dev time.