What’s wrong with Angular 1

Daniel Steigerwald
Oct 6, 2014 · 3 min read

Update: It’s long time I wrote this article and now I would write it differently. Programming is hard and we all do mistakes. The hard thing for me is to express disagreement in friendly and helpful tone.

App logic and structure expressed in HTML, which is enchanting for beginners (Look’ma no JS, magic!), but terrible for real development. We are developers, we write and debug code. But Angular is HTML parser. I really don’t want to debug any string based parser instead of my code. HTML should be just a projection of app state, not a source of truth!

  1. Two way databinding is an anti-pattern. There are too much what-if situations. Binding from model to view is ok, but from view to model, it’s completely different story!
  2. Dirty checking, accessors (Ember and Backbone), Object.observe and all that stuff. Wrong! It’s slow and brittle and it will consume mobile battery like hungry dog for no reason. You don’t need it. Use Facebook Flux rather. Also, you should never model app data flow with several events spreaded over x classes, where everything listen everything. Be explicit.
  3. Duplicated app structure with obsolete angular.module. Almost for every app feature you have to 1) change HTML 2) change its controller.
  4. Angular is slow. And with dirty checking and HTML parsing always will be. You can’t fix broken design. Do I have to tell something about consequences for mobile web apps? I guess not.
  5. No server side rendering without obscure hacks. Never. You can’t fix broken design. Bye bye isomorphic web apps.
  6. Angular is hard to learn. It’s irony because Angular itself is promoted as easy framework for beginners. But it’s very complicated kind of easiness. You have to learn a lot of Angular specific patterns useful only in Angular world. Yeah, it’s result of bad design. This is both sad and ridiculous. Abstract layer can solve many problems, except problem of having too many abstract layers.
  7. Google does not use Angular in production for their flag apps like Gmail or Gplus.
  8. Vendor lock. And because Google does not use Angular in production, they can kill Angular anytime. You know that Google is still kind of agile company, not having a problem to kill any project despite it’s used by milions people.
  9. Will be rewriten entirely soon, which is a good thing for framework, but pain for you.

Not everything with Angular.js is bad and team behind it is brilliant. Vojta Jína did fantastic job with new DI container. Misko Hevery wrote awesome articles about TDD and writing testable code. And more.

But I suppose initial decisions were wrong therefore I consider Angular as dead end. Is Angular worth the risk? No.

Feel free to correct me.

Update 1: Almost everything I wrote is true also for Polymer. Maybe I should write an article: “What actually Polymer is, and should I use it?”. tl;dr: Polymer is integration point and tool for quick mashups. Not app architecture solution.

Update 2: The reason I wrote this article is because at my courses I have to unlearn people using Angular in the same way how Angular had to unlearn people using jQuery. Yes, we all were there, and now it’s time to move :-)

Update 3: What I would recommend instead of Angular.

Update 4: Another points of view:

Este.js dev stack

Robust and comfortable dev stack for isomorphic web apps

    Daniel Steigerwald
    Este.js dev stack
    Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
    Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
    Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade