
Things that suck in AngularJS - sbarre
http://lhorie.blogspot.ca/2013/09/things-that-suck-in-angularjs.html
======
gkoberger
Documentation is by far the worst part of Angular. I spent 90% of my time
Googling and 10% writing code. (Hey, maybe that's Google's plan -- ramp up
traffic to search. Synergy!)

AngularUI is confusing, mostly undocumented and often behind Angular.
Splitting ngRoute/ngAnimate into their own files is an odd choice, although I
assume the former is so they can replace it with the superior ui-router. Which
also is weird. Like jQuery, it seems like the UI portion is just off on their
own doing what they want.

Google has the chance to build _the_ new framework that will run the web in
2-3 years. Much like Rails a few years ago. Angular is an amazing framework.
It seems like they just don't care.

Angular needs someone versed in developer usability to take control of the
public facing Angular stuff and give it a complete overhaul. Right now, it's
the result of hundreds of people haphazardly making changes.

~~~
camus2
> Google has the chance to build the new framework that will run the web in
> 2-3 years. Much like Rails a few years ago. Angular is an amazing framework.
> It seems like they just don't care.

People use to say that about ExtJS a few years ago , then BackboneJS, etc ...
There will never be one framework to rule them all , like Rails never ruled
server-side developpment, Rails influenced other frameworks. Likewise Angular
will , and something better than Angular will come by.

> Angular needs someone versed in developer usability to take control of the
> public facing Angular stuff and give it a complete overhaul. Right now, it's
> the result of hundreds of people haphazardly making changes.

that's how most open-source projects work. Angular is not a Google library,
Google already has closure[1] , which is neat and scales(ie great
performance,unlike Angular), Gmail is built on top of it , but strangely
nobody else but google is using it...

EDIT :

[1]
[https://developers.google.com/closure/library/](https://developers.google.com/closure/library/)

~~~
paultannenbaum
Maybe my understanding is wrong, but closure (and closurescript) are compiled
languages. Angular is a UI framework, so comparing them is apples to oranges.

And I think the Angular community would be thrilled if it had even close to
the kind of documentation that Rails has. You are correct, no one framework
will rule them all, but there are examples of OS projects that have good docs
(like jQuery and Rails) that can be used as comparisons when evaluating a
framework.

~~~
graue
You may be thinking of Clojure and ClojureScript — with a J. It's confusing
naming, but those are different, and are not Google products.

In this thread, we're talking about Google's Closure (with an S) Library.
Google also makes a Closure (with an S) Compiler, but it's more of an
optimizer — it "compiles" from JavaScript to optimized JavaScript.

~~~
chii
I would prefer to clear the confusion by calling Closure templates "soy
templates", and differentiate it from the Closure compiler (for compiling
javascript).

------
Nitramp
I agree with most of the things mentioned in the article, but here are a
couple of nits, just in case you have that exact problem and look for the fix:

$timeout having no $cancelTimeout: that's just called $timeout.cancel(),
taking the promise you got out of the initial $timeout call.

$.when is called $q in AngularJS, support for promises actually runs deep in
the framework.

Regarding the difficulty of instantiating controllers, and controlling who
publishes what on the $scope when: I think there should be a style rule that
you never, ever have some piece of JavaScript depend on the fact that some
other piece of JS adds a variable to its parent scope. Yes, that's global
state, or dynamic scoping, and should never be used. Just create a service if
you need two directives to communicate. This gets more obvious and easier with
1.2 and the controller-as style.

Bi-directional data binding should never get you into a loop if you take care
to only use the APIs in ngModelController. If you managed to trigger a loop,
you're probably using the wrong API - loops are something that can happen in
bi-directional data binding, but it's not a given.

This is not to say the author is wrong, as said above, I agree with most of
his points.

~~~
lhorie
Hi author here. Thanks for the feedback :)

re: instantiating controllers - services definitely help, but you still have
to design and expose APIs to manage the lifecycle of variables from the
controllers, and often times (at least for me), there are a lot of cross-
concerns and it becomes impractical to have services to deal with each
permutation of concern groups (this is especially a problem in more
exploratory projects). I should note that in the cases where maintainability
suffers the most, I have upwards of 5 core model entities and a dozen other
auxiliary ones being manipulated in a single page.

Also, when things need to persist across route changes, then you're pretty
much stuck to polluting $rootScope (or worse, $cookie)

re: "Bi-directional data binding should never get you into a loop if you take
care to only use the APIs in ngModelController"

Yes, they _shouldn 't_, but under some unexplainable circumstances they do,
even when I'm explicitly avoiding all the other undocumented traps (e.g.
isolated scope interop, etc). One very big weakness in Angular is internal
integration testing. Given enough moving parts, even simple things that should
just work start breaking in very strange ways (looking at you, ng-if).

~~~
anoncowherd
So why does Backbone.JS suck then? :)

------
dchuk
Shameless subreddit promotion: I (and the rest of the members) are trying to
submit every single worthwhile AngularJS article to
[http://www.reddit.com/r/angularjs](http://www.reddit.com/r/angularjs) so that
it becomes a solid place to keep up with AngularJS tutorials and guides.

So far we've almost doubled the subscriber-base in about 3 months so things
are finally starting to snowball a bit in terms of participation.

~~~
mcv
Why Reddit?

~~~
dchuk
I didn't start that subreddit actually, just became a mod a few months ago.
Reddit is easy for these types of things because so many coders are already
using it to browse other subreddits. I'd prefer it be its own site entirely
but this is working well for now so no need to mess with a good thing.

------
louthy
> I consider myself to be a reasonably good js developer, but the internals of
> AngularJS are overwhelmingly non-approachable.

Same here. I'm just getting up to speed with Angular. I spent the past weekend
developing a web-app to manage our internal test-process. I like it a lot, I
managed to create an incredibly complex and interactive web-app in two days.

Well, I say I like it a lot, I like the idea a lot: data driven mark-up,
separation of concerns, etc.

However when it goes wrong it's incredibly difficult to step through the
Angular code to work out what on earth is the cause of the issue.

It took me several hours of poking around trying to get this tree-view
directive to work:

[http://ngmodules.org/modules/angular.treeview](http://ngmodules.org/modules/angular.treeview)

First to try and work out why the directive wasn't being initialised, then why
the parameters were coming through with different names of the properties
compared to what the original source expected (ngTreeModel rather than
treeModel for example). Then, why on the inner elements of the tree the
properties coming through _were_ named as expected!

So exasperated I head over to the documentation for directives, and, yeah,
horrible... incredibly dry and terse.

I never quite got to the bottom of the issue, and have deferred working it out
until I know Angular a bit more (var treeId = attrs.ngTreeId || attrs.treeId).

But I can't deny that this thing is incredibly powerful, so I think it's worth
persevering with. But yeah, some better docs and up-to-date examples would be
very, very welcome.

EDIT:

I remember reading this a few months back. Now I get it...

[http://www.bennadel.com/blog/2439-My-Experience-With-
Angular...](http://www.bennadel.com/blog/2439-My-Experience-With-AngularJS-
The-Super-heroic-JavaScript-MVW-Framework.htm)

------
jowiar
Angular, when it feels right, makes me incredibly productive, but I feel like
I spend 90% of my time banging my head against a brick wall.

One of the single biggest usability features of anything is giving things
appropriate names. The "other half" of Karlton's law is well in effect here.
Angular fails miserably at this task. And that makes reading documentation, as
well as maintaining enough context in my head to be productive nearly
impossible.

From a documentation standpoint, the documentation focuses on "this is how
this function works internally" rather than "this is how you use it to produce
results".

I want to like Angular. So much of it feels right, and technically it seems
excellent. It really is a usability nightmare, though.

~~~
pavlov
_I feel like I spend 90% of my time banging my head against a brick wall._

Why do people want to work with a technology like that?

Personally I feel that the worst part of programming is when you're stuck
trying to decipher the inner workings of an intermediate layer. It's so
frustrating and futile, and I'm not learning anything generally useful because
mastering arcane workarounds for technology layer X doesn't translate to
anything else.

I'll much rather work with technology that doesn't make me feel magically
productive 10% of the time, but does make me actually productive 99% of the
time. There are plenty of those around.

~~~
jowiar
I agree. What I'm trying to determine is whether or not it's a rabbit hole
going down. Am I using a very powerful tool that's user interface is fine, but
takes a little bit of time to learn. Or am I using a very powerful tool that
has a user interface that's just bad. I'm honestly not sure - I haven't spent
enough time with it to tell.

And yes. A programming language or framework is/has a user interface.

------
eof
I've been doing (mostly backend) webwork for a living for about half a decade
now; the last ~6 months I have been building an app that is using angular.

I agree the documentation sucks; but beyond that I actually don't have any
complaints. I don't have anything to compare it to; but I have written _some_
JS over the years and what angular is doing is blowing my mind.

Because it blows my mind I find it hard to bitch or find fault. I _did_ have
to spend several hours stepping through angular core code to figure out WTF
was going on with $scope.$watch(); but again, I can't really say that $watch
_itself_ sucks; just that I had to read the code to actually understand how to
use it.

If I _had_ to pick something other than documentation to point at, I would say
that silent shadowing of non-object primitives when "new" scopes are creates
for things like ng-repeat and ng-if

------
gbadman
This is a good set of arguments explaining some challenging corners of
AngularJS.

It is true that when you start getting into the realm of edge cases,
substantial knowledge of the framework's internals is required to put together
a solution that is consistent with the 'zen of Angular'.

The author argues that some of the challenges introduced by Angular's $apply
lifecycle and its approach to two-way bindings make it a challenge to use in
certain circumstances. I would rephrase that and say that Angular's state-
tracking and two-way binding solution is a very elegant hack to a very complex
problem, considering limitations imposed by javascript, css and html. Angular
proposes a set of integrated solutions that allow developers to avoid a
substantial amount of boilerplate (and complex boilerplate, at that) for
synchronizing state and the view. As with every other framework, it is not
appropriate for every problem.

That being said, I continue to use and love Angular in a complex app with
quite a few moving parts. I migrated from Backbone.js about a year ago and
never looked back.

/x-post from Reddit:
[http://www.reddit.com/r/javascript/comments/1pdzbz/things_th...](http://www.reddit.com/r/javascript/comments/1pdzbz/things_that_suck_in_angularjs/)

------
rcconf
I found Angular to be overly complex and couldn't imagine training a team to
learn to use it in reasonable time. That's the scariest part of adopting
Angular for me. How would other coworkers adapt to the API and how long would
it take for them to use it?

The documentation was o.k at best, but I find that isn't the core issue. If
you take a look at
[http://docs.angularjs.org/guide/concepts](http://docs.angularjs.org/guide/concepts),
it takes a very long time to completely understand what's happening under the
covers.

I'm definitely looking for alternatives.

~~~
d0m
I disagree. I very like how the learning curve of angular follows my simple to
complex application features. What I mean is that it's very easy to get
started and hack you way through something that work, even if it's not 100%
angular best practices. I.e. putting jquery code in your controller. As you
become better and better, you start to have a better understanding of how
angular works and your code improves similarly. I think this is an amazing
quality for a framework. It reminds me how fun it was with jquery to get
started even if the code was terrible, and then improve from it as you learn.

For a newcomer to an angular project, they can simply read the html and have a
pretty damn good idea of what's happening. You don't have to start writing
directives and play with transclusion right away.

------
davexunit
The Angular docs are a ghetto. They really need to get rid of the Disqus
comments section. Also, I don't think it really helps that their docs are an
Angular application. I would really prefer a static html manual and an offline
version in pdf or info format.

------
general_failure
If you think angular docs are bad , you should try ember. Ember is so
frustrating. All answers on SO are out of date or wrong.

~~~
camus2
Ember creators cleary did not know where they were heading when they began
writing it.

AngularJS was influenced by Flex and Spry( the creator worked at Adobe ) from
the start, and still is.

~~~
flylib
Ember was heavily influenced by Sproutcore

~~~
davissorenson
Ember WAS Sproutcore, Sproutcore 2.0 is what became Ember.

Worth noting: Sproutcore was used to build iCloud, apparently.

~~~
flylib
that's what I thought, so clearly Ember wasn't written from Scratch

------
bearwithclaws
Been using (or, trying to use) AngularJS for the past 2 months.

The way to get around the bad documentation for me are sites like
[http://egghead.io/](http://egghead.io/) and
[http://thinkster.io/](http://thinkster.io/) (and of course, tons of SO-ing).

~~~
collyw
I tried these, and they explain all the components nicely, but don't explain
how to put everything together to get a mid to large scale app put together.

Maybe I just struggle as I am new to front end development, and to stuck in my
server side mindset.

------
rjaguayo
JQuery.when is similar to $q.all
[http://docs.angularjs.org/api/ng.$q](http://docs.angularjs.org/api/ng.$q)

------
Cthulhu_
So, a lot of people complain about AngularJS's documentation, not just this
article or the comments, but everywhere.

Does nobody see the bright 'Improve this doc' button at the top right or
something? It's an open source project - instead of complain, contribute! The
link immediately opens a github pull request for your convenience and you can
edit it in github's own editor.

Yeah, you could shift the blame to Google, but afaik, it's not one of their
supported products, but a 10% time product - meaning that the creators /
maintainers themselves can't work full-time on it either, and rely on the open
source community to help them out.

Go forth and fork.

~~~
lhorie
Improving docs is a bit of a chicken and egg problem: someone who's having a
hard time with the docs is not going to be able to help improve it.

------
flylib
Surprised the knock is bad documentation (The site is awful), but I have heard
that Angular has a lot better documentation then Ember currently does

~~~
scardine
Ember is still changing a lot, and some of the later changes are cleared
inspired by Angular.

Ember-data looks much better than anything in Angular. Ember has a bit too
much "convention over configuration" to my taste but the project is evolving
well; I would not say it is production-ready but is getting close, so keep it
under the radar.

------
adrianbg
My biggest pet peeve is how it suppresses errors in inline expressions.

~~~
antihero
Fucking hell. I do like AngularJS, but everything to do with expressions
pisses me off. Fairly incoherent documentation, combined with lack of errors
or any sort of meaningful way to debug them.

~~~
troyk
No doubt, care to share how you feel about $scope inheritance?

------
woah
Can't google just hire an intern to update the documentation? C'mon guys, it
would likely be the very cheapest and most effective thing they could do at
this point.

~~~
nailer
Angular has 'from Google' written on it, but it's not a Google-created
project. They make no money from it, and Closure's way more popular inside
Google.

They'd hire an intern to fix Closure bugs.

------
atulagarwal
AngularJS explicitly [1] states that its suited best for standard CRUD apps.
If you need to do something which requires touching the DOM or some low level
manipulation, better stay off it. We decided against it while building our GUI
Editor ( adpushup.com), and decided on Backbone (w/ Backbone relational).
Backbone is a library (as opposed to being a framework) and plays really nice
with jQuery and vanilla JS.

However, there'll be projects/components for which AngularJS (or EmberJS)
would be better suited, and we'll surely love to give it a try.

[1] :
[http://docs.angularjs.org/guide/overview](http://docs.angularjs.org/guide/overview)

------
colemorrison
I absolutely love angular. Documentation is a definite given. I was having a
problem with resolving an ng-class on <body> with $rootscope and I thought,
"I'll go look at $rootScope's documentation!"

[http://docs.angularjs.org/api/ng.$rootScope](http://docs.angularjs.org/api/ng.$rootScope)

Psyche. Good god.

------
dodyg
Please do not use a framework that you do not understand. It is not good for
the sustainability of your application. It is better to read/maintain a
verbose application than dealing with some obscure magic.

I tried to learn AngularJs but I can't understand it so I gave up and used a
simpler and more limited JS library (ractivejs).

------
jacques_chester
There's also a lot of missing fit and finish.

For example:

    
    
       watch( watchExpression, listener, [ objectEquality ] )
    

vs

    
    
       watchCollection( obj, listener )
    

Yet in watchCollection, like in watch, 'obj' can be an expression that is
evaluated.

------
adamors
When I first started using Angular I actually bought a video course on it from
Pluralsight. So when I started my first Angular project I hit the ground
running.

There are also a lot of free videos on Youtube, that sometimes explain things
more clearly than the docs.

------
gadr90
A framework guides you into a determined way of doing things. It is a known
tradeoff: 90% of what you need to do is simpler, 10% may be a little harder. I
have now built two medium-large web apps over the last months with Angular and
while, naturally, it's not without problems, I have found that most of my
difficulties were due to me doing things in a non-Angular way.

I also find it is going in a very good direction with the recent changes in
1.2.0. They listened to a lot of feedback from the community.

------
codereflection
Where are the Angular devs? Are they not paying attention? I would expect at
least ONE contributor to see this article and take in the feedback, offer
advice, make corrections.

------
arbus
> The page for directives is another (in)famous part of the docs that, despite
> relating to one of the most important aspects of the framework, is often
> derided as being overly dry

While that used to be true, the directives page recently got updated to
provide a much better and simple guide to directives along with plently of
code samples -
[http://docs.angularjs.org/guide/directive](http://docs.angularjs.org/guide/directive)

~~~
Narretz
There is still some work to do. Read the paragraph about transclude : true?
$transclude is one of the best features of advanced directives, and the
paragraph is still the old one which leaves you with a "... what?" even after
you read it 5 times. An example is very much in roder here, but how long
should the article be? Before, this section was actually in the guide, and the
doc for $compile was neat and clear. Now it's actually messier than before.

------
RossM
I've been turned off by the Angular docs (feels like how I found API refs
intimidating when I started coding) - can anyone recommend an alternative or
book?

~~~
optymizer
I've read "Mastering Web Application Development with AngularJS" and I thought
it was pretty good at explaining difficult concepts in AngularJS.

------
henrytao
In my opinion, despite some of the worst parts of Angular, we can use Angular
as an integration with existing front-end web framework. We can make AngularJS
work smoothly with the site running normal Ajax request, single page
technique... (as I made Angular working with OpenERP few days ago).

By this way, we can save a lot of time dealing with DOM and re-use all
existing technique too.

------
apunic
Got also into Angular for some while and my verdict: if this wasn't made by
Google it wouldn't haven gotten off the ground. Its concept has too many
quirks and isn't thought through. Tried recently React and this feels much
more sane, you have to relearn stuff but it's way less than Angular and
performance is better.

------
Kiro
Worst for me: hooking up Angular with a stateless REST API without using a
middle layer application for authentication.

------
itsbits
Every framework has pros and cons. I also suggest you have a look at EmberJS.
All those features you are missing in Angular are there in EmberJS like
promises using Ember's RSVP etc...And then EmberJS may be having its own
cons...Testability is one of them..

------
EGreg
Those people here looking for a tiny, sane MVC framework with live bindings
should try CanMVC. After doing a bunch of frameworks (JavascriptMVC, DoneMVC)
I think that company produced a simple, well documented framework better than
Backbone.

------
pablobaz
As you dive deeper into Angular it becomes clear a lot of it is unpolished.
For example $resource seems very half baked. It has lots of quirks e.g.
trailing slashes and its promises support seems to be a bolt-on.

------
luikore
I prefer rivets.js. I just need a little library for object binding, I don't
need weird java-like concepts.

~~~
jlebrech
wow, nice find

------
codeoclock
Pah! Let's write all our code in hex. We can't have the government getting
involved in anything!

Ron Swanson approves this message.

