Ask HN: What's the problem with AngularJS?
Seems a lot of people here are starting to push it away for other technologies, mostly ReactJS which I struggle to see how the two frameworks are even alike.
14 comments
The problem with internet discussions is that the raw number of people who have informed opinions are low compared to the number of people who want to participate in a given discussion.
Because of this, many people end up parroting the ideas they've heard from others without having the proper context or nuance in their arguments that you would normally get through actual experience.
The truth of the matter is somewhere in the middle of "Angular.js is good" and "Angular.js is the second coming of Satan." That truth probably lies closer to "Angular.js is good" than the general consensus on the internet would lead you to believe.
At the end of the day, take internet opinions as just that - opinions, and try to form your own conclusions.
Because of this, many people end up parroting the ideas they've heard from others without having the proper context or nuance in their arguments that you would normally get through actual experience.
The truth of the matter is somewhere in the middle of "Angular.js is good" and "Angular.js is the second coming of Satan." That truth probably lies closer to "Angular.js is good" than the general consensus on the internet would lead you to believe.
At the end of the day, take internet opinions as just that - opinions, and try to form your own conclusions.
It's a framework, it tries to do everything, but it does a half-assed job at most of them.
It has its own module system, but it's half-assed.
Its architecture is a mess; not simple, not easy to understand.
So many people adopt it just because it's from Google, and then these people find themselves fighting with the framework and having to ask tons of questions, so you get these statistics that seem to imply "lots of people are talking about Angular", so more people jump on the bandwagon .. and so on.
Personally I recommend Knockout.js + Require.js + Durandal + rsvp.js (for Promises).
It has its own module system, but it's half-assed.
Its architecture is a mess; not simple, not easy to understand.
So many people adopt it just because it's from Google, and then these people find themselves fighting with the framework and having to ask tons of questions, so you get these statistics that seem to imply "lots of people are talking about Angular", so more people jump on the bandwagon .. and so on.
Personally I recommend Knockout.js + Require.js + Durandal + rsvp.js (for Promises).
The level of FUD here is astounding. AngularJS is not perfect, nor certainly are the major competitors. React seems to be dribbling out a piece at a time to us and each piece gets its own name and arrives in its own time. That makes it a little bit difficult to use as a framework. Hopefully it will all eventually jell and provide a really different take on how to build the front-end. I'd love it if there was a third choice with the same level of support behind it out there to give both of them a run for their money.
But this is reality here: http://www.google.com/trends/explore#q=angularjs%2C%20ember....
See those lines hugging the bottom of the chart? They're everything that isn't AngularJS and React. React is clearly on the uptick and AngularJS on the downtick for the partial Feb data they've got, but everybody else is in the noise level.
Yet people here would have you think:
1: It's old! - Really? 1.0 shipped in mid 2012. In three years we will have gone from 1.0 to 1.4 and some work done on 2.0.
2: It's going to change tomorrow when 2.0 comes out. - Really? Have you spoken to the other guy just above? He seems to think it's decrepit, you're worried that anything you build with it will have to be thrown away tomorrow because of its astounding rate of change.
3: Using the Chinese menu system of putting together a front-end framework is perfectly viable. Just pick something from columns A/B/C/D and throw it together and start using it. You'll find lots of people who can answer your questions, there are books written on that particular combo of tech, and there are developers out there by the hundreds you can hire who will have no problem diving right into your projects.
No. It doesn't really work that way. Pick an arbitrary grab bag of stuff and maybe you'll make some excellent choices. But you'll have to live with that decision for quite a while. Even a less popular stack like Ember.js is going to get more third party support than whatever you decide upon for yourself.
Above all, please do a quick experiment for me. The next time somebody tells you that AngularJS is a dead end and you can't rely on it for years to come, ask them what they would have recommended back in 2013? Just two years ago. What set of stuff would they have advocated then that would be doing so well today and have this long lived future into 2017+ that wasn't AngularJS? Backbone.js? I don't know of anything.
My point is this, the front-end and JavaScript tech is changing at a rate way too high for anyone's predictions about two and three years down the road to have a lot of merit. AngularJS seems like a reasonable bet to have done well and have lots of info available about migration from 1.X to 2.0 so at the moment I'm still on that path. In the meantime I hope to learn more about Facebook's stuff to see if it gives me useful ideas or to see if I can incorporate parts of it into AngularJS (Flux seems interesting for instance and would likely slide into most of the frameworks). But the people below who speak with such certainty about the future... Maybe they don't see it as clearly as they think.
But this is reality here: http://www.google.com/trends/explore#q=angularjs%2C%20ember....
See those lines hugging the bottom of the chart? They're everything that isn't AngularJS and React. React is clearly on the uptick and AngularJS on the downtick for the partial Feb data they've got, but everybody else is in the noise level.
Yet people here would have you think:
1: It's old! - Really? 1.0 shipped in mid 2012. In three years we will have gone from 1.0 to 1.4 and some work done on 2.0.
2: It's going to change tomorrow when 2.0 comes out. - Really? Have you spoken to the other guy just above? He seems to think it's decrepit, you're worried that anything you build with it will have to be thrown away tomorrow because of its astounding rate of change.
3: Using the Chinese menu system of putting together a front-end framework is perfectly viable. Just pick something from columns A/B/C/D and throw it together and start using it. You'll find lots of people who can answer your questions, there are books written on that particular combo of tech, and there are developers out there by the hundreds you can hire who will have no problem diving right into your projects.
No. It doesn't really work that way. Pick an arbitrary grab bag of stuff and maybe you'll make some excellent choices. But you'll have to live with that decision for quite a while. Even a less popular stack like Ember.js is going to get more third party support than whatever you decide upon for yourself.
Above all, please do a quick experiment for me. The next time somebody tells you that AngularJS is a dead end and you can't rely on it for years to come, ask them what they would have recommended back in 2013? Just two years ago. What set of stuff would they have advocated then that would be doing so well today and have this long lived future into 2017+ that wasn't AngularJS? Backbone.js? I don't know of anything.
My point is this, the front-end and JavaScript tech is changing at a rate way too high for anyone's predictions about two and three years down the road to have a lot of merit. AngularJS seems like a reasonable bet to have done well and have lots of info available about migration from 1.X to 2.0 so at the moment I'm still on that path. In the meantime I hope to learn more about Facebook's stuff to see if it gives me useful ideas or to see if I can incorporate parts of it into AngularJS (Flux seems interesting for instance and would likely slide into most of the frameworks). But the people below who speak with such certainty about the future... Maybe they don't see it as clearly as they think.
AngularJS is not a great framework. In fact, it's a horrible framework. You should really be using ReactJS. It's leagues ahead and much more robust. BTW, Angular is also getting old.
AngularJS is a fine framework. Like any technology it has it's positives and negatives. The biggest issue people seem to have with Angular at the moment is that the upcoming Angular 2 is a complete rewrite of the framework and the angular team isn't sure if there will be an upgrade path from the current versions.
I've used Angular for both prototyping and in large enterprise applications and it's served me well personally. It takes a bit to get used to the angular way of doing things but once you learn it - it's as good as any framework.
I've used Angular for both prototyping and in large enterprise applications and it's served me well personally. It takes a bit to get used to the angular way of doing things but once you learn it - it's as good as any framework.
Angular abstractions leak everywhere:
http://stackoverflow.com/questions/18826320/what-is-the-hash...
http://stackoverflow.com/questions/16935766/run-jquery-code-... <- "You might need this timeout to be sure its run after DOM render." wat
- You have to do everything the "angular way". Timeouts, intervals, http, modules, angular.toJson. It's a pain. Why can't I use the regular setTimeout, or ES6 or Common JS modules, or JSON.stringify?
- You end up having to dig inside the source code to debug issues with Angular.
- You basically HAVE to understand the digest cycle.
- Its way of doing templating is crippled in the sense that it's not as expressive as javascript.
- Honestly I think it's for people who doesn't like javascript and its ecosystem (npm).
React isn't alike angular because that's the point. React embraces javascript whereas Angular doesn't. If you want a http library use one of your choosing from npm, like axios. You want to use Common JS modules? Go ahead.
- You have to do everything the "angular way". Timeouts, intervals, http, modules, angular.toJson. It's a pain. Why can't I use the regular setTimeout, or ES6 or Common JS modules, or JSON.stringify?
- You end up having to dig inside the source code to debug issues with Angular.
- You basically HAVE to understand the digest cycle.
- Its way of doing templating is crippled in the sense that it's not as expressive as javascript.
- Honestly I think it's for people who doesn't like javascript and its ecosystem (npm).
React isn't alike angular because that's the point. React embraces javascript whereas Angular doesn't. If you want a http library use one of your choosing from npm, like axios. You want to use Common JS modules? Go ahead.
Angular.js is a framework, so it's no surprise that you have to understand how it works and use its idioms.
It's also batteries included, so it makes certain choices for you in exchange for cleaner integration. These are choices you have to make for yourself when using React. This is freedom at the cost of integration. Framework decisions always involve deciding on this tradeoff.
It's also batteries included, so it makes certain choices for you in exchange for cleaner integration. These are choices you have to make for yourself when using React. This is freedom at the cost of integration. Framework decisions always involve deciding on this tradeoff.
- The answer to why you have to use $timeout, $interval, etc. is simple. If you do it that way then AngularJS knows when you might have made a change in the scope and can look to see if there are updates to be made in the UI or watches to fire. It is a convenience system to avoid you having to tell the system that new data arrived from an earlier call to the web server and that you assigned it to a variable that also happens to appear in multiple spots on the page. React does not "embrace" that issue either. It does not magically know when to update itself on timer events or AJAX responses without some help.
P.S. You can absolutely use anything you like other than the provided wrappers. If you do, just call $apply() afterward. That's the signal to AngularJS that you changed something that might require it to do updates elsewhere.
- In two years of doing AngularJS work as a full time job (plus weekend projects) I have never ended up digging through the source code. Nor have any of the people working for me on my team at work. So the idea that you have to do that is patently false.
- I'm not sure how much is there is to understand about the cycle. It happens whenever events fire which indicate changes might have occurred. Later, when browsers directly support watching variables for change, I'm guessing there will be no need for it anymore.
- Hmm. The templating thing is an interesting way of thinking about it. Yes, it is crippled in one sense because it doesn't have the full expressiveness of JavaScript. I can see that. On the other hand it's elegant because you don't have to drop out of your HTML to do your templating work somewhere else using a completely different syntax or location. I think there are really good arguments to be made on both sides of this argument.
- Fascinating. Almost all of my AngularJS code is JavaScript. The portions of the code devoted to keeping AngularJS happy are a very small portion of the total. Based on what I've seen of 2.0 controllers, services, etc. are simply standard JavaScript objects so it seems a hard argument to make that they aren't fully embracing JS.
- And the final argument is one of my favorites. I've seen it over and over again, "Don't use a framework at all! Cobble together your own thing out of best-of-breed pieces to make a system." That may work well for an individual (though I think it will not) but for a team?!? No way.
I'm not anti-React or anti-Ember, but I am anti-throw something together based on intuition and try to use it to build something real.
P.S. You can absolutely use anything you like other than the provided wrappers. If you do, just call $apply() afterward. That's the signal to AngularJS that you changed something that might require it to do updates elsewhere.
- In two years of doing AngularJS work as a full time job (plus weekend projects) I have never ended up digging through the source code. Nor have any of the people working for me on my team at work. So the idea that you have to do that is patently false.
- I'm not sure how much is there is to understand about the cycle. It happens whenever events fire which indicate changes might have occurred. Later, when browsers directly support watching variables for change, I'm guessing there will be no need for it anymore.
- Hmm. The templating thing is an interesting way of thinking about it. Yes, it is crippled in one sense because it doesn't have the full expressiveness of JavaScript. I can see that. On the other hand it's elegant because you don't have to drop out of your HTML to do your templating work somewhere else using a completely different syntax or location. I think there are really good arguments to be made on both sides of this argument.
- Fascinating. Almost all of my AngularJS code is JavaScript. The portions of the code devoted to keeping AngularJS happy are a very small portion of the total. Based on what I've seen of 2.0 controllers, services, etc. are simply standard JavaScript objects so it seems a hard argument to make that they aren't fully embracing JS.
- And the final argument is one of my favorites. I've seen it over and over again, "Don't use a framework at all! Cobble together your own thing out of best-of-breed pieces to make a system." That may work well for an individual (though I think it will not) but for a team?!? No way.
I'm not anti-React or anti-Ember, but I am anti-throw something together based on intuition and try to use it to build something real.
It was a rhetorical question. I understand why we need to use a special version of setTimeout or a special HTTP module, but the fundamental problem is that Angular's "reactive javascript" abstraction leaks in a way that you're forced to do it the Angular way.
React's abstraction also leaks, which is evident when it doesn't automatically know to update itself so you have to call `setState`. But I'd choose this set of leaky abstractions over Angular's. Plus it makes it easy to spot all the places where the UI can change which is a huge plus for debugging. The beauty of React's set of abstractions is that it doesn't force you to do things a certain way (use $http, use $timeout) or use observables which embraces mutability.
Also to further my point that Angular (and any other framework that provides templating) doesn't embrace javascript, every time you use `ng-repeat` you're not doing javascript. You can't put a debugger in the middle of the loop to check the scope. You can't use Immutable-js because `ng-repeat` loves arrays. (Ok you can convert the immutable to an array before hand, but then when it changes you'd have to incur an expensive rerender of the list) You can't use static analysis tools.
React's abstraction also leaks, which is evident when it doesn't automatically know to update itself so you have to call `setState`. But I'd choose this set of leaky abstractions over Angular's. Plus it makes it easy to spot all the places where the UI can change which is a huge plus for debugging. The beauty of React's set of abstractions is that it doesn't force you to do things a certain way (use $http, use $timeout) or use observables which embraces mutability.
Also to further my point that Angular (and any other framework that provides templating) doesn't embrace javascript, every time you use `ng-repeat` you're not doing javascript. You can't put a debugger in the middle of the loop to check the scope. You can't use Immutable-js because `ng-repeat` loves arrays. (Ok you can convert the immutable to an array before hand, but then when it changes you'd have to incur an expensive rerender of the list) You can't use static analysis tools.
Angular is popular and anything that's popular gets criticized heavily.
Most of its criticisms are from people who don't fully understand angular and that's to be expected. Usually you can find issues with anti-angular rants that would apply to any javascript framework or large library.
Angular provides a very broad set of tools that takes a while to fully appreciate and learn. Of course React or Flux or something else will be "better" than angular at something or other because Flux and React are very specialized frameworks that do one thing very well.
Most of its criticisms are from people who don't fully understand angular and that's to be expected. Usually you can find issues with anti-angular rants that would apply to any javascript framework or large library.
Angular provides a very broad set of tools that takes a while to fully appreciate and learn. Of course React or Flux or something else will be "better" than angular at something or other because Flux and React are very specialized frameworks that do one thing very well.
I see no problem with Angular, but at the moment 1.x is dead tech, and 2.x is not here yet. So it's difficult to start a new project with Angular without feeling a bit nervous.
How is 1.x dead?
1.4 is going to be released in March.
1.4 is going to be released in March.
I would not use it for a new project now, if you know you will maintain that code for more than a few years.
https://news.ycombinator.com/item?id=8961857
http://www.breck-mckye.com/blog/2014/12/the-state-of-javascr...
https://news.ycombinator.com/item?id=8961857
http://www.breck-mckye.com/blog/2014/12/the-state-of-javascr...
For React, you should be comparing React + Flux to Angular.
The biggest problem with Angular is that it has a very steep learning curve, and writing bad Angular code is worse than writing bad jQuery soup.
- Using watchers/observers are encouraged, which makes control flow impossible to read for sufficiently complex pages. It effectively creates a potential side effect on any variable that can't easily be traced, and multiple watchers can casacade changes to eachother.
- Because of the way watchers/events work, Angular's digest loop implements a TTL, where it will keep evaluating watchers/events until there are no more changes, with a hard stop at $TTL+1. While this solves a lot of problems, it can make it very difficult to monitor state changes in the view, when a console.log/debugger/breakpoint will get triggered ten times as often as you'd expect.
- Angular has a lot of terminology[1], and each concept has its own set of idiosyncracies. When you combine this with the additional bootstrapping logic in Jasmine (and things like isolateScope), it ends up being very complex for a developer's first framework.
- Parent/Child relations in Angular are inferred from the structure of the DOM. This means you need to read your templates to figure out how your app is structured, and you'll end up with tight coupling unless you're diligent about your design decisions.
- It's very easy to let a lot of view logic slip into ng-bind and similar attributes. All of this logic should be extracted into objects and unit tested, but this means that a lot of the convenience of using Angular's declarative syntax end up being minimal at best.
- Like any framework -- expanding on what #quadratini said -- you need to use Angular's built-in libraries to do anything. While the syntax is reasonably similar, $timeout, $interval, $http, $q, etc all need to hook into the digest cycle, and this means you'll be wasting time figuring out when to call $apply or when to wrap a piece of code in $timeout just to get it to play nicely with Angular.
Angular is very powerful and not necessarily a bad framework, but based on my experience using it in a team environment for the past year and a half, unless everyone is senior-level at Javascript, you're going to quickly end up with a lot of hard to maintain, mediocre code.
[1] https://docs.angularjs.org/guide/concepts
The biggest problem with Angular is that it has a very steep learning curve, and writing bad Angular code is worse than writing bad jQuery soup.
- Using watchers/observers are encouraged, which makes control flow impossible to read for sufficiently complex pages. It effectively creates a potential side effect on any variable that can't easily be traced, and multiple watchers can casacade changes to eachother.
- Because of the way watchers/events work, Angular's digest loop implements a TTL, where it will keep evaluating watchers/events until there are no more changes, with a hard stop at $TTL+1. While this solves a lot of problems, it can make it very difficult to monitor state changes in the view, when a console.log/debugger/breakpoint will get triggered ten times as often as you'd expect.
- Angular has a lot of terminology[1], and each concept has its own set of idiosyncracies. When you combine this with the additional bootstrapping logic in Jasmine (and things like isolateScope), it ends up being very complex for a developer's first framework.
- Parent/Child relations in Angular are inferred from the structure of the DOM. This means you need to read your templates to figure out how your app is structured, and you'll end up with tight coupling unless you're diligent about your design decisions.
- It's very easy to let a lot of view logic slip into ng-bind and similar attributes. All of this logic should be extracted into objects and unit tested, but this means that a lot of the convenience of using Angular's declarative syntax end up being minimal at best.
- Like any framework -- expanding on what #quadratini said -- you need to use Angular's built-in libraries to do anything. While the syntax is reasonably similar, $timeout, $interval, $http, $q, etc all need to hook into the digest cycle, and this means you'll be wasting time figuring out when to call $apply or when to wrap a piece of code in $timeout just to get it to play nicely with Angular.
Angular is very powerful and not necessarily a bad framework, but based on my experience using it in a team environment for the past year and a half, unless everyone is senior-level at Javascript, you're going to quickly end up with a lot of hard to maintain, mediocre code.
[1] https://docs.angularjs.org/guide/concepts