

Ask HN: What's the problem with AngularJS? - someguy1233

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.
======
quadratini
Angular abstractions leak everywhere:
[http://stackoverflow.com/questions/18826320/what-is-the-
hash...](http://stackoverflow.com/questions/18826320/what-is-the-hashkey-
added-to-my-json-stringify-result)
[http://stackoverflow.com/questions/16935766/run-jquery-
code-...](http://stackoverflow.com/questions/16935766/run-jquery-code-after-
angularjs-completes-rendering-html) <\- "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.

~~~
JohnMunsch
\- 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.

~~~
quadratini
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.

------
jf22
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.

------
KukicAdnan
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.

------
skylark
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.

------
whichdan
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](https://docs.angularjs.org/guide/concepts)

------
hasenj
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).

------
y0ghur7_xxx
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.

~~~
iends
How is 1.x dead?

1.4 is going to be released in March.

~~~
y0ghur7_xxx
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](https://news.ycombinator.com/item?id=8961857)

[http://www.breck-mckye.com/blog/2014/12/the-state-of-
javascr...](http://www.breck-mckye.com/blog/2014/12/the-state-of-javascript-
in-2015/)

------
JohnMunsch
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....](http://www.google.com/trends/explore#q=angularjs%2C%20ember.js%2C%20backbone.js%2C%20reactjs%2C%20durandal%20js&cmpt=q&tz=)

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.

------
cmstoken
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.

