7 ms·

Why you should not use AngularJs

114 points by caisah 12y ago

coldcode 12y ago
While I have no direct experience with Angular (I used to do javascript but now iOS) the folks in the office using Angular seem testy all the time.
southpawgirl 12y ago
After ~1 yr of experience with Angular, I have to say I fully agree. Debugging is a pain, for a start, and so is delving into the source code. Plus, it's incredibly complex and opinionated and still it leaves it really easy to slip into really poor practices and untestable code (observe the complexity and verbosity of this best practice guide: https://github.com/mgechev/angularjs-style-guide https://github.com/mgechev/angularjs-style-guide). The real deal breaker is, however, performance in complex pages. I much prefer to write my own controllers and models and use Reactjs for the views.
exratione 12y ago
Takes all sorts. I put in some time at an office where the team struggled immensely with Ember but found Angular much easier to pick up and produce results with. The scaling thing is just one of the hurdles you have to manage in this framework. Every system has them. Once you learn where the limits are the tools exist to manage it: https://www.exratione.com/2013/12/considering-speed-and-slowness-in-angularjs/ https://www.exratione.com/2013/12/considering-speed-and-slow... Like all frameworks, Angular isn't suited to every task. If you are rendering massive tables, to pick the obvious example, then you probably shouldn't be using any of the modern binding-based frameworks for that part of your application.
snarfy 12y ago
I'll take a good library over a framework any day. Angular is a framework.
nsamuell 12y ago
While I'd be the first to agree that Angular does a bunch of things I think are a bit crazy, articles like this don't really move the needle for me. The author doesn't like the design of Angular and feels it isn't efficient enough. OK, that's OK! However, there's not some massive conspiracy here - go ahead, use React/Ember. In my own experience, Angular is performant enough for most web applications, and the convenience the framework offers makes up for a lot of the crazy, weird things it does to achieve that API. But to each his own.
- southpawgirl 12y ago
  "there's not some massive conspiracy here - go ahead, use React/Ember" I wish it were the case; whilst for my own projects I certainly follow such advice, I've found that in industrial settings Angular is seen like a framework that delivers quickly and "if you don't like it probably you don't understand it", and therefore trying to oppose its choice raises eyebrows ("ah you want to bill us more days", or "duh! our consultant wants us to make exotic||obsolete choices"), more than it triggers any objective discussion.
- woah 12y ago
  No conspiracy, just a bad choice by Google to throw a bunch of money and promotion at a substandard framework.
whoisthemachine 12y ago
I agree with your points, but I can say that I do not have the same hatred towards the framework as you do. It sounds like I should feel fortunate to have left that project after only a few months of working with Angular.
andrea_s 12y ago
In my experience, it's very easy to shoot yourself in the foot with Angular, performance-wise. But this is most often due to poor understanding of how the underlying update model works (people abusing deep watches would be a prime example). Of course, the generally poor documentation does not help newcomers...
santoriv 12y ago
I don't know if I agree with everything that this post says, but I do agree with the bit about two way data-binding being a problem. Two way data-binding definitely gives a "Wow that was easy" impression in a tutorial app or something not too complex, but once you get into the realm of a seriously complex app, it becomes an anti-pattern. You need to know which direction the data is flowing and in many situations there can not be two sources of truth that are always in sync with each other. I'm working with Ember and I'm really glad that they are moving away from using two way data binding by default.
hippich 12y ago
I am working on a large app based on angular (not my decision - I voted against it :)), and felt many pain points already, from poor design overall, to crappy extensions most of the currents apps are using. It Kinda reminds me whole Wordpress thing. Really subpar codebase - but at the same time very easy to make simple things, and as a result - a lot of popularity. And this comes not as surprise to see so many blog posts comparing Angular to jQuery... But perhaps this bothers me the most - https://www.youtube.com/watch?v=X0VsStcCCM8#t=745 https://www.youtube.com/watch?v=X0VsStcCCM8#t=745 Guy behind framework openly admits he did not really pay attention to what other frameworks were doing (and Ember used to be Sproutcore and went through similar observe-loop pains in the past.) He just transferred his Java-server-side-MVC experience ($scope/$context - these are very distinct server-side MVC concepts) as is to the browser, which, as turned out, not quite well suited for long living in-browser apps.. And then whole dependency/packaging mess. There were already solution and tooling in place for AMD - but he decided to reinvent it, and as a result integrating any serious building process is a pain (i am not talking about 1 page apps here, i am talking about apps with 10Mb of JS code bases.) While this all workable, and this is what I do at my day job, this should not be necessary. I call it "bullshit job" just like many "create report" type of jobs - where no real value is created. If you know 100% that your app will never grow outside small prototype - go for it, otherwise either have plan in place to redo your app in sane framework, or do your app in sane framework from the start.
- marcofiset 12y ago
  What would be a sane framework? Every one of them seems to have many pain points, and every other developper tells you should use X instead of Y because Z.
  - jbeja 12y ago
    Purescript.
    - lomnakkus 12y ago
      Purescript is a language, not a framework.
andrew_wc_brown 12y ago
I am building larges scale web-apps with AngularJS and I have no issues with debugging or performance that I need to move to another framework. Once you know the paint points of any framework you work around them.
SideburnsOfDoom 12y ago
In the section on minification; > When you minify your code, it stops working, since variables are injected by name. ... You have to use this syntax ... We didn't have that problem. Or rather we did until we reaised that the minification tooling can convert it automatically. The author does not know that his problem is not a problem any more as it has already been solved.
- riffraff 12y ago
  FWIW, newish versions of angular can be set to explode in your face if you use the shortened syntax even when unminified using "ng-strict-di" which I suggest everyone to use.
afarrell 12y ago
> There is a fundamental rule in programming, it relates to absolutely any technology or language, this rule says that explicit is always better that implicit. Is this a fundamental rule? I thought it was something highly valued by python culture but not by, say, ruby on rails.
- eatonphil 12y ago
  "Explicit" ties in to readability and from there, long-term support-, maintain-, and debug-ability. While OP did issue a blanket statement, this idea is fairly language/framework independent.
  - yxhuvud 12y ago
    Yes, but it still isn't that clear cut. IMO and generally speaking, implicit is better when there is an obvious default behaviour that should be used in most cases. It may still be necessary to be able to override that default behaviour, but having to restate the obvious everywhere is not something that is good or desirable for the points you mention, since it will only make it harder to see what the differences are compared to the common case. Of course, not all problems have default solutions and those should usually not have default behaviours. To be honest, I'd rather state the rule as following when designing an API: "Do the obvious thing". Sometimes that will involve explicitness, and sometimes it will involve implicitness, but almost always it will be a mixture where some aspects are explicit and some things are implicit. The hard part is figuring out what should be which.
    - afarrell 12y ago
      The problem is that the "obvious thing" relies on implicit knowledge of whoever is designing the API and might be nonobvious to someone else.
- mackwic 12y ago
  I don't think so, check what ActiveSupport brings to ruby (http://guides.rubyonrails.org/active_support_core_extensions.html http://guides.rubyonrails.org/active_support_core_extensions...). TLDR: with RoR, things like `[1,2,3].third` or `foo.present?` is highly encouraged.
sergiotapia 12y ago
That's all fine but literally the #1 reason you should not use Angular is how the angular team tossed everything for version 2. How can you trust such a tool? Do you want to rewrite your applications when version 3 comes out? Whos to say thy want do the same thing come v3
scottu 12y ago
There sure are a lot 'Angular is Bad because...' articles out right now. Is it mainly because of the rewrite? I've begun using Angular for personal projects. At work we use CANjs. I like CANjs but I have to say it feels easier to become productive on AngularJS. For me productivity is most important. Regarding framework vs library. I heard more than one speaker at Fluent last year say that Angular was a library and not a framework like Ember. For me Angular seems pretty light weight compared to what else is out there. Maybe in a few months I'll feel different. For now I don't hate on Angular.
CSDude 12y ago
I am not a good front end developer, however I think something like Angular is very useful to a frontend noob like me, I remember my old Jquery days, it is much easier to write modular code in Angular. You just have a template, and its controller. Easy! (For not very complicated things ofc) It might be better in other frameworks, I agree the docs are somewhat confusing, I still confuse provider-service-factory however as I said, it simplifies most of my development, and my medium sized web app runs very smoothly with Angular
- exodust 12y ago
  "a frontend noob like me, I remember my old Jquery days," I'm not sure how a frontend noob can have "old jquery days"! Not sure a comparison with jquery is needed. They're different enough, or do some people actually consider using Angular a "step up from" Angular? That would be funny. Personally I prefer the cross browser/device performance benefit of jquery even for a medium sized app. Potential growth of the app's frontend needs can be met with jquery. It runs quick I've noticed even when it has a ton of work both initially and dynamically. I've thrown a lot at it, too much, and Jquery doesn't mind a high load of elements and updates, especially if you get your loading spinner graphics and display-timing sorted, complex pages can look quite smooth even on mobile. It wouldn't be wise to rule out a good performer like jquery.
Bahamut 12y ago
To be honest, this article is pretty poor, and even demonstrates the lack of understanding of Angular the author has. The databinding capabilities is said to be at 8000+ watchers now, although not all watchers are equal. A lot of performance improvements have been made since 2-3 years ago when that post was made about the watchers, which is where that oft poorly quoted 2000 watcher number originates from. The two way databinding complaints miss the mark - the point of them in directives was to mimic eencapsulation and what is now being known as the we component spec. Web Components are essentially what Angular directives were meant to be in absence of an official spec for browsers to implement. The point of two way databinding in inputs also are for encapsulating logic for each component. The comments about ng-cloak and ng-bind were also flat out incorrect. I think most of all, the author doesn't understand context - Angular was conceived during a different time for frontend, and at a different time with browser support. Five years is a long time to last in the frontend world currently, and that it will likely last at least 3 years more is surprising for a framework that has changed frontend development for the better overall. Angular is obviously not perfect, and the core team members are quick to point out flaws in approach, or solutions that were good at the time but don't make sense going forward due to changes in the browser environment or other technologies solving problems that Angular had to solve, such as with Object.observe, ES6 modules, and ES6 promises. I have built & architected many Angular apps over the past two years, some being very complex due to the problem space. I have found Angular to be perfectly suited to the task, and snappy to boot. I have seen very few perf problems where I could not fix them with a little work - the only one that was too difficult was dealing with editable tables with lots of data in older browsers (IE8 - 10), and I believe I could have tackled it, but I was playing more of an advisor role to another developer, and these sort of problems usually require the engineer working on the problem to understand the nuances of the code itself.
- adambratt 12y ago
  My thoughts exactly. There's nothing new or unique about this article that hasn't been brought up or debated before. Saying that data binding is wrong because it doesn't use click handlers for a button is kinda silly...Angular allows you to do that. I use ng-click all the time on buttons. $watch is for communicating between interdependent components not handling click events.
crazychrome 12y ago
never tried it. AngularJS gave me a strong feeling of j2ee, bold, tons of reinvetions of old concepts. most of all, the authors are from google which never shipped a high quality Js/browser based product. except the original gmail. the only problem i have with this article is: i wrote a hatre comment on angularjs about 8 months ago and got downvoted heavily, but this one just keeps earning points!
bahmutov 12y ago
Interesting post, not sure I agree that the points raised mean AngularJs is a bad choice. Consider first objection - two way binding. Not only there are user-space solutions (bindonce), but now there is standard one-way binding in ng v1.3. The Angular does nice job allowing simple interactive apps to be written in 30 minutes by anyone familiar with HTML and JavaScript. At the same time, if the app performs what is needed by the client, the app can be profiles, and each bottleneck can be optimized in a couple of steps. For example, we went through this process and described the steps we used in http://bahmutov.calepin.co/improving-angular-web-app-performance-example.html http://bahmutov.calepin.co/improving-angular-web-app-perform...
GUNHED_158 12y ago
Couldn't find any specific reason in this article to NOT use AngularJS! One can always talk about any framework like this. Good reasons to NOT use a framework might be: Lack of hope in future improvements, Inability to deliver the necessities, etc. AngularJS delivers and there is a lot of hope around it and that's exactly the reason people use ReactJS too. AngularJS is a very powerful framework and implements many of the common patterns in rich web applications. It has a learning curve which is normal, and poor documentation which is being improved day by day. Adopting AngularJS will result in less coding in the near future which in turn will result in less bugs and support. Therefore making it worth the learning curve.

114 points by caisah 12y ago

While I have no direct experience with Angular (I used to do javascript but now iOS) the folks in the office using Angular seem testy all the time.

southpawgirl 12y ago

After ~1 yr of experience with Angular, I have to say I fully agree. Debugging is a pain, for a start, and so is delving into the source code. Plus, it's incredibly complex and opinionated and still it leaves it really easy to slip into really poor practices and untestable code (observe the complexity and verbosity of this best practice guide: https://github.com/mgechev/angularjs-style-guide https://github.com/mgechev/angularjs-style-guide). The real deal breaker is, however, performance in complex pages. I much prefer to write my own controllers and models and use Reactjs for the views.

exratione 12y ago

Takes all sorts. I put in some time at an office where the team struggled immensely with Ember but found Angular much easier to pick up and produce results with. The scaling thing is just one of the hurdles you have to manage in this framework. Every system has them. Once you learn where the limits are the tools exist to manage it: https://www.exratione.com/2013/12/considering-speed-and-slowness-in-angularjs/ https://www.exratione.com/2013/12/considering-speed-and-slow... Like all frameworks, Angular isn't suited to every task. If you are rendering massive tables, to pick the obvious example, then you probably shouldn't be using any of the modern binding-based frameworks for that part of your application.

snarfy 12y ago

I'll take a good library over a framework any day. Angular is a framework.

nsamuell 12y ago

While I'd be the first to agree that Angular does a bunch of things I think are a bit crazy, articles like this don't really move the needle for me. The author doesn't like the design of Angular and feels it isn't efficient enough. OK, that's OK! However, there's not some massive conspiracy here - go ahead, use React/Ember. In my own experience, Angular is performant enough for most web applications, and the convenience the framework offers makes up for a lot of the crazy, weird things it does to achieve that API. But to each his own.

southpawgirl 12y ago
"there's not some massive conspiracy here - go ahead, use React/Ember" I wish it were the case; whilst for my own projects I certainly follow such advice, I've found that in industrial settings Angular is seen like a framework that delivers quickly and "if you don't like it probably you don't understand it", and therefore trying to oppose its choice raises eyebrows ("ah you want to bill us more days", or "duh! our consultant wants us to make exotic||obsolete choices"), more than it triggers any objective discussion.
woah 12y ago
No conspiracy, just a bad choice by Google to throw a bunch of money and promotion at a substandard framework.

whoisthemachine 12y ago

I agree with your points, but I can say that I do not have the same hatred towards the framework as you do. It sounds like I should feel fortunate to have left that project after only a few months of working with Angular.

andrea_s 12y ago

In my experience, it's very easy to shoot yourself in the foot with Angular, performance-wise. But this is most often due to poor understanding of how the underlying update model works (people abusing deep watches would be a prime example). Of course, the generally poor documentation does not help newcomers...

santoriv 12y ago

I don't know if I agree with everything that this post says, but I do agree with the bit about two way data-binding being a problem. Two way data-binding definitely gives a "Wow that was easy" impression in a tutorial app or something not too complex, but once you get into the realm of a seriously complex app, it becomes an anti-pattern. You need to know which direction the data is flowing and in many situations there can not be two sources of truth that are always in sync with each other. I'm working with Ember and I'm really glad that they are moving away from using two way data binding by default.

hippich 12y ago

I am working on a large app based on angular (not my decision - I voted against it :)), and felt many pain points already, from poor design overall, to crappy extensions most of the currents apps are using. It Kinda reminds me whole Wordpress thing. Really subpar codebase - but at the same time very easy to make simple things, and as a result - a lot of popularity. And this comes not as surprise to see so many blog posts comparing Angular to jQuery... But perhaps this bothers me the most - https://www.youtube.com/watch?v=X0VsStcCCM8#t=745 https://www.youtube.com/watch?v=X0VsStcCCM8#t=745 Guy behind framework openly admits he did not really pay attention to what other frameworks were doing (and Ember used to be Sproutcore and went through similar observe-loop pains in the past.) He just transferred his Java-server-side-MVC experience ($scope/$context - these are very distinct server-side MVC concepts) as is to the browser, which, as turned out, not quite well suited for long living in-browser apps.. And then whole dependency/packaging mess. There were already solution and tooling in place for AMD - but he decided to reinvent it, and as a result integrating any serious building process is a pain (i am not talking about 1 page apps here, i am talking about apps with 10Mb of JS code bases.) While this all workable, and this is what I do at my day job, this should not be necessary. I call it "bullshit job" just like many "create report" type of jobs - where no real value is created. If you know 100% that your app will never grow outside small prototype - go for it, otherwise either have plan in place to redo your app in sane framework, or do your app in sane framework from the start.

marcofiset 12y ago
What would be a sane framework? Every one of them seems to have many pain points, and every other developper tells you should use X instead of Y because Z.
- jbeja 12y ago
  Purescript.
  - lomnakkus 12y ago
    Purescript is a language, not a framework.

andrew_wc_brown 12y ago

I am building larges scale web-apps with AngularJS and I have no issues with debugging or performance that I need to move to another framework. Once you know the paint points of any framework you work around them.

SideburnsOfDoom 12y ago

In the section on minification; > When you minify your code, it stops working, since variables are injected by name. ... You have to use this syntax ... We didn't have that problem. Or rather we did until we reaised that the minification tooling can convert it automatically. The author does not know that his problem is not a problem any more as it has already been solved.

riffraff 12y ago
FWIW, newish versions of angular can be set to explode in your face if you use the shortened syntax even when unminified using "ng-strict-di" which I suggest everyone to use.

afarrell 12y ago

> There is a fundamental rule in programming, it relates to absolutely any technology or language, this rule says that explicit is always better that implicit. Is this a fundamental rule? I thought it was something highly valued by python culture but not by, say, ruby on rails.

eatonphil 12y ago
"Explicit" ties in to readability and from there, long-term support-, maintain-, and debug-ability. While OP did issue a blanket statement, this idea is fairly language/framework independent.
- yxhuvud 12y ago
  Yes, but it still isn't that clear cut. IMO and generally speaking, implicit is better when there is an obvious default behaviour that should be used in most cases. It may still be necessary to be able to override that default behaviour, but having to restate the obvious everywhere is not something that is good or desirable for the points you mention, since it will only make it harder to see what the differences are compared to the common case. Of course, not all problems have default solutions and those should usually not have default behaviours. To be honest, I'd rather state the rule as following when designing an API: "Do the obvious thing". Sometimes that will involve explicitness, and sometimes it will involve implicitness, but almost always it will be a mixture where some aspects are explicit and some things are implicit. The hard part is figuring out what should be which.
  - afarrell 12y ago
    The problem is that the "obvious thing" relies on implicit knowledge of whoever is designing the API and might be nonobvious to someone else.
mackwic 12y ago
I don't think so, check what ActiveSupport brings to ruby (http://guides.rubyonrails.org/active_support_core_extensions.html http://guides.rubyonrails.org/active_support_core_extensions...). TLDR: with RoR, things like `[1,2,3].third` or `foo.present?` is highly encouraged.

sergiotapia 12y ago

That's all fine but literally the #1 reason you should not use Angular is how the angular team tossed everything for version 2. How can you trust such a tool? Do you want to rewrite your applications when version 3 comes out? Whos to say thy want do the same thing come v3

scottu 12y ago

There sure are a lot 'Angular is Bad because...' articles out right now. Is it mainly because of the rewrite? I've begun using Angular for personal projects. At work we use CANjs. I like CANjs but I have to say it feels easier to become productive on AngularJS. For me productivity is most important. Regarding framework vs library. I heard more than one speaker at Fluent last year say that Angular was a library and not a framework like Ember. For me Angular seems pretty light weight compared to what else is out there. Maybe in a few months I'll feel different. For now I don't hate on Angular.

CSDude 12y ago

I am not a good front end developer, however I think something like Angular is very useful to a frontend noob like me, I remember my old Jquery days, it is much easier to write modular code in Angular. You just have a template, and its controller. Easy! (For not very complicated things ofc) It might be better in other frameworks, I agree the docs are somewhat confusing, I still confuse provider-service-factory however as I said, it simplifies most of my development, and my medium sized web app runs very smoothly with Angular

exodust 12y ago
"a frontend noob like me, I remember my old Jquery days," I'm not sure how a frontend noob can have "old jquery days"! Not sure a comparison with jquery is needed. They're different enough, or do some people actually consider using Angular a "step up from" Angular? That would be funny. Personally I prefer the cross browser/device performance benefit of jquery even for a medium sized app. Potential growth of the app's frontend needs can be met with jquery. It runs quick I've noticed even when it has a ton of work both initially and dynamically. I've thrown a lot at it, too much, and Jquery doesn't mind a high load of elements and updates, especially if you get your loading spinner graphics and display-timing sorted, complex pages can look quite smooth even on mobile. It wouldn't be wise to rule out a good performer like jquery.

Bahamut 12y ago

To be honest, this article is pretty poor, and even demonstrates the lack of understanding of Angular the author has. The databinding capabilities is said to be at 8000+ watchers now, although not all watchers are equal. A lot of performance improvements have been made since 2-3 years ago when that post was made about the watchers, which is where that oft poorly quoted 2000 watcher number originates from. The two way databinding complaints miss the mark - the point of them in directives was to mimic eencapsulation and what is now being known as the we component spec. Web Components are essentially what Angular directives were meant to be in absence of an official spec for browsers to implement. The point of two way databinding in inputs also are for encapsulating logic for each component. The comments about ng-cloak and ng-bind were also flat out incorrect. I think most of all, the author doesn't understand context - Angular was conceived during a different time for frontend, and at a different time with browser support. Five years is a long time to last in the frontend world currently, and that it will likely last at least 3 years more is surprising for a framework that has changed frontend development for the better overall. Angular is obviously not perfect, and the core team members are quick to point out flaws in approach, or solutions that were good at the time but don't make sense going forward due to changes in the browser environment or other technologies solving problems that Angular had to solve, such as with Object.observe, ES6 modules, and ES6 promises. I have built & architected many Angular apps over the past two years, some being very complex due to the problem space. I have found Angular to be perfectly suited to the task, and snappy to boot. I have seen very few perf problems where I could not fix them with a little work - the only one that was too difficult was dealing with editable tables with lots of data in older browsers (IE8 - 10), and I believe I could have tackled it, but I was playing more of an advisor role to another developer, and these sort of problems usually require the engineer working on the problem to understand the nuances of the code itself.

adambratt 12y ago
My thoughts exactly. There's nothing new or unique about this article that hasn't been brought up or debated before. Saying that data binding is wrong because it doesn't use click handlers for a button is kinda silly...Angular allows you to do that. I use ng-click all the time on buttons. $watch is for communicating between interdependent components not handling click events.

crazychrome 12y ago

never tried it. AngularJS gave me a strong feeling of j2ee, bold, tons of reinvetions of old concepts. most of all, the authors are from google which never shipped a high quality Js/browser based product. except the original gmail. the only problem i have with this article is: i wrote a hatre comment on angularjs about 8 months ago and got downvoted heavily, but this one just keeps earning points!

bahmutov 12y ago

Interesting post, not sure I agree that the points raised mean AngularJs is a bad choice. Consider first objection - two way binding. Not only there are user-space solutions (bindonce), but now there is standard one-way binding in ng v1.3. The Angular does nice job allowing simple interactive apps to be written in 30 minutes by anyone familiar with HTML and JavaScript. At the same time, if the app performs what is needed by the client, the app can be profiles, and each bottleneck can be optimized in a couple of steps. For example, we went through this process and described the steps we used in http://bahmutov.calepin.co/improving-angular-web-app-performance-example.html http://bahmutov.calepin.co/improving-angular-web-app-perform...

GUNHED_158 12y ago

Couldn't find any specific reason in this article to NOT use AngularJS! One can always talk about any framework like this. Good reasons to NOT use a framework might be: Lack of hope in future improvements, Inability to deliver the necessities, etc. AngularJS delivers and there is a lot of hope around it and that's exactly the reason people use ReactJS too. AngularJS is a very powerful framework and implements many of the common patterns in rich web applications. It has a learning curve which is normal, and poor documentation which is being improved day by day. Adopting AngularJS will result in less coding in the near future which in turn will result in less bugs and support. Therefore making it worth the learning curve.