
I won't be using Angular for my next project - hippich
https://javascriptkicks.com/articles/2657
======
BinaryIdiot
I find myself liking almost every one of these articles that talks about how
"you shouldn't use popular JavaScript framework X because <list of reasons
why>" a little too much.

After many years of dealing with various frontend frameworks I've essentially
taken a curmudgeon attitude with many of them and find it far easier to simply
write my applications using just JavaScript and maybe some messaging library
to get the decoupling I want (I've posted on HN before about my little library
called msngr.js that I use in many of my projects now because I am in love
with messaging patterns). I find these far easier to understand than any of
the frameworks that provide "magic" of sorts where automatic things happen for
you.

The last time I used Angular was picking up a project other developers did. It
had a good separation but felt very overly complex. But I feel that way with
most frameworks (especially react).

I think the key takeaway here is that Angular, React, etc; these frameworks
are not for everyone and are not for every project. If a framework forces a
way of development that helps keep productivity higher then it's probably a
good fit at least for that team. As a plus almost any of these frameworks can
be used with great success for prototyping. So I think there is always value
there.

~~~
Shog9
IME, this tends to be a problem with frameworks in general: the goal, after
all, is essentially to create a new platform on which to build, but that
implicitly invalidates a whole lot of knowledge your potential users have of
the _underlying_ platform.

In other words, you're asking folks to not just learn something new, but also
forget something they've perhaps invested a great deal of time and energy into
already.

Sometimes, that tradeoff is worthwhile. But it's never free.

~~~
logicallee
good point, but a sunk cost. New programmers, such as young* developers
learning front-end architectures for the first time, never learned all of the
underlying platform. So they can spend the next ten hours achieving x amount
of progress in pure javascript, or y amount of progress coding atop a
framework.

As an analogy, the difference between x and y is why, in decades past, so many
inexperienced programmers started coding C without ever learning assembly -
and then later, so many people started codig in a high-level interpreted
language without ever learning C/C++. (Which may have been the language the
interpreter was coded in, or even available directy if they needed it, such as
in very performance-oriented code.)

* a general observation, more rigorously read: inexperienced.

~~~
Shog9
That only works if the framework actually does work as a complete platform,
though - that is, if you can get away with forgetting (or never learning) the
underlying platform _once_. To go back to Angular, it would mean forgetting
all about the non-Angular-friendly parts of the DOM, events, etc. and never
needing to use them again.

I haven't written any assembly in many years now, but for a good while it was
still pretty important to maintain that knowledge - you never knew when you'd
need to use it for a routine here or there that was just too slow or
cumbersome in C. And still, long, long after that, _debugging_ C required at
least some assembly knowledge if you wanted to get home in time for supper.

And this is where I see folks getting into the weeds with stuff like Angular:
if you completely forget (or never learn) the underlying platform, it's
entirely too easy to get stuck when it comes to debugging or even performance
issues: you know it shouldn't take 3 seconds to render the page, but if you
can't look under the abstraction then you're hosed.

So eventually, you're stuck learning the whole stack anyway. And now it's not
a sunk cost: you have to forget what lies beneath every time you sit down...

------
yesimahuman
We've been working on the next version of Ionic with Angular 2, and I've been
really impressed by it. No more two-way data binding and going crazy with
ngModel, scope oddities are gone, etc. Scope is replaced by component instance
data, and controllers by component constructors and methods, just like it
should be! Building components is a _lot_ easier than directives, and they can
be extended and composed in a more OO fashion. It's way more accessible and
easier to learn than v1 was.

Also, it's actually a lot closer to being ready than people think. We've had
relatively few roadblocks despite the alpha status. It tries to do less than
v1 did, which we appreciate as a framework extension.

So, obviously we are heavily invested in Angular, but we also see the v1
design issues firsthand and are the first to admit Angular can, and should, be
better (though people are building amazing applications with it today). I'm
convinced v2 is going to be great for the project and switching costs won't be
as terrible as previously predicted.

Plus, it's going to make v2 of Ionic a lot faster and better, so I'm all for
it.

(also, we are starting a series of posts on how Angular 2 works, if you're
interested: [http://blog.ionic.io/angular-2-series-
introduction/](http://blog.ionic.io/angular-2-series-introduction/))

~~~
aikah
> So, obviously we are heavily invested in Angular

You probably don't need angular at that point anyway. You could make up your
own stack it wouldn't make a difference. Or it means depending on a framework
that may change with each version new, breaking all the code of your users
because i'm pretty sure you won't be maintaining old versions of ionic for
long.

Don't break interfaces, that's what made Linux popular, that's what made js
popular,jquery popular, even windows(until the modern ui fiasco)... Refactor
but don't break. Eventually you people following angular demise will learn it
the hard way.

~~~
yesimahuman
Though your comment is overly dramatic, I agree to an extent. Ionic
"transcended" angular to the point that a lot of new Ionic devs learn Angular
through Ionic.

That being said, Angular 2 is a big technical improvement and the changes
required to support it aren't too burdensome. It will make Ionic apps faster
(on mobile we can use any perf improvements we can get). We are going to work
hard to not break interfaces as it pertains to the Ionic API.

~~~
aikah
Mark my words, you don't need Angular but you're now taking a risk with each
version of a product you don't even need at first place.The time spent
rewriting your entire framework is some time not spend writing new features
for the current one.

------
sb8244
This seems slightly sensational to me. I thought maybe it was because the
author would view me as Junior, but then I saw his other post and it just
doesn't apply at all. In fact, I felt even more strongly after reading his
explanation article.

Why I don't like the article:

    
    
        * Very vague about actual issues and instead a lot of generalizations. Even the explanation article isn't very helpful.
    
        * No real concrete code backing his examples.
    
        * Generalization that having any logic in views is a bad thing. (ng-if and ng-hide is all you really need in a view and it isn't bad if used responsibly!)
    

I've only been served well by Angular. I find it's flexibility to be
exceptional, and has blended almost perfectly with our Rails pipeline and API.
We have a pretty large codebase with it and integration with legacy
javascript. It just works.

Performance is a real concern and is one of the reasons we haven't ported a
large legacy view to Angular, but I think we could solve this if we really saw
value in porting it over at this point.

~~~
zarriak
A lot of the post has more to do with js itself. The author talks about
performance, but never addresses the fact that most juniors probably started
in Python or Ruby. They didn't have to care about doing things the most
efficient way, and could probably just use a framework to do what they wanted
to do without caring about implementation. This lack of concern is not
rectified by any of the senior engineers, and only appears once they are
required to do something outside of a framework that provides decent
performance.

I don't want to come across as rude, but it seems strange that hiring a junior
developer and introducing them to web development doesn't come with a guide on
what to do or how to approach js. I don't quite understand how researching
deep enough into Angular to find out about performance tweaks doesn't lead one
to make a guide or tips for new hires. Sure, you can hope that they know what
they are doing, but if you care enough to stop using a framework due to their
bad habits it might be time to reflect and realize that the power given by a
framework comes with more abilities and more pitfalls.

This trade off is clearly demonstrated when the author talks about the
"pit[s]" that junior engineers fall into. They look at code and see it works
for one use and just use it in the other case because they have seen it work.
It isn't all their fault that they are "very good at copy and pasting" because
nobody has told them the steps to guide their code structure. I appreciate the
author for sharing his views but it seems like it would be helpful to provide
the list of pitfalls and ways to avoid them to his juniors instead of
disliking frameworks.

~~~
robertthegrey
I disagree - most of this post I wrote has very little to do with JavaScript
itself and everything to do with Angular. Likewise, I don't want to come
across as rude, but I also don't want words put in my mouth. The performance
issues with Angular are not fiction, they are very real concerns. Hence the
sheer number of tutorials popping up lately showing you how to use React in
your Angular apps to improved the rendering performance plus a number of other
hacks I'd prefer my juniors steer clear of.

It's also got nothing to do with the juniors coming from Python or Ruby, in
fact most of mine started on Java and Erlang or are self taught, but I've had
very little trouble with bad habits creeping in to projects with those same
juniors when using frameworks like backbone, ember and react (so far) - so
once again, it has very little to do with pitfalls in JavaScript and more to
do with pitfalls in Angular itself - at least, that has been the case IME.

------
cl42
For those folks who have used Angular in major projects, but also have
experience with other frameworks, what do you think?

I ask because this post is a bit light on details and feels a bit angry to me.
I'm not a front-end developer, but our dev team has not complained about
Angular and I'm wondering if I'm missing something.

~~~
stupidcar
I have been using Angular for the past two years as the primary front-end dev
in a start-up. Prior to that I spent ten years doing web development, both
back-end and front-end, with a wide variety of libraries and frameworks.

Angular is still, by far, the best framework I have ever used. I have zero
regrets about choosing it.

This post reflects the pathological nonsense that pervades certain quarters of
front-end development. It demonstrates the following fallacies:

1\. If a technology has any flaws, they render the whole thing worthless.

2\. New technologies that I haven't tried are probably perfect and won't
require any hacks.

3\. Kids these days aren't doing any _real_ programming like we did back when
we coded in Backbone / jQuery / Raw JS / VBScript / Java / C++ / COBOL /
Assembly / Punch-cards.

4\. Syntactic sugar and abstractions are inherently bad, whereas writing a lot
of boilerplate code is good for the soul.

5\. Someone I respect doesn't like something, so I shouldn't like it either.

6\. Old, widely deployed technologies are over-complicated, because people
have built more complex systems with them than with new technologies, and thus
have been forced to tackle more complex requirements.

7\. I have worked with this technology for a while, and built up a corpus of
specialist knowledge and hacks, therefore it is more flawed and than these
newer technologies, which I haven't worked with and therefore only understand
in a shallow way, and therefore seem simpler.

8\. Acquiring specialist knowledge is bad, and not the reason I am paid to do
what I do.

~~~
woah
Good points, but angular has the very real drawback of useless terminology
(transclude?) and a lot of wheel-reinvention (the several strange types of
components). It's a pretty standard observable framework dressed up with a
bunch of unnecessary hocus pocus (and pretty bad performance).

I've strongly disliked angular as long as I've been able to code. On the other
hand, I like react a lot even though it has a similar learning curve. React
may have strange and unfamiliar concepts, but they are actually new concepts
in ui development that make things less error prone, very performant, and
cross platform.

If the angular team was not funded by Google, I doubt any of them would be
working on it any more. Actually, with angular 2, that's the case anyway.

If you don't like dom-diffing frameworks, maybe check out vuejs. This is an
observable framework like angular, but it's performance is acceptable and its
api is very clean and makes sense.

------
UweSchmidt
Another one of those articles :-) The author feels the pulse of a javascript
framework's culture. Watches versions, core developers and his own feelings
about it all. Career opportunities and sunk learning costs are at stake.

As everyone is learning, no project is really "typical" and so much is up to
personal taste, chances are we won't see a case study of a project in various
stages. Ideally the author of such a study would describe clearly just when
the framework clicked for him, and when it became a burden. Just what code is
so cumbersome it's never fun to work with? What feature was rejected due to
performance concerns?

All we can do is read those articles and, going meta, keep track of the
frequency and sigificance of these articles and get an idea where the hype
train is going...

------
joshribakoff
No web framework is perfect. I do dislike parts of Angular, for example
silently ignoring unrecognized directives.

I love doing web development, but parts of web programming suck. Therefore,
there's going to be parts in every web framework that suck.

I find that being a fanboy for any framework is unhealthy. So is being a
hater. It has good parts & bad parts. This article seems uninformed. There is
a lack of Angular specific terminology. Most of the criticisms may in fact be
valid, but are not backed up or explained. The author also recommends
alternatives then goes on to imply he has not yet "taken these for a spin". I
feel the author may be talking about stuff he doesn't have enough experience
with.

I won't tell you Angular is the best framework, or that it is good or bad. I
will advise you to ignore articles like this & try it out for yourself.

------
dyscrete
I don't think anyone will see this but here goes.

Try Meteor[1].

Over the past few years using things like Angular, mithril[2], React[3],
Vue[4] Meteor, and Ember[5] for large production sites, I've found Meteor
painstakingly easy to quickly build real-time "isomorphic" web applications.
If you haven't tried it and you're thinking about creating an app with a
FRP[6] app I recommend giving it a whirl.

[1] [http://meteor.com](http://meteor.com)

[2] [https://lhorie.github.io/mithril](https://lhorie.github.io/mithril)

[3] [http://reactjs.org](http://reactjs.org)

[4] [http://vuejs.org](http://vuejs.org)

[5] [http://emberjs.com](http://emberjs.com)

[6]
[https://gist.github.com/staltz/868e7e9bc2a7b8c1f754](https://gist.github.com/staltz/868e7e9bc2a7b8c1f754)

Edit: Fix spacing

~~~
ciokan
Meteor is not just a web framework which many actually want. I can't just
build a new frontend for my existing Django application with Meteor can I?
Meteor is server & client with also a lock on Mongodb.

~~~
sebastianconcpt
Of course not. Meteor is not a frontend framework that will fit yor X backend.
Meteor is an Isomorphic Environment that, by the way, rocks if you have the
freedom to choose it. Completely different things.

Regarding to MongoDB, the Postgres option is in the pipeline.

------
hyperpape
I really don't get what people mean when they say they're against frameworks.
Your app that you're making with no framework...how are things structured? Do
you just repeat yourself everywhere? Or do you really have a pseudo-framework
that's implicit in the conventions that you use?

What I'd like more than anything else is examples of substantial web apps
written without a framework.

~~~
albertoleal
I don't think that's what people meant.

This is probably what they meant:

"Developers will move, I believe, from monolithic frameworks like Angular.js
and Ember to a ‘pick n mix’ of small, dedicated libraries to mitigate the risk
of churn"

Source: [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/)

~~~
hyperpape
I should've pre-empted this, but I didn't. If you're gluing libraries
together, it seems like you're sort of creating an ad-hoc framework. Is the
difference just that you're making it up as you go along and you're not
creating something that attempts the same kind of generality?

~~~
zarriak
A major advantage to putting libraries together is making the code that is
able to be the glue between the different libraries. It usually is the part
that defines the structure of the app overall, allowing you create solutions
to your needs that are not available to you in large frameworks. You can
implement the same things in Angular or Ember, but you will be sacrificing
choices that will result in the problems present in the author's article. The
inherent formulaic approach lends itself to extending the use of things that
worked in the code base to places they shouldn't be. This is significantly
decreased when you are handling the libraries, because they force you to think
on a more fundamental level of the approach you need to take.

Take this basic idea of what an app does (I use code in this context to mean
js that was written by you.)

Input -> The code -> Output

Frameworks: The code exists in all three areas, resulting in having to change
all three areas of the code instead of one.

Libraries: The code exists separate of the input and output, allowing one to
make changes to any of the three areas without having to change much (if
anything) in the way the code works. This (in theory and usually in practice)
also makes testing easier to develop even if the code wasn't designed with
testing in mind.

~~~
hyperpape
This only seems applicable to code that can be structured as a pipeline of
data, which isn't many javascript apps.

------
deif
As someone who has worked extensively with Ember and Angular in large
projects, I'd say that I prefer Angular even though I know the current version
will be deprecated.

I've found that ensuring functionality is locked into tiny angular modules and
proper project structuring makes working with the framework a complete breeze.
The testing framework that is inbuilt is mega handy too.

That said, the ending conclusion that we should be wary to jump on the Angular
bandwagon is not unfounded. I'm a bit wary, however, of Ampersand since it
looks a LOT like Ember, and well... I'd just use Ember if I wanted that.

Aurelia looks quite promising. There's not a lot of info out there about it,
so I doubt a lot of people will start jumping the Angular ship just yet, but
it's something interesting to keep an eye on.

~~~
modnine
The main difference between Ampersand and Ember is that Ampersand has embraced
npm and does not require you to find a way to fit the problem at hand into the
framework. For example, at work we have an app that only uses the domain layer
(collections and models) from Ampersand and uses React for the view layer.
Ampersand has embraced the library concept and is not really a framework at
all.

------
BurningFrog
The most popular technologies always get the most complaints. You can almost
use the hate volume to measure what the best technology of the day is (I said
_almost_ ).

One reason is the obvious one. The more people who use something, the bigger
the population with something to complain about. And the bigger audience to
write for.

I also think there is a tipping point when something gets so established that
people are _told_ to use it.

------
mmastrac
I've used Angular for a big project before and had no issues with it. In fact,
it's one of the most productive frameworks that I've used.

I tried ember.js as well, but it wasn't my cup of tea. I wouldn't go so far as
to recommend people avoid Ember because I didn't like it, unlike this post has
done.

Just because X isn't a good fit for you doesn't mean that it's a "Bad Thing".
And just because X is great for you doesn't mean that it's a "Great Thing". We
have so many options because there are tradeoffs for all of them.

------
dude3
I just started using ngReact
[https://github.com/davidchang/ngReact](https://github.com/davidchang/ngReact).
I replaced the main ng repeaters in the app with react jsx lists and the
performance improvements are noticeable even on lists that are not long (15
items) with lots of ng binds. This needs to be built into angular by default
period and the integration could be improved significantly. Also filters are
horribly slow and need to be fixed or not used in views at all.

~~~
Bahamut
You should try out [https://github.com/wesleycho/angular-
react](https://github.com/wesleycho/angular-react) (disclaimer: I built it) -
it cleanly integrates the ability to use React with Angular

------
robertthegrey
Wow, didn't expect the varied responses to my article, but glad to see it's
opened up some good criticism of Angular itself, and of course my own
reasoning in the post. Always good to get balanced opinion, and the only
reason I put something like this out in the public domain is to get that
feedback - maybe there's something huge I'm missing and others with experience
can help. I've been in this web programming game for 20 years now and if
there's one thing I've learned, is you're never too old (or experienced) to
learn something new.

For those bemoaning the fact that I was hating on junior devs - I wasn't - and
I explain that in a separate article linked to from the post, so it may help
clarify those points. I also give more concrete examples in that follow-up
post because a lot of comments said I was being too vague in this post - which
to a certain extent I agree with, but it was never my intention to write a
book or a manual. If someone is genuinely interested in more depth to some of
my reasoning, I'm happy to be contacted about it with specific questions and
we can go more in depth. Doing that in the post would have lost more readers
than it gained so for me it was a balance for an already long article.

The bottom line for me, is that it's been far easier to get junior devs going
in frameworks like backbone, ampersand, durandal (aurelia now) and react than
it has been with angular and I've seen less bad habits forming. For me those
are facts in my day job - but your mileage may vary.

------
collypops
Where's the cancer comparison...

 _scrolls_

...where is it...

 _scrolls some more_

...ah, there it is.

------
aaronem
I don't exactly love Angular either (though I do use it), but you can
criticize it without descending to outright misrepresentation, as with the
claim that you have to order view directives in a particular way or things
break. That's totally untrue, and the article linked in support of the claim
doesn't say anything of the sort -- it's just some random guy explaining how
he orders his directives and why.

------
exratione
Mileage varies.

I my experience AngularJS works well with quality teams who come into the
Javascript ecosystem with a front-end / design / HTML background. They get the
markup-based systems; it's less of a leap. I can think of one team in
particular who had a horrible time with Ember, but took to Angular very
quickly.

The application speed thing, I think, is non-issue now that people have
figured it out and written a lot on the topic. There are a lot of good
articles out there that explain very clearly how not to write slow AngularJS
applications. I even wrote one myself back a ways:

[https://www.exratione.com/2013/12/considering-speed-and-
slow...](https://www.exratione.com/2013/12/considering-speed-and-slowness-in-
angularjs/)

There are definitely other issues worthy of attention, such as learning why
you don't factor your application into directives everywhere, learning to
avoid all the normal global variable issues with $scope, and the very mixed
quality of the documentation - sometimes good, sometimes encouraging outright
bad design choices, sometimes lacking very necessary detail.

------
jonpress
I think it was a huge mistake to announce Angular 2.0 so long before its
release date. In the open source world, you should aim to release the product
BEFORE you even announce its existence, not the other way around!

When you release first, you get valuable feedback from early adopters and you
get an opportunity to add finishing touches without upsetting too many users.

When you announce first, you are effectively labeling your current release as
stale/outdated and no one wants to build a new project on legacy technology!

As for AngularJS itself; I think it's fine structurally. I don't find it too
'monolithic' \- I think it strikes a good balance.

You could use something more modular (single purpose) like React, but then
you'd end up building a whole custom framework on top of it (made up of a
large range of small libraries) to handle things like routing and
data/validation layer, etc... Is using your own custom framework (made up of
so many small <and potentially less than compatible> open source components)
really better than using a single cohesive solution which is maintained
externally (for free) by the open source community?

------
dazhbog
What is the framework you hate the most? The one I am using right now!
AngularJS has been a love and hate, feature and bug library in my stack. Many
times I tried to run away.. I tried Rivets (easy but a pain to do binding),
React, looks promising but needs some serious investment, Ractive, cant even
remember what I didnt like.. oh well..

------
kennu
Angular.js should be considered a tool that solves certain problems well and
some other problems less well.

In my book, Angular (when used with Yeoman's generator-angular-fullstack) is a
high-productivity tool that immediately generates a fully functional, well
structured MEAN application that's very easy to extend. You get something
useful running in less than an hour. That's perfect for prototypes and
internal enterprise apps where productivity is more valuable than performance
or SEO.

OTOH if you're working on a big web app that will take months to develop, you
might as well spend more time building the foundation, and also choose a
framework that provides server-side rendering, high DOM performance and things
like that.

IMO most of the bickering related to JavaScript frameworks is just people
using them for different purposes, and one person assuming everybody else will
use them for the same purpose as she does.

------
UnoriginalGuy
With free Windows 10 around, dismissing older browsers MIGHT be more realistic
than today. Then we only have the Android 2.xx legacy to deal with. XP users
have absolutely no excuse.

~~~
hippich
Totally unrelated, but I don't think XP still used because customers don't
want to spend money on upgrade. More likely because some part of their
business tied to technology which tied with some XP components.

~~~
ddoolin
I didn't invest a whole lot of time reading about it, but when they ended
support for XP a lot of whining was from business owners who either couldn't
or were too cheap to upgrade.

------
modnine
I blame things like todomvc, which I think is great in spirit, but a huge
menace in practice. It gives people false hope that framework x will solve all
their ills. Any SPA that is more than trivial requires engineering skills.
Additionally, it is likely that you'll be building said SPA with a team of
developers who have varying skill levels. From my experience, a framework
should provide a certain amount of level-setting (as opposed to something that
is 100% custom) for new team members. However, there is nothing stopping
people from putting data access logic in controllers or polluting the views
with complex logic. Those sorts of mistakes can and will happen regardless of
technology. The key is to pick the right technology for your team and the
problem at hand and stick with it.

------
ahoge
> _Angular 2.0 [...] doesn 't fix any of today's problems_

Directly followed by:

> _Views and data-binding are a mess, and seriously degrade performance_

Want to have your cake and eat it, too?

Angular 2.x does simplify things quite a bit and it also offers much better
performance.

------
tomasien
I used Angular for the first time recently building a little example demo
based off a template that used Angular. It was so horrible to use in basically
every way, however some of the concepts (as noted in this article) intrigued
me. I would never use it again, but I do data-bindings are conceptually
correct, in that the DOM should have dynamic properties. Right now you do that
in jQuery or common JS by adding a class or ID and then binding manipulations
to that class/id or element, but that's obviously a hack.

The problem is Angular is ALSO obviously a hack and makes a lot of things
harder than they need to be. Oh well!

------
raspasov
I used AngularJS a for a little while about a year ago. It made you feel like
you're using a different programming language to overcome all the JavaScript
shortcomings, which is probably a good thing.

In any case though, it feels like all JavaScript frameworks out there are just
trying to overcome fundamental weaknesses in JavaScript the language. At that
point, I'd recommend looking into ClojureScript which is fundamentally a
better language. I've recently started using ClojureScript + ReactJS + Om and
it's been great so far.

------
sownkunz
We use Angular on our application and I can't stand it. The only thing I like
about it is how well testing is built in to the framework. Beyond that it is
far too complicated. Once your project really grows and you've got a huge
Angular codebase, with the sometimes inevitable rushed pace you need to work
in at a company, it just becomes a disaster. "Scope" crap everywhere that you
have no idea where to find what you're looking for.

Definitely would look into something else for my next project.

~~~
BinaryIdiot
This is what I've run into on every Angular project I've been thrusted into.
It goes from a somewhat decent separation to absolute chaos incredibly
quickly. While that's the developer's fault I don't feel like Angular lends
itself to extending and revising existing applications very easily.

~~~
EugeneOZ
This guide can help to keep code organized:
[https://github.com/johnpapa/angular-
styleguide](https://github.com/johnpapa/angular-styleguide)

------
lisa_henderson
The pain I've felt with Angular has been less about Angular itself and more
about the way it integrates with the backend frameworks I've seen it used
with. If the backend has a clean RESTful API, then Angular is not so painful.
If the backend has a complicated structure, then I find myself wasting epic
amounts of time trying to find templates, paths, etc.

Angular will make a lot of calls to the backend, but in general you can not
look at your Angular code and figure out where all the calls are going to the
backend. Complex URLs are often assembled from diverse variables that are
stored in varied locations. You can not grep for an URL because it does not
exist as a string. There is no equivalent to the "rake routes" command -- no
way to find out what routes Angular might use. I found myself opening the dev
console on FireFox and watching what Ajax commands were issued while the pages
loaded and operated -- which is a fine way to track down a call that is
working, but if a call isn't working, then it won't show up in the dev
console, and you are left trying to track it down.

There might be some structure or conventions that would allow us to find the
problem when facing a bug in our Angular code, but so far we have not found
it.

~~~
EugeneOZ
> in general you can not look at your Angular code and figure out where all
> the calls are going to the backend

Why? Can't imagine why you can't look at code of your services and figure out
where is URL.

~~~
EugeneOZ
No, really, REST API services in Angular usually have path to endpoint written
in the most top part of code (especially in $resource). So I really wonder how
it's possible to hide API endpoint URI there.

------
GroSacASacs
I created a library inspired by Angular
[DOM-99]([https://github.com/GrosSacASac/JavaScript-Set-
Up/tree/master...](https://github.com/GrosSacASac/JavaScript-Set-
Up/tree/master/js/libraries)). It is very near JavaScript in the way you use
it.

I search criticism to make it better.

------
ilaksh
This guy says he is thinking of using Aurelia instead. Aurelia mentions using
web components. If I can use web components now the why do I need Aurelia?

~~~
BinaryIdiot
Same reason you might use Polymer instead of raw web components: Polymer adds
nice polyfills, binders and observers and overall nice helpers to make
handling web components much easier than the raw standard.

I tried using straight web components with the polyfills; it gets kinda messy
compared to something more polished as Polymer. I assume it's the same deal
with Aurelia.

------
bikamonki
Using the DOM to keep state seems like a very smart trick to me. I liked that
about Angular when I first started learning JS MV* frameworks. I didn't like
the whole Angular way but I did copy that trick to my Backbone apps. I like to
use what I find smart and mix it on my solutions. Next up on my list is
virtual DOM.

------
JohnMunsch
[http://johnmunsch.com/2015/01/31/the-best-part-of-any-
angula...](http://johnmunsch.com/2015/01/31/the-best-part-of-any-angularjs-
troll-post/)

------
mmilano
This was posted and commented on a few months back here.
[https://news.ycombinator.com/item?id=8953366](https://news.ycombinator.com/item?id=8953366)

------
DigitalSea
I can share the pain. I have been using Angular for a long time now and I
avoid it as hard as I can now these days because it is so painful to use. When
you write Angular applications you're not writing Javascript you're writing
decorated HTML. I have actually been building a production application in
Rob's newer framework and Durandal successor: Aurelia. The thing I love about
it is you're writing ES6 Javascript and using standards based features. I
think we are reaching the point where we will see less decoration based
abstractions and more of just plain old Javascript in future frameworks.
Aurelia is just the beginning of what is to come. I have also been loving
React.js + Flux, but Aurelia more so than React these days.

------
ascotan
Major issues I have with angular:

1\. Doesn't play well with jquery.

Digest cycles and event passing don't mix. With any significant jquery plugin
you end up with $timeout(0) hacks (with or without the jquery being wrapped in
a directive). Since jQuery is the foundation of pretty much everything, this
is a torpedo that sinks the battleship. In addition, pulling in jQuery plugins
(awesome ones!) requires a major hackathon of wrapping the code in a
directive, figuring out why the events are always triggering, then throwing
some $timeout(0) hacks in there. ship it!

2\. No concept of M (model) in MVC/MVVC/MTV/M??

Data in the directives, data in the controllers, data in the services. oh my!
Once your app reaches a certain complexity you'll be doing WTF's as to where a
$scope.variable is actually being defined. (Oh i see it was defined in a
controller inside a directive that was inserted into the DOM dynamically via a
controller!?...)

3\. When things go wrong you have to dig too deep

Want to make a recursive directive? Good luck reading the docs on the $compile
phase. There are too many times that when something goes wrong with angular,
you end up in a deep well of tears trying to figure out why it's not working.
This creates a productivity problem.

Minor issues I have with angular:

1\. DOM pollution

old schoolers see adding non-standard tags in the HTML as 'code smell' for the
same reason that we no longer do 'onclick=alert('hi')'. Part of the reason
that this stuff was replaced with $('id').click() was that it created tight
coupling between the HTML and the dynamic code. By inserting non-standard tags
into HTML which requires the use of a 'compiler' you are no longer separating
the concerns of 'presentation', 'structure' and 'dynamic code'. I personally
find it distasteful, however, I can live with it (like a stinky roommate).

2\. Slow unit testing

One of the most touted features of angular is it's testability. However, 1)
virtually every angular component out there has no unit tests and 2) testing
directives and mocking out features is so time consuming that it brings
development to a crawl. I find that the mix of time spent on testing vs coding
is 50/50\. That is that for 1 day of coding you'll put in a full day of
writing unit tests. The reason is that testing angular is so complicated that
it takes that long to get it right. Unit tests are always a good time
investment, and that investment is not 0. However, if feel that a 50/50 ratio
is too high. Testing should be faster to allow devs to be more productive.

3\. Performance is easy to screw up

Reading some of the other comments I realized another minor issue. Performance
in angular is great. However, because angular doesn't have any real organized
(or patterned) way to create an app (you can make a controller or have a
controller in a directive), you end in a situation where the way you have
organized your code now creates performance problems. This is true in any
framework and with some training can be avoided. However, it appears that the
critical mass for this issue comes much sooner than expected due to the perl-
like anything goes feel to application structure.

------
brettster55
'and neither should you' is a pretty big blanket statement.

------
krick
Ok, nice, now tell me what I _should_ use. (Yeah, I saw his comment about
Ampersand, but still…)

------
wtbob
Perhaps so that his next project will be more than a blank page when viewed in
emacs-w3m?

------
nodesocket
>> Ask any junior developer who has used it briefly, and they’ll tell you that
they absolutely love Angular. In this sense it’s like giving candy to a child.

Here we go, another condescending, arrogant developer on his soap-box. Do you
know why Junior developers like Angular? Because it is quick, intuitive, and
you can rapidly release, just in the same way PHP and Ruby are. Are you
building applications for the sake of building them, or building something
users will use and love?

See:
[https://s3.amazonaws.com/m.helpscout.net/blog/2014/feb/devs-...](https://s3.amazonaws.com/m.helpscout.net/blog/2014/feb/devs-
vs-cust-2-19-14.jpg)

~~~
kristopolous
Sure, but I'm going to move myself into the line of fire by suggesting that
some frameworks can encourage the development of bad habits and anti-patterns
- especially those that prevent projects from being easily re-arrange-able in
the future.

Sometimes the choices made presumes a specific application is built and then a
junior developer over-commits to the current state of a dynamic application
and thereby precludes the application from easy future repurposing to match
the dynamics of the actual products intent.

What do I mean by that? You can call this "concreting the abstractions". The
abstractions given by frameworks have to be implemented in a concrete manner
in order to build the application - duh.

But then what you often get are ill-equipped abstractions layered on top
(square peg in round hole syndrome) and then the concrete implementation on
top of that.

Then the rug gets pulled out from underneath that.

The naivete of a Junior Anything is a lack of perception of the nuances of the
craft - an ignorance of the consequences of actions - and the wisdom to have
the right kind of deductive minimal execution to get from objective to
actualization.

All too often, the frameworks give you a bag of hammers and say "alright,
figure it out". With This approach, the limits of excellence are quite low.

This matters for the long term with the customers ... you want them ecstatic
and to follow you in a near cult-like fashion --- not just merely shrugging
their shoulders and cocking their head sideways as they abuse the product in a
disenchanted ritual.

Anyone can do that. There's no beauty or value there - and it's not how you
create a following. There is a meaning to art and mastery - when you do it
right, everyone gets it.

It's the unquantifiable quality that Robert M Pirsig discusses in Zen and The
Art of Motorcycle Maintenance, or what Tim Leberecht talks about in the
Business Romantic. These things matter - otherwise we are all soulless hacks.

------
EugeneOZ
lol, another one. People are free to use React, Angular, Ember, Backbone,
Meteor, VanillaJS, even brainfuck. You don't like something - don't use it and
calm down, stop being a bigot.

 _and yes, I 'm not polite and it's intended. Haters deserve to be hated._

