
AngularJS: The Bad Parts - lars
http://larseidnes.com/2014/11/05/angularjs-the-bad-parts/
======
serve_yay
Actually, I think an opportunity was missed in the section about dependency
injection. The problem of minifying is easy enough to avoid - you just don't
use that form. (I do agree that the tutorials shouldn't be teaching the
dangerous form, and the dangerous form shouldn't even be a thing.)

No, what I hate about Angular's DI is that it tries to make inferences about
the name you give it, instead of the name being an unambiguous identifier. It
does this for "convenience" but it just ends up causing problems and making
incorrect guesses.

I'm talking about how, for example, if you have a class called
WobbleController, you don't inject 'WobbleController', you inject 'Wobble' and
Angular just "figures out" the 'Controller' part. Pretty sweet when it works!
Wow, you don't have to type 10 characters! (Good luck grepping for it later,
though.)

But when it makes a wrong guess it seems impossible to fix. The other thing
that sucks about this is that you have to reload your app to see if Angular
will actually be able to find the thing you're injecting. This whole thing is
supposed to save time, and it just doesn't. It sucks.

~~~
andybak
> The problem of minifying is easy enough to avoid

Yes - use a minifier that doesn't break Angular code. Asking me to insert
repetitive verbiage isn't an acceptable solution.

~~~
serve_yay
Sure, whatever, I just don't think it's the real issue with DI in Angular.

~~~
jaunkst
I am torn about how minification affects metaprogramming. I don't believe that
reducing the delivery footprint should ever effect how the code is
interpreted.

~~~
btown
On the other hand, if you think of access to argument names as part of the
Javascript language, then a "minifier" that threw out that information would
by definition not be a Javascript minifier - it would be a minifier of a
subset of the language.

~~~
alanh
lol. i have to laugh at this. it is _not normal_ to write a framework that
requires exact argument names in userland code. it is completely strange and
unusual for something to break just because an argument name was renamed; this
data is theoretically _private to the function._ The only reason this is not
the case in Angular is because of the _insane hack_ of stringifying functions.
This is a violation of how things are designed and assumed to work in
JavaScript. You don’t run functions by toStringing them and eval-ing them; you
just call them... anything else is an experiment, not a supported use.

------
nyir
The article didn't mention my favourite (ha) pet peeve with Angular, error
handling, which makes me wonder about if everyone else doesn't have that
problem: even after working with the framework for a couple of months now, I
still run, about every other week, into the issue that if something doesn't
work, there is exactly zero indication of that. Most prominently misspelled
names and parameters of directives. You're lucky if you get an error in the
Javascript console, if you happen to have that open all the time.

To me that's infuriating. I get that Javascript isn't Haskell (and I don't
even want to go that far into that direction), but the combination of extreme
leniency and the remarkable absence of checks is really bad.

~~~
wmil
I can see why they did that. Null/undefined checks in templates are messy and
ugly, and there are a lot of cases where objects on the scope won't be ready
when the scoped element is first rendered.

Templates shouldn't be throwing exceptions for something like customer.name
when customer is null. Angular's rendering tries to do something sane by
default in a very common case.

If it really bothers you, you can easily write your own click-log-error
directive that writes to the console if the function isn't defined.

Actually thanks to Angular's DI system you can replace the base ng-click with
one that does throw an error.

~~~
nyir
I didn't mean the template part in particular, rather think directive
arguments, scoping behaviour (the dreaded "wrap your value in an object if you
want data-binding").

Sure, not rendering a null value is, while I disagree, a possible choice and
certainly useful in certain contexts. However the point about objects not
ready should IMO be rather fixed by delaying until the object is ready and I'm
actually horsing that if possible so that no uninitialised state is visible at
any point.

And again, for production mode you mostly don't want exceptions to pop up, but
a strict mode for development is useful. Otherwise someone (who? the customers
won't notice this way) has to tell me that some values don't show up (yes,
modulo testing).

Replacing those handlers is actually a very interesting idea, I'll try and see
how that goes.

------
saosebastiao
I'm pretty new to front end development, and a few months ago I started
learning Javascript by experimenting with a few front end frameworks. When I
got to Angular, I dropped it the moment I saw string-based expressions. How is
that even remotely acceptable? I can't even imagine the bugs I would be
embedding everywhere.

~~~
rdtsc
Give react.js a try. I am not a web developer either. Saw Angular first. Got
lost in the soup of new terminology -- digest cycles, dependency injections,
services, factories, scopes. I suspect Angular probably made sense to already
experienced JS developers who had to struggle with jQuery before...

But then I tried react and the whole idea of unidirectional event flow made
sense, JSX was a little confusing but it was simple to grasp the need and use
of it.

~~~
jdlshore
> I suspect Angular probably made sense to already experienced JS developers
> who had to struggle with jQuery before...

Not really. Angular is its own little world of terminology and ideas. I've
heard it said that Angular users don't learn JavaScript, they learn Angular.

~~~
taurath
Absolutely the case - I enjoy Javascript coding but can't stand having to
follow Angular's opinions on everything that should be done to the DOM. Having
a consistent model of interaction is great, and Angular enforces that while
giving you quite a few nice tricks, but it does it in a way that feels so far
away from JS itself that I'd bet it actually hurts your Javascript composition
to know Angular.

------
lobster_johnson
Coincidentally, the scoping issue is almost exactly the same issue that
plagued Zope, a Python-based app server, back in the day.

In Zope, any property could be inherited not just from the parent object, but
from the current context; you could invoke the object path "a.b" and b would
inherit from b, but if you invoked the object path "a.c.b", b would inherit
from c instead. They called this design pattern "acquisition", and seemed
rather proud of it until they realized it was the kind of magic that was
ultimately too magical for its own good.

The Zope guys tried very hard to eradicate it, and in the process ended up
alienating all the developers with the new, non-backwards-compatible version.
Funnily enough, there is another Angular parallel to Zope: Just like Zope 3,
AngularJS 2.0 is also not backwards-compatible.

Angular's parameter-based dependency injection is coincidentally the same
reason Martini [1] is slower than most other Golang web frameworks. Clever,
sure, but ultimately a design flaw.

These problems demonstrate how important it is to introduce a good design from
the very beginning. You can fix bad code, but bad design is much harder to
change.

[1] [https://github.com/go-martini/martini#service-
injection](https://github.com/go-martini/martini#service-injection)

~~~
chumpalump
You nailed it, Sir. This "zopeness" is exactly what kept me from adopting
AngularJs.

------
moogleii
Our team chose to use angular admittedly because of its popularity (it's also
why we chose bootstrap over foundation, though that probably had smaller
repercussions). Most of the rest of the team then ran off to work on other
stuff, so I ended up with most of the angular work. It's been at least 8
months now, and I've gotta say the article is pretty spot on.

But I don't really mind anymore for two reasons: I know most of the gotchas
now (probably after some loss/whitening of hair), and I haven't used any of
the other major frameworks (like ember) to really be able to make an informed
comparison.

I don't know if there's a real takeaway here. Maybe "evaluate major contenders
even if one is super popular" or "be more vocal when someone tries to blindly
railroad in a candidate"?

~~~
serve_yay
That happened to me at my last job too. There was no real, actual discussion
about what we would use, the party line was "Angular looks like the future of
web development" (this claim came from people who spend all their time in C#,
not front-end devs).

------
nawitus
Just today I lost half an hour figuring out why my ng-show worked for all
other strings except for "f" and "F". AngularJS definitely has it's own
traps..

~~~
Guillaume86
What is the trick? I usually use "!!variable" to ensure boolean conversion so
I guess I would have been fine?

~~~
nawitus
Yeah, "!!variable" works, and in my case I used ".length > 0".
Boolean(variable) works too. It's just unfortunate when you're assuming that
the expression or typecasting works like in JavaScript, and then AngularJS had
to invent these unnecessary rules that make no sense. JavaScript's type
coercion is tricky enough, you don't need to make it worse.

------
likeclockwork
There is so much in this article that is disingenuous.

For example point #4 complains that Angular redefines Constructor to mean
something else.

The controller constructor IS a constructor, it constructs an instance of a
controller and can request and decorate(or construct) a new scope by injecting
$scope.

But the debate aside... the quoted revision is over a year old! (It also
hasn't reflected the behaviour of the controller constructor for even longer
than that, but that's a separate matter.)

------
nogridbag
When I was evaluating Angular, the near deal breaker for me was that the
router could only swap a single view area - which is useless for anything more
than a trivial "Hello World" example. To build a real app, I would have to
divide it into multiple small Angular apps. Is this still the case with core
Angular?

I realize there's the third party AngularUI UI Router project. I'm assuming
everyone who uses Angular for any real project uses that.

~~~
kuni-toko-tachi
Glad you mentioned this. Not every SPA has a UX that lends itself to nested
controllers. The routers and $scope handcuff you. And sibling views in ui-
router don't solve the issue either.

------
grannyg00se
The scoping should be made more explicitly against a particular controller.

The issue is resolved simply by using controller as syntax which is
recommended in many blogs. Point taken about the pit of dispair though.

[http://jsfiddle.net/sndyxfdk/1/](http://jsfiddle.net/sndyxfdk/1/)

------
EugeneOZ
that's why 2.0 is complete rewrite - exactly to eliminate all these bad parts.

~~~
lukifer
Can you specify some of the forthcoming improvements? I want to like Angular,
but every time I've actually used it has been a practical and conceptual
headache. (Also, the idea that they're creating a new compile-to-JS language
seems strange and unnecessary.)

~~~
ddoolin
A decent overview:
[http://www.infoq.com/news/2014/10/angular-2-atscript](http://www.infoq.com/news/2014/10/angular-2-atscript)

The kicker is elimination of these concepts: Controllers, Directive Definition
Object, $scope, angular.module, and jqLite

~~~
michaelchisari
The addition of a whole new scripting language seems... overly complicated.

~~~
paulhodge
It's TypeScript with the addition of a few key features that are helpful for
Angular's design.

Technically, Angular 1.0 also had its own scripting language too. It's kind of
inevitable, since Javascript itself is one of the obstacles to making a better
web framework.

~~~
emilis_info
I think it is more Dart... At least the AtScript specification mentions Dart
more often than any other language.

------
mcv
I loved Angular. And I still love many parts of it. I like the declarative
style, the automatic data binding, and all that other stuff that's painful in
JQuery, but fairly painless in Angular.

Well, painless at first. Because eventually you run into the limitations. The
data binding doesn't scale, a lot of things that are easy to declare
(particularly scope variables for directives) are a lot more complex than they
initially seem. The article hasn't even scratched the surface on problems with
scope in Angular.

And then there's the fact that my templates keep turning everything into
strings. Too often, when binding stuff from an outside controller to the
isolate scope of a directive, I keep having explicitly to turn all the strings
back into numbers.

Still, Angular does a lot of very neat stuff. There are just too many common
use cases that the neat stuff doesn't really cover very well.

------
btown
A lot of people complain about Angular's digest cycle and hold up React as the
way forward. My understanding, and I could be wrong, is that both frameworks
do work for every "binding" to the data in every update cycle - for React, you
need to create short-lived objects for a component and its children AND
evaluate every dependency on external objects, whereas for Angular it's a few
function wrappers and iterations on top of evaluating every dependency on
external objects. Seems like modern JS JITs should optimize both of these
cases so it's just the evaluations. And both frameworks have facilities for
limiting the scope at which the update cycle needs to run. Am I wrong in
saying, then, that React isn't inherently more performant?

~~~
lobster_johnson
As I understand Angular, objects are mutable, and Angular must perform deep
dirty checks on every object to be perfectly consistent. As pointed out by the
author of the blog post, this needs to be repeated until there are no more
changes detected. That's the whole point of Angular's digest loop.

React's data model is much simpler, at least at a high level. State changes
are explicit, and data is immutable. This means that whenever you give a
component new props, it can simply do a deep comparison of the data with the
previous version and mark the component as dirty if it's changed. (Setting a
new state always triggers a re-render, no matter if the data is different or
not.) Since data changes only happen explicitly, and flow naturally through
component nesting, it doesn't need process a lot of data to figure out what
needs to be updated.

The list of dirty components is then processed to produce the virtual DOM,
which is then diffed against the real DOM. Doing anything with the real DOM is
expensive, whereas the virtual DOM is extremely fast. So is building the
virtual DOM; while it's true that a component's render() method needs to build
its own tree every time it's called, re-rendering is extremely fast, even if
you actually change state near the root of the virtual DOM (which causes a
bigger cascade of dirty checks). Current JS engines are capable of creating
tens of thousands of objects in just a few milliseconds.

(There are a few of optimization tricks you can use to avoid renders, too. In
particular, there is PureRenderMixin, which declares that your component is
"pure", meaning that given the same props and state, it will always render the
same tree, allowing React to do shallower checks to determine if a render is
needed.)

------
iamleppert
Angular is awful. I took one look at the docs way back when we were evaluating
at BigCo and walked away.

------
dscrd
> Whatever the reason is for Angulars popularity, it isn’t that it’s a great
> framework.

Something similar to this seems to be true for every piece of programming
technology that is popular. How did it come to this? Other professions don't
go in masses towards the worst solutions, do they?

~~~
wmil
"There are only two kinds of languages: the ones people complain about and the
ones nobody uses."

-Bjarne Stroustrup

Every piece of tech involves design tradeoffs. Most software benefits from
network effects -- there are advantages to using what everyone else is using.
Because of that people inevitably end up using software with design decisions
they disagree with.

It's worse in programming because their are fewer hard design limits.
Everything comes down to preference.

------
serve_yay
I've built a couple things with it, and I wouldn't use it again. But it's very
popular!

------
bsaul
i've written a fairly large angular app, and the ng-if case struck me as
totally incomprehensible (why the hell would ng-if have its own scope ?). Then
i realized i've never had to use ng-if.

That's not to minimize the trouble you get when you first have to learn about
scope inheritance, but I think ng-if may be the only completely non-intuitive
directive of the framework. (As opposed to something like let's say ng-repeat,
where you sort of get the intuition that some care will be needed).

~~~
wmil
I don't think that's even a scope issue...

ng-model will auto-create scope variables if they don't exist. That's a handy
shortcut.

But if you have two inputs that can auto-create variable you're asking for
trouble, and you should probably initialize it on the scope constructor.

Or at the very least, use an ng-init so that you know where it will be
created.

------
leeber
Here's why I like angular...

It only took me a couple days of fooling around with it before I built
something useful with it. The steep learning curve is only if you want to know
the how-and-why behind every feature of the framework (which I still am not
even close to). Learning 100% of the framework is simply not necessary for
certain apps.

It's easy in my opinion, it's quick, and it gets the job done. If I run into
any problems, there about a bazillion stack overflow post addressing my issue
already.

~~~
darkmagnus
you sound practical...gasp!!! ;)

~~~
serve_yay
Think so? To me it sounds like the sort of person who leaves messes to get
cleaned up by others. No need to learn the tools you're using, just shove shit
out the door and let someone else worry about it!

------
hcho
The dependency injection thing is really a non issue. Just use something like
ng-min before you minify and you are set. Just for the price of another entry
in your grunt.js file.

~~~
nawitus
It's "insane" to require a post-processing step to fix a bug in a single
framework.

~~~
arnarbi
Maybe your use of quotes is to make fun of the article, but in any case, I'll
say this: I disagree it is a bug, rather it is a shortcoming of a minifier
that it does not preserve the semantics of the input program.

Since this shortcoming is hard or impossible to overcome completely, case-
specific post-processors to help out the minifier sound reasonable to me.

~~~
nawitus
I think it's simply a flawed design to use reflection to read function
parameter names and then use that information to apply semantics. I think
parameter naming is something that shouldn't directly be semantic, as that's
what most developers except. If, for example, I'm supplying a callback
function to a library, I don't except the library to read the parameter names
and then do stuff differently depending on the variable naming I happened to
use.

I think your point about the minifier being "broken" is a good one, but the
real problem is with AngularJS in my opinion.

~~~
general_failure
Isn't this exactly what Active Record in Rails does?

~~~
bronson
No, ActiveRecord never looks at argument names. (unless you're talking about
Ruby's named parameters, which is nothing like Angular's DI and not AR-
specific)

~~~
general_failure
What I meant is db tables and field names get converted into ruby class names
and properties/methods. This is basically convention over configuration. It's
the same with angular.

------
msoad
I understand most of it, but digest loop is a great idea! It's much better
than manual `model.on('change', view.render)` of backbone for example.
Developer might forget to do this manual rendering for certain actions which
is bad

~~~
orthecreedence
I view it as an icky hack. I much prefer the `model.on(...)` explicit wrapping
of model data/eventing in an object. It's a lot more performant and easier to
look at and say "that is a model" vs "this is a javascript object, but I don't
know if it's being listened to or not."

Forgetting to set up your eventing fabric is not a great reason to choose a
framework. If you forget to hook up the wires, the view doesn't render
properly. This is easily debuggable.

------
psp
I think digest loop is one of the best parts of AngularJS. I wonder how it
ended on this hate list. I dont think I will agree with much of the rest
either.

~~~
sanderjd
Out of curiosity - what do you like about the digest loop? I have never
thought of it as anything other than a necessary evil in implementation to
achieve some high level goals.

------
xfalcox
I can't get the script who counts the bindings to run. Any help?

Uncaught TypeError: Cannot read property '$$nextSibling' of undefined

~~~
lars
Maybe you're not using ng-app? In that case, document.querySelectorAll("[ng-
app]") wont return any elements, and it wont find the root scope. Replacing
"[ng-app]" with a selector that finds your root element should work I think.

~~~
xfalcox
I'm using the deferred bootstrap indeed. Changed to body and now the script
works, thanks!

By the way, very nice article, and after working with some real time angular
apps, the thing that haunt me the most is the number os binds.

People just want more information, and it can hard to explain that we have a
limit.

------
pgsuckz
TL;DR: AngularJS is a horrible framework because it can be abused by newbies
and is too "complicated" plus some other non-issues.

~~~
smt88
"Too complicated" is a huge issue in the real world. It makes code hard to
maintain, hard to pass off to others, and hard to reason about. That's the
main issue with Angular: it's hard to reason about the code, and it frequently
violates the principle of least astonishment.

------
kuni-toko-tachi
Glad the truth is coming out! This will save a lot of developer time and will
make SPA's even better.

------
jmstout
I first tried to view this article on my mobile device and saw this:
[https://dl.dropboxusercontent.com/u/117695213/static/larseid...](https://dl.dropboxusercontent.com/u/117695213/static/larseidnes.jpg)

To me, this is already revealing. A critique of a web framework and this is
the first impression I get? Not off to a good start. There’s a reason people
find it hard to trust a fat nutritionist. I see parallels here.

Lately there has been a lot of negative feedback about AngularJS and I have
been interested in the critiques of its shortcomings. For this reason, I gave
him the benefit of the doubt, pulled up the article on my computer, and dug
in.

His initial complaint about prototypically inherited scope properties (Bad
Idea #1) being confusing and "literally impossible" to predict was perplexing
to me. He states that he understands a child scope will inherit from its
parent scope, yet doesn't explicitly instantiate any object on the parent
controller in his example of the so-called problem (
[http://jsfiddle.net/1op3L9yo/](http://jsfiddle.net/1op3L9yo/) ). A child of a
parent with no properties inherits nothing from its parent -- this seems
obvious. If properties are actually defined on the parent the child will
inherit them. Is this not the expected behavior?

The "fix" for his "impossible" scenario, is to make sure you explicitly define
the property on the parent.

In his specific example, that would look like this:

$scope.obj = { prop: '' };

( [http://jsfiddle.net/355fuxk5/](http://jsfiddle.net/355fuxk5/) )

He complains: "Whether or not a new scope is introduced by a directive is up
to its implementer. And if a new scope is introduced, it is up to its
implementer to decide if it inherits from its parent scope or not."

How is this a bad idea? I like choices in life, don't you?

He talks about dynamic scoping being a terrible thing. I think the
alternative, dictating One True Way of doing things, removes flexibility. This
would be far worse than the current status quo of leaving it up to the
developer. He advocates for removing this choice altogether, but is there
NEVER a good use case for this "dynamic scoping"?

He also complains about the digest loop -- how two-way bindings constantly
check for changes and impact performance as your number of bindings grow.
There is truth to this, but it is easy to write your own directives that only
update UI elements when a change occurs. This can easily be achieved in a
variety of different ways. (The most universally familiar of which being a
simple callback paradigm.)

Building a quality application with angular requires you to think, but I would
argue that designing a performant application with ANY framework demands the
same thing. You might initially think you get some things for free, but
everything has its costs. If you want things to happen automagically, without
needing to be explicit about the needs of your specific use case, that'll cost
you. Is this not a near universal truth in programming? People fault the
framework when, instead, they should be faulting themselves: their own
laziness or lack of clarity.

He talks about having a page listing where their UI already had 2000 bindings
and how clicking a "load more" button added another 1000 bindings, killing
performance. I can't understand why you would possibly have that many
bindings... for ANYTHING, unless you're Doing It Wrong. Why would you need any
two-way bindings for explicitly appended information? When the user clicks
"load more", we know something needs to change. If performance is a concern,
why would you ever allow that listing to be automatically updated by checking
for changes on every digest cycle? Instead, you can either explicitly update
the element when the action is called (no two-way bindings), or use a SINGLE
binding for the entire list. 1000 bindings? What could possibly be the
justification for that?

Bindings can be drastically reduced and performance dramatically improved if
you work to optimize your code and move from prototyping with built in ng-*
components, to crafting components explicitly for your needs. I truly believe
the standard ng-* components are meant more for prototyping and to serve as an
example for how you can accomplish similar things as your write your own
application specific code. Not being clear about this is perhaps one of
angular's biggest failings.

Does it really surprise any programmer or developer that in order to achieve
high performance in your application, you must architect explicitly for your
use case?

To put it another way, in order to make a great application, you need to
understand what is happening under the hood. If you're using components that
you don't fully understand, that end up running a bunch of unnecessary
operations, is that the framework's fault, or your own?

Is it really the role of the framework to do your development for you? You can
either have things happen automagically, or have things be performant, but not
both. This is reasonable and beyond logical, I think.

He critiques the language used in the documentation to explain controllers and
hangs his hat on what he feels is the misuse of the word "constructor". His
contention is that this is incorrect because the controller functions are
being applied to an existing scope, not being instantiated in the traditional
sense. Yet, and he even admits this, he is critiquing documentation that is
over a year old. The current docs do a better job of clarifying what's
actually happening. How is this a fair critique of a framework? Cherry picking
year old documentation... this just seems silly, and as someone else said,
disingenuous. Nothing is perfect, especially out of the gate, especially in
open source -- I think we all know that.

His further complaints in this section employ the same strategy -- he takes
segments from the documentation out of context and explains why they don't
make sense. He even says that their use of the term "syntactic sugar" to
describe the many options for creating components (services, factories,
providers) is incorrect because, in his mind, "syntactic sugar" would imply a
direct syntax modification to JavaScript or implementation of a custom
language parser. Really?

Let's see what Wikipedia has to say on the subject:

"In computer science, syntactic sugar is syntax within a programming language
that is designed to make things easier to read or to express. It makes the
language "sweeter" for human use: things can be expressed more clearly, more
concisely, or in an alternative style that some may prefer."
([http://en.wikipedia.org/wiki/Syntactic_sugar](http://en.wikipedia.org/wiki/Syntactic_sugar))

Soooo, for example, angular's service and factory being abstractions over the
provider implementation? When you don't need the full power of a provider
using these higher level functions makes it more concise, easier to use, and
"sweeter"... sounds like syntactic sugar to me, unless we're just being
pedantic for the sake of it.

He says, "Angular seems to strive to make things as complicated as possible."
I would argue that this simply isn't true, is shortsighted, and borderline
insulting to the intelligence and efforts of angular's core team. I believe
AngularJS is opinionated but it strives to make things as flexible as possible
and as a result some inherent complexity exists.

In my (almost) 2 years of working with the framework, this is what I’ve found:
AngularJS is extremely flexible. Its built in components are great for quick
prototyping and its underlying structure provides an excellent FRAMEWORK for
creating more purpose built, application specific, code. In my experience,
angular is there when you want it to be and quickly gets out of your way when
you don't need it. This is a robust framework. It is built for rapid
prototyping and creating complex, performant applications (when properly
executed). It is not baby's first framework.

How many times have we heard the old adage that, with most things in life, you
get out what you put in. This is doubly true for angular (and development as a
whole, I would speculate). If you're willing to put in the work, AngularJS can
be a phenomenal tool in your arsenal. It can also be great for getting a
prototype together, but one must understand, that a prototype is just that.
Using ng-* components everywhere and expecting everything to work out
optimally is just not going to happen. Did you REALLY think it would?

To pull a quote from his last paragraph:

"... many people like to recommend projects they haven’t used in any depth,
because the idea of knowing what the next big thing is feels good. The result
is that people choose frameworks largely based on advice from people who don’t
know what they’re talking about."

The irony here is palpable. Change "recommend" to "criticize" and "knowing" to
"condemning" and I almost needn't say more (he says, 8000 words later).

~~~
lhorie
I've also been using angular for about the same amount of time, and I think a
lot of what he's saying is valid. On more than one occasion, a co-worker would
come asking for help with a bug and to explain why it was happening was far
more complicated than it really should be.

Of course putting enough time on a framework can pay off once you've mastered
the tool and know all the caveats. The problem is that if you weigh the pros
vs the cons objectively, the cons are not something you can scoff at. Angular
has a lot of complexity that is difficult to reason about, and there are a lot
of traps along the way to mastery (speaking from experience seeing co-workers
shoot their own feet).

For me, the biggest problem is that it throws some seriously useless errors
(e.g. race-condition infdig on a route redirect). In a sane framework, errors
are meant to direct you to the cause, not simply to announce that something
somewhere is written in a way that the framework doesn't like because of
complex reason foo. This can be a serious showstopper if you are more than a
single developer working on the codebase and even more so if the rest of the
team touching the codebase isn't made of Angular superstars (which is often
the case).

------
wnevets
This article the bad parts: all of it.

~~~
RussianCow
Could you be more specific about what you don't like about it?

~~~
wnevets
Extremely derivative and already talked to death here on HN. There is
virtually nothing original in this article.

~~~
mistermumble
This is the first time I have read some of these criticisms of Angular on HN.
Can you point to threads where there was discussion of these issues? Would
like to get more info on these. Thanks.

~~~
tim333
There's some stuff here
[https://news.ycombinator.com/item?id=8507632](https://news.ycombinator.com/item?id=8507632)

and here
[https://news.ycombinator.com/item?id=8527230](https://news.ycombinator.com/item?id=8527230)

------
mck-
Bad Idea #1 : can be prevented easily with `controllerAs` syntax — this is
pretty widely accepted to be best-practice, so the approach that he points out
should never be used to begin with

Bad Idea #2: can be avoided using gulp. If you are minifying, you should be
using gulp anyway, so it’s just a matter of adding a plugin to take care of
that

Bad Idea #3: this is true, and you have to take care of it for large-scale
applications to prevent performance breakdowns. Since angular 1.3 there are
one-time bindings as well.

Bad Idea #4: This sounds like nitpicking from a JS purist

Bad Idea #5: I agree that this stuff is unnecessarily complicated

so yeah… there are many ways that you can break Angular :p learning curve is
definitely steep.. and there are plenty of edge-cases that will bite you.
Despite all that, it’s pretty powerful at what it does, once you get around
it…

