
Criticisms of Angular - andreapaiola
http://www.leanpanda.com/blog/2015/09/20/our-criticisms-of-angularjs/
======
IgorPartola
Sometimes I feel like I'm the only one who actually likes Angular. Two way
data bindings are very convenient for writing UI. I don't want to write an
event listener for every onclick, onchange, and onkeypress. I want the values
in my models and the values in the DOM to be in sync. I like using nearly
straight up HTML as my template. I do this in Django, so why not in Angular? I
like that I don't need to render things server-side because then the server is
just running a REST-ful API. That way I can write different clients for the
API and don't have to change the server (mobile app, desktop UI, etc.) I like
the clean separation between presentation (HTML templates), UI logic
(controllers), and communication (services).

I feel like Angular's biggest problem is the documentation. It starts out
talking about things like dependency injection and why that's good, instead of
simply displaying how to use the framework. It's got a steep learning curve
and it just seems that people get scared of the documentation and run away
before they really give it a try.

~~~
lhorie
> it just seems that people get scared of the documentation and run away
> before they really give it a try

Anedoctally, as the author of another JS framework
([http://mithril.js.org](http://mithril.js.org)), I see a lot of people
migrating away from Angular due to complexity, bloat and performance issues.
I, myself, spent a good two years wrestling w/ Angular problems full time
before jumping ship. Our apps were quite complex and we were fully invested in
trying to make Angular work, and definitely not just making a half-assed
effort to like it. So it's definitely not just newbies.

~~~
code_sterling
I like Mitiril, but the way you manage your view layer doesn't work for me.
I've tried several "build a Dom in code" approaches before, and they haven't
proven to be very maintainable in the long run, especially for larger and more
complex solutions. Additionally, the cost of migrating an app is much much
higher.

So while this post is mostly FUD, your points are valid, I feel all frameworks
come with a tradeoff.

~~~
davexunit
I love Mithril's (and other's) "build a DOM in code" approach. Traditional
templating systems are always limited domain-specific languages that add lots
of complexity for things that should be simple, template "partials" and
iteration come to mind instantly.

Making the virtual DOM tree a first-class value that can be treated as a
persistent data structure is a huge win. Templates are functions that return a
virtual DOM node. Rendering a list is a map from Thing -> virtual DOM node.
Redundant rendering is avoided with memoization. "Partials" are just
functions. The system handles escaping and prevents XSS vulnerabilities by
distinguishing plain strings from DOM nodes, which string-based templating
systems do not do. All of the complexity and difficulty of working with
templating systems goes away when we can just use the usual functional
combinators we all know and love to compose views.

On top of Mithril, I recommend working in a functional reactive library
(Kefir, Bacon, Rx, whatever else) to make the whole application declarative
and functional. Angular just doesn't compose well with other things like
Mithril and other primarily functional libraries do. I should really write a
blog post on this.

~~~
Touche
> On top of Mithril, I recommend working in a functional reactive library
> (Kefir, Bacon, Rx, whatever else) to make the whole application declarative
> and functional.

How are you using an FRP library with Mithril? I thought with vdom libraries
you never touch the real DOM.

~~~
davexunit
Mithril allows you to declare callbacks for the various DOM events on the
virtual DOM nodes. This is where you glue in the FRP library. A callback will
set the current value for one of the roots of the signal graph.

------
SonicSoul
This is a rehash of the same problems that have been circulating for years
[0]. There is literately not a single original thing here. Most of these
issues are gotchas that can easily be avoided once the developer is aware of
them (such as scope inheritance / dynamic scope which is due to Javascript
Prototypal Inheritance [1]).

What's ironic is that angular 2 is fully rewritten in part to fix all of these
issues, but none of that is mentioned, and the only focus is on how much
Angular 2 sucks because it's not compatible with 1. There is also no mention
of clear migration path and ability to run angular 1 and 2 side by side [2]

I've put 4 Angular sites in production and never faced issues due to any of
these problems. I've had issues with caching, end to end testing of ajax
calls, sharing functionality with non angular parts of the site. The very fact
that the OP listed these issues tells me that he's not actually used Angular
in production. Angular 1.x has limitations for sure but it works quite well in
most scenarios.

[0] [http://larseidnes.com/2014/11/05/angularjs-the-bad-
parts/](http://larseidnes.com/2014/11/05/angularjs-the-bad-parts/)

[1] [http://jimhoskins.com/2012/12/14/nested-scopes-in-
angularjs....](http://jimhoskins.com/2012/12/14/nested-scopes-in-
angularjs.html)

[2] [http://angularjs.blogspot.com/2015/08/angular-1-and-
angular-...](http://angularjs.blogspot.com/2015/08/angular-1-and-
angular-2-coexistence.html)

EDIT: shortened. EDIT2: added conclusion

~~~
snorrah
Where is this focus about Angular 2 sucking? The author is in fact happy about
Angular 2 being a re-write. Read the section under Problem 6, where he calls
the proposed complete re-write of Angular courageous and laudable.

Now he says this is a problem for Angular 1.x because there's no carry-over of
knowledge into 2.x, but that's in no-one saying Angular 2 sucks like you are
suggesting.

~~~
SonicSoul
you're right, that was not the best way to put it. I just saw this which
seemed like focusing on negative w/out noting that all his complaints will be
addressed.

 _Not convinced yet? Well, what if we were to tell you that the next major
version of Angular will take a scorched earth approach to the existing
structure that means it will have zero retro-compatibility with what exists
today?_

------
nateabele
So, they trot out the same tired arguments against Angular that people have
been making since the beginning, and this makes the front page where people
engage in serious discussion about it?

Did I miss some subtle novelty about this post, or is Angular ennui just that
popular on HN?

~~~
fein
Not to mention his example is just straight wrong about $scope and ng-if.

His JSFiddle examples are all using angular 1.1.5. Angular 1.2 properly binds
scope inside an ng-if.

I agree that angular 1.1.5 had it's warts, if that's what this is supposed to
be about. The current release version of angular is 1.4, about to be 1.5.

Edit: After fully reading through this blog post; it's almost all wrong.

Dirty Checking: Yes, we have have to sacrifice ease of use for performance
sometimes. So keep it in mind and don't make so many simultaneous data
bindings. Why you would need 2000+ in any given state(ui-router)/route is just
mystifying. Don't abuse ng-model.

Dependency Injection: Are you kidding me? He's not even using the array
notation for proper DI with minification.

Pointless Complexity: This is an actual valid argument, and the only one on
the blog. Google has some pretty bad documents for angular, especially when
describing directives that isolate scope.

Server Side Rendering: Uh, the whole idea behind stuff like angular is
decoupled frontends from your server. Build a REST API and point angular at
it; no need to ship layout code with services.

Angular 2: There's an upgrade path that should allow the two to exist in
tandem. There's no reason to not keep writing angular 1.x code right now. It's
not like Angular 2 being released means all your previous code is worthless.

~~~
DougWebb
_Dirty Checking: Yes, we have have to sacrifice ease of use for performance
sometimes. So keep it in mind and don 't make so many simultaneous data
bindings. Why you would need 2000+ in any given state(ui-router)/route is just
mystifying. Don't abuse ng-model._

As someone who's going to need to make a recommendation soon about whether or
not to use Angular on a new project, this part worries me. The apps my company
builds are full of data grids (Enterprise CRUD-based stuff) and it's entirely
reasonable for us to have a 100-row grid with 20 columns as just _one_ of the
components on our page. So that's 2000 data bindings right there just for the
data values. We'd also have metadata on every cell bound to classes and
validation state. If we allow in-place editing, a single one of those fields
can be updated. We can't have the entire grid re-checked after every update if
that's going to hit the limit on acceptable performance. We'd need to limit it
to the row (eg: cross-field validation rules) and elements outside the grid
(eg: change toolbar button states.)

Does Angular 2 have similar limitations? Should we wait for Angular 3 and
Object.Observe?

~~~
fein
Might be a nasty pill to swallow, but in most cases, populating a grid with
2000+ bindings is in the area I'd call bad UI.

However, I don't think that the performance hit you would take would be that
noticeable depending on the implementation.

Here's a jsperf test that can demonstrate angular performance with 10k
watchers:

[http://jsperf.com/angularjs-digest/72](http://jsperf.com/angularjs-digest/72)

Chrome 45 gave me about 3.2k ops/sec

~~~
DougWebb
_Might be a nasty pill to swallow, but in most cases, populating a grid with
2000+ bindings is in the area I 'd call bad UI._

Totally agree, but my business is auto-generating fully-featured applications
based on database schema inspection and a code-generation wizard, for clients
with large enterprise databases. So the app has to work reasonably well with
out-of-the-box generation before we start tweaking it to customize and improve
the UI for the most important tables and most common workflows.

Thanks for the jsperf test. It's good to know the range of results for
different browsers. Our app needs to run on everything, including Mobile
browsers, and that test proves that we can't get away with using the typical
Bootstrap responsive "hide some columns for xs" approach. We need to not
generate markup for most of the columns at all. That means we're going to have
to enhance our generation wizard to let us specify, per-table, device-size-
specific column lists instead of just a single column list.

------
shubhamjain
I haven't tried Angular yet but have built applications in React. In my
opinion, frameworks like Angular suffer from a fundamental problem, that, it
is almost impossible to gauge the problems of a new design unless you have a
built a medium - large scale application with it which is very hard when you
are just experimenting. There might be few heuristics, few rule of thumbs one
can follow but still it will be hard to see if the ease - effort ratio will
make the framework worthwhile. You can make things too "magical" and also too
"worthless".

I guess that's why everyone complains that it is easier to build a Todo
application in Angular but the troubles grow as you grow bigger. The reason
why React is successful might be they did get a chance to experiment the
architecture on their own things before releasing it to the public.

~~~
hellofunk
I've never understood any comparison between React and Angular. To me it seems
like trying to compare a slick car to a fancy car garage. They try to solve
quite different problems, right?

~~~
lojack
> They try to solve quite different problems, right?

Sort of. The problem React is solving is a subset of the problem Angular is
solving. It's a bit more like comparing an older model sports car to a modern
engine.

~~~
astazangasta
A modern engine that also insists on doing your taxes.

------
nioufe
While the author makes some fair point about angular's weirdness. He fails to
understand that many design choices where made because javascript and js
libraries were not as advanced as today.

For example the module system is made so because at the time, amd, browserify
and ES6 modules were not ready.

And the main point of angular 2 is not to remake angular because it was weird,
it is to adapt it to new technologies.

------
stupidcar
When the author doesn't understand the difference between a module system and
a dependency injection system, it's hard to take the rest of what he says
seriously.

~~~
troels
They kind of solve the same problem, but in different ways. I, for one, think
it's debatable if the 800 lb gorilla that is dependency injection has any
merit in javascript.

~~~
emsy
DI is not an "800 lb gorilla". If anything, certain implementations of DI
frameworks are (I'm looking at you, Spring).

~~~
troels
I disagree. They were a solution to the inflexibility of rigid languages like
Java, but seems entirely alien in the context of Javascript. A DI framework
adds a load of indirection.

~~~
brodo
DI is a design principle, not a class for frameworks. DI just means to
"inject" the dependancies of an object through constructor arguments, setters
or by simply setting instance (aka member) variables. In other words, DI means
that you don't use global variables (aka singletons). DI does not provide any
more flexibility itself, but most DI frameworks encourage the usage of
interfaces instead of concrete classes (which is a good thing) when it comes
to defining dependancies. Sadly however, the fancy pants therm for using
interfaces is "dependency inversion", because when using interfaces, the
compile time and runtime dependancies of a class point in opposite directions.
As you can imagine, this lead to a lot of confusion.

------
rbalicki
Valid criticisms of Angular include that it gives you enough rope to hang
yourself, that the documentation/tutorials teach you to code Angular in a bad
way (abuse the $scope object, etc.) in the interest of making it "easy" and
that the terminology and symbols used can be simplified.

However, once you learn to avoid Angular's pitfalls, it's a very powerful tool
for creating large apps that do not collapse under their own weight.

To illustrate, how often do experienced Angular devs make $scope inheritance
errors? If you are, you're not using controllerAs syntax and are coding
sloppily. No framework can save you from sloppy coding.

~~~
spmurrayzzz
One of the trends I've seen in my own hiring is that many Angular devs lack a
solid understanding of fundamental JavaScript (closures, prototypes,
functional programming, DOM API, async patterns, et al). This may be a
function of how much the framework is able to abstract away from the user.

This dearth can lead to lots of code smells, bugs, antipatterns, and other
grenades that can present significant problems at scale no matter what
framework you choose to go with.

So if it's true that many Angular apps have problems at scale — one hypothesis
would be that it may be a reflection of the selection bias of those who choose
to use the framework. Which is not to say that advanced JS people aren't using
the framework (they clearly are) but anecdotally, upwards of 90% of the
Angular-based devs I've interviewed or interacted with personally lack an
understanding of many of the aforementioned JS fundamentals.

~~~
rbalicki
Perhaps the scaling problems are also because JS only became a "real" language
in the past few years. Beforehand, there wasn't much need for coherent app
structure because large apps were impractical.

------
Antwan
"With the next article we’re going to introduce you to React JS, [...] that
have won us over entirely."

How can you take the article seriously with that kind of conclusion.

~~~
apeacox
why?

~~~
fridek
Because React solves only the directive part of Angular? I'm not saying it's
great BTW, but comparing React to Angular is silly. That's like saying you
chose lodash.js over Angular.

~~~
kcorbitt
This was probably a valid observation two years ago, when the React story on
state management was "bring your own solution." But these days, although it's
technically a separate project, Flux is the de-facto state management solution
that a React-first webapp will use. There are lots of competing
implementations (I use redux) but my point is that you'd be hard-pressed to
find an app written in Angular that couldn't also be written using React+Flux.
Of course the architecture is going to look different, but you can certainly
get to the same place.

~~~
fridek
Sure you can. And as I said, I'm not a big angular lover. In fact we used
Backbone for REST in it, because of shortcomings of the $resource at the time.

And flux is great and React-first, but it's not technically a part of React.
And it is also great, having a choice is usually a good thing.

Still I'm skeptical when people are happy just because they moved from angular
to react. Or from any X to Y really. Usually the gain comes more just from
rewriting things with better understanding of the project and from more
established team. No one does A/B studies on it, right?

------
protonfish
He missed so much. How about non-standard invalid HTML? Breaking all
searchability and accessibility? Encouraging voodoo coding?

~~~
Loque
This was the deal breaker for me when first looking at Angular - loose
coupling, progressive enhancement, accessibility and keeping code in its
appropriate layers seemed to get thrown out for an attitude that everyone has
JS running... it felt like a return to the days of Flash.

I could ramble for a long time about it, anecdotally; I have peers who use
(and seem to enjoy using) Angular (all .net devs), and others who point out
its flaws (front-end architects). I find it a very interesting discussion
point.

~~~
ohnomrbill
While I'm sure this gets abused, I think many of the people who use and enjoy
Angular limit it to developing web apps. When I use Angular for something,
it's a true web app, and I need to be able to execute client side code. When I
have static content, I would just use HTML + CSS.

If you're using Angular, the use case might justify the attitude that everyone
has JS running. The same people who hold this attitude when making an Angular
app might build perfectly serviceable sites to deliver static content without
JS.

------
pwfisher
Our company had two Angular codebases, the public site and our internal site.
Experience in one taught you nothing about the other because there was no
"Angular way" to structure your code.

Having "enough rope to hang yourself" while our devs were just learning
Angular led to an unholy mess. Development slowed to a painful crawl.

We hate Angular. We're an Ember shop now. We love Ember!

Angular gives you enough rope to hang yourself. Ember lets you stand on the
shoulders of giants.

~~~
SonicSoul
Interestingly I've heard similar sentiments from Ember developers, mainly that
it is much more 'opinionated' than Angular.

In my experience with Angular there is a pretty clear logic on how to
structure code. I suppose that logic is not enforced so there is nothing to
stop developers from just cramming all code into index.thml. Being a dev
manager I've adopted feature structure [0] and it has worked quite well across
all our apps.

Furthermore there is pretty clear distinction on what kind of logic should be
included in controller vs service vs factory vs module. This has made writing
unit tests a breeze in my experience.

I'd be curious to hear what Ember constructs exist that helped you so much.

[0] [http://www.johnpapa.net/angular-growth-
structure/](http://www.johnpapa.net/angular-growth-structure/)

~~~
trophygeek
I'm a bit behind on this thread and I am an Angular guy myself, but I think
Ember is moving this direction.

[http://www.programwitherik.com/ember-
pods/](http://www.programwitherik.com/ember-pods/)

------
neals
I work as a JS contractor on large custom e-commerce configurators. In the
last few months I've learned that Angular is not built for large custom
e-commerce configurators. Just my 2c /

------
SFjulie1
You have the calvinist way of coding: learning, coding, and working harder to
improve. Believing that experience will help you build a greater skill. You
put your faith in yourself and hard work. You aim for simple elegant code that
talks less and does better. You believe more in efficient design than in code:
you are a programmer, not a coder.

You have the catholic way of coding: believing in a framework like a church
and venerating a bloated edifice with multiple weaknesses to support your most
complex code.

Most of the angular coder I have met are just lazy coders believing in magic
and tradition not wishing to see coding has a hard earned skilled acquired by
craftsmanship.

Coding is not a "tradition", it is a "Beruf".

I am a protestant programmer, and I believe I will achieve better code with
more hard work and learning than by venerating any bloated layers in between
that will come in my profound gained understanding of programming.

[The one relying on his hard work] is like a man building a house, who dug
down deep and laid the foundation on rock. When a flood came, the torrent
struck that house but could not shake it, because it was well built. (Luke
6:48)

PS: I do angular. I fix my colleagues' works and it always make me want to
puke to dig in this insanity everytime.

------
choward
This article is about 2 years late. These are solved problems in angular 2 by
default and have solutions in angular 1.

= Problem #1: Scope inheritance and dynamic scoping

Use directive controllers

= Problem #2: Dirty checking

Use immutability

= Problem #3: Dependency injection

I'm not really sure what the author is saying here. It sounds like he's
confused and thinks DI and modules solve the same problem. The one statement
he has bolded is completely false: > Angular forces you to use a third, custom
designed alternative mechanism: one that is inferior to the already existing
mechanisms available. You can use a module system if you want. Nothing is
stopping you.

= Problem #4: Pointless complexity

> providers, values, factories, services, constants [...] All five concepts
> could easily be assigned a single identity. True, so just use providers if
> that makes you happy. Angular 2 also simplifies things.

= Problem #5: Server-side rendering

He stated a solution for angular 1. Personally, I don't really care about
server side rendering so I won't elaborate. Angular 2 will have angular-
universal

= Problem #6: Angular 2

> Not convinced yet? Well, what if we were to tell you that the next major
> version of Angular will take a scorched earth approach to the existing
> structure that means it will have zero retro-compatibility with what exists
> today?

> it would be simply foolish to use Angular 1.x for new applications.

LOL, fear mongering. The angular team has already stated there will be a
migration path to angular 2. They also announced they will continue to support
angular 1 as long as people are using it. It's funny that he complains about
angular 2 when it addresses his problems with angular 1.

~~~
p3llinor3
Oh! So just have a bunch of arcane design patterns instead of using the tools
packaged with the framework! Sounds great...

------
maaaats
Funny that the last complaint is that Angular2 will break a lot of stuff, when
it will actually fix most of the issues he's mentioning above. One can never
win.

------
wmil
I always feel like scope inheritance problems are overstated.

It's weird, but it's weird in the exact way that JS prototypical inheritance
is weird. So it's important to learn.

Anyways the fix is simple, always initialize your variables before you use
them. Either in the controller or using an ng-init.

------
juristr
Nowadays: want lots of traffic on your blog -> rant about Angular.

The problem is just that you're nearly a year too late.

\- yep angular has flaws (which framework doesn't?)

\- ya, it does dirty checking and yes, that might have perf implications if
used the wrong way. But hey, 6 years ago when Angular was created it was a
revolutionizing idea, and still holds today. Also, at that time no
Objecte.observe existed, nor did SPAs really (well..GWT was kinda the solution
at that time). But, did u check what they're doing in Angular 2? Heard about
RxJS and stuff?

\- DI: strange syntax techniques to work around minifiers? You don't really
use those, do u? heard about ngAnnotate?

\- Oh...AMD, UMD etc...do not dependency injection. And yes, agree, DI
together in combination with AMD/UMD/... creates confusion with newbie
frontend developers

\- Then: Angular 2 is already live on GitHub, for a while; has even it's own
webpage online

\- and for god's sake..Angular 2 is compatible with Angular 1...read their
blog posts, their Tweets, weekly meetup notes and design docs (all openely
available on GDocs)

\- oh..and there are even some rumors server-side rendering will be possible
in ng 2

I like ur blog, but if you go and rant, please check the latest status, inform
yourself, then rant. Nothing against critics, they foster discussion, but only
if made properly.

------
Kiro
OT: why are they using "BazaarJS" in the titles of both this and the post
they're linking to but "BazarJS" everywhere else in the articles?

~~~
apeacox
"BazarJS" is a series of articles about JS frameworks, pre-processors, etc...
they already published the same in italian language some months ago. now
they're re-publishing (with eventual updates) the same in english.

------
narrator
They announced recently that there will be an easy Angular 1 to Angular 2
migration path.[1]

I think Google is getting blowback from the "worse is better" crowd that have
supported the meteroic rise of c, php and mongodb. Specifically, the "worse is
better" belief that:

"There is a point where less functionality ('worse') is a preferable option
('better') in terms of practicality and usability." [2]

reminds me of his criticism of "excessive" features in Angular, even though
those features are there for a reason.

Usually, what happens with "worse is better" is that when people start missing
key features, a bunch of bolt on pre and post processor tools show up to add
features (e.g linters, "strict mode",Mongo migration tools) that weren't
needed in the more complete solution.

1.[http://news.softpedia.com/news/google-releases-guide-on-
how-...](http://news.softpedia.com/news/google-releases-guide-on-how-to-
migrate-from-angularjs-1-x-to-2-x-490106.shtml)

2.[https://en.m.wikipedia.org/wiki/Worse_is_better](https://en.m.wikipedia.org/wiki/Worse_is_better)
[fixed]

------
aikah
Say what you will I like Angular 1. And there is a ton of resources and books
all over the web to help.There is a solution to everything and it's pretty RAD

However, I'm very skeptical about Angular 2. For several reasons. First (I
tested it) right now, it is way too complex and unnecessary verbose.

They wanted to support future techs like web components, observables (reactive
functional programming) which are great, but it's not that easy to use.

Some people will not like the Rx approach which forces one to rethink the way
one codes. There is serious mental gymnastic involved here when one has to
think in terms of cold and hot streams, especially when one is used to ng1.

Of course, people who love Typescript will enjoy it,and it's true it's easier
to figure out what is what with explicit types, but people who are sticking
with ES5 for various reasons will hate all the boilerplate needed to get
started.

And they went crazy with dependency injection,this time, this is a divisive
issue among programmers and while ng1 DI was light weight, ng2 DI is going
full Java which Java/C# folks will like, but i'm not so sure about the rest.

The biggest question is, how is ng2 relevant compared to React + Flux/Relay?
since it tries to do the same thing but with more complexity? with that weird
template syntax ([attr-read-from]="variable" , (event)="handler" ,[(read-
write)]="variable", *template-directive="expression" ... )? React has JSX
which is a serious advantage.

ng2 will be ready in a year at best but businesses can be tempted to just move
to React in the meantime and then stick with that.

.

~~~
Bahamut
I think if a business needs to, I would recommend they move to React now -
Angular 2 is shaping up to be quite impressive, and taking pretty much all of
the lessons that Facebook has brought with React (& possibilities brought
about by the generally clean architecture such as server-side rendering,
native mobile app support, etc.), and refining it ruthlessly, but you can only
use what is available if you are consuming a third party library. Once Angular
2 is ready though, I would only consider using it in a new project unless the
company is already deeply invested in React (or other tech) & doesn't have the
time to migrate.

Angular 2 is still rough today, and that is why it is still in alpha - the
Angular team is still trying to figure out what do they need to expose in the
framework for consumers to build flexible components. In addition, the testing
situation still needs to be refined some. The UI Bootstrap team is in the
beginning of migration to Angular 2, and we already came across some pain
points that Google is working with us to try to ease as much as possible.

As far as ng2 vs. React - ng2 uses pure HTML templates still. ng2 manages to
use this and still optimize dramatically over React due to how change
detection works in Angular. The template syntax is not complicated once you
get used to it - it is much easier than remembering all of the edge cases that
JSX has had to write around (i.e. className) due to issues of conflict with JS
itself, and certainly much easier than remembering all of the little caveats
and edge aspects of ng1.

Web component support for Shadow DOM is opt-in, and it does use the template
tag for custom components. Observables have some overhead, but the great thing
is that it is optional for many things, and easy to use when something is
exposed as an observable.

The Angular 2 DI is much better than the Angular 1 version - it is much more
powerful and doesn't require a hacky implementation due to its use of
decorators.

~~~
aikah
> ng2 manages to use this and still optimize dramatically over React due to
> how change detection works in Angular.

That's what the angular team claims yet, there is absolutely no proof that ng2
templates are faster than React, and I did my own benchmarks. You can say
"it's still alpha" , but if speed is a business requirement for ng2, alpha
doesn't fulfill that promise.

> The Angular 2 DI is much better than the Angular 1 version

Better or more verbose and complicated ? I just don't want to do that kind of
DI in the front-end. It will lead to people over engineering their code bases.
It will lead to bad and verbose code, everything what front-end development
should not be.

~~~
Bahamut
Actual benchmarks would disagree with your claim - the Meteor team did a
benchmark and found Angular 2 significantly faster than Angular 1 (I hope so),
React, and their own Blaze. The perf gap increases dramatically with the more
DOM elements worked with - the best part is that the Angular and Meteor team's
benchmarks are both open source! (The Angular team does not compare with
React, just Angular 1 and a baseline of no JS generated DOM)

The problem I have found with most codebases written with angular is by far
the underengineering put into it, sometimes to an appalling degree. The new DI
is pretty simple - specify an array of services, or just define the array
elsewhere and import it in and set it to a config onject. There is not much
complexity on the user's side.

~~~
aikah
> the underengineering put into it,

There is no such things as underengineering, given specific business
requirements. On the other hand, writting useless code is something I often
see with people abusing IoC containers like Spring. If a minimal codebase
passes the acceptance tests it is not "underengineering" ,it's actually doing
one's job as a developer.

Anyway i'm really against the lack of pragmatism in the new DI. But don't
worry , by the time ng2 is realised you'll see an avalanche of blog posts
about how horrible it is. Mark my words.

~~~
Bahamut
There is such a thing called underengineering - it happens quite often at dev
shops where developers do not plan their code out with flexibility, clarity,
and modularity, where you run into poor abstractions that are inflexible
because not enough thought went into what approach would work best for
potential business needs...and unsurprisingly, that sort of code often is
difficult, if not impossible, to properly test.

Re: ng2 DI, I disagree, I have used the ng2 DI system for almost a year now,
in production code as well for a large part of it.

The new DI is decoupled from any framework, allows multiple injectors, avoids
verbose hackiness, and is more natural to use - all significant improvements
to ng1. There is literally nothing lost, only additions in terms of features
and flexibility.

------
fridek
"I’m not joking: we were perfectly able to get by in one of the Angular
projects developed internally — consisting of around 200 Javascript files and
a total of around 10,000 lines of code — using only factories."

Funny, I could agree this is true for providers or services. Factories however
can't be used for singletons, so I'd rather not know how they implemented
shared state and utils.

~~~
scotty79
Factory is just a function. It can easily instantiate and return singleton.
You just call it instead of using `new` on it at the place of use. It's
probably not very nice from philosophical standpoint but it can have its
merits.

------
gizi
Angular is the answer to another question than the question that I usually
face. So, the usability guy and the graphical designers have produced HTML/CSS
page designs that work well and look good. The purpose of the javascript that
I will be adding, is to make sure the user interface functions. Faced with
these requirements, I have never been in a situation in which I felt that
something like Angular would be able to contribute anything useful. If you
drag Angular into the fray, it will be the most important kid in the room that
you will need to constantly babysit. Forget about what you want to achieve.
Think of Angular first. Everything else is unimportant ...

------
omouse
Angular's dependency injection system is much much better than dealing with
CommonJS/AMD in my opinion. I would be okay with ES6 modules too but
apparently those aren't getting much love yet.

The scoping in AngularJS can be a bit of a pain but I mean, if you know it's
dynamically scoped and you know that the directive (ng-if) is introducing a
new scope then it isn't the end of the world. Emacs has dynamic binding and
it's been working on pretty well so far and contributes to extensibility.

I wonder how the author would convert Angular to use lexical scoping instead
of dynamic scoping; would it even be possible without forcing all directives
to have a lot of boiler plate?

------
a-guest
Angular may not be perfect, and there are lots of other tools out there, but
Angular definitely remains an option to get the job done. And when articles
like this pop up, I wonder if we all unconsciously fall into the trap of the
"Fallacy of the Perfect Framework" described by Shawn Wildermuth in a recent
post. As if moving from one framework to a different one, we will all of the
sudden have no more problems and everything will be "perfect".

[http://wildermuth.com/2015/09/01/Angular_v_React_v_Aurelia_v...](http://wildermuth.com/2015/09/01/Angular_v_React_v_Aurelia_v_et_al)

------
vikingcaffiene
> Problem #1: Scope inheritance and dynamic scoping

Easily solved by using the controllerAs syntax

> Problem #2: Dirty checking

One time binding to the rescue here. Been available for a good while now.
Dirty checking does suck though but is usually not a deal breaker.

> Problem #3: Dependency injection

The authors main problem here seems to be with problems minifying the code.
All one needs to do is to pass in an annotations array which is an established
best practice. So instead of controller('ControllerName', function($scope,
$someService){}) one should use controller('ControllerName', ['$scope',
'$someService', function($scope, $someService){}]) there are other more
readable ways to do this such as $inject but I digress.

> Problem #4: Pointless complexity

This is debatable and more a matter of opinion. I disagree and think the glut
of the authors woes come from not taking the time to understand the framework
properly. The learning curve is steep yes but I've used a TON of javascript
frameworks and Angular consistently comes out the winner long term in
maintainability and stability.

> Problem #5: Server-side rendering

Isomorphic javascript to the rescue here. React does it better in this case
but its available if you need it. Angular is a single page web app. If you
knew that going in and have a problem with it now... well lets just say that
its important to understand the trade offs that come with any technology one
chooses to include in their stack.

> Problem #6: Angular 2

Yes this was a concern, and then the angular team listened to the outcry from
the community and now have been developing a migration path for users of the
1x code. They have also dedicated an entire team to continue development on
the 1x codebase for as long as it remains popular thats why there are two
angular websites.

While I admit that angular isn't perfect (literally nothing is) nearly all of
the authors criticisms are due to lack of following best practices. You can
find a pretty good summation here: [https://github.com/johnpapa/angular-
styleguide](https://github.com/johnpapa/angular-styleguide)

------
weatherlight
I love Angular but I often find when I look on StackOverflow for a better way
to do something that the most upvoted "solution" is often the WRONG
way(Abusing watchers, Abusing $scope, etc) to do something and often
contradicts what's in the Angular docs. I can't help but think to myself, "No
wonder people hate angular. There's so much bad documentation(Official and
Unofficial) and hacky solutions out there. No wonder people are having a bad
time."

------
tkinom
Is Angular really that popular? From google trend, Jquery is still 3-5 times
more popular then Angular, React. What do you guys think?

[https://www.google.com/trends/explore#q=jquery%2C%20angularj...](https://www.google.com/trends/explore#q=jquery%2C%20angularjs%2C%20angular%2C%20react%2C%20reactjs&cmpt=q&tz=Etc%2FGMT%2B7)

~~~
CitizenKane
In terms of Single Page Application frameworks, Angular is very popular.
Comparing it to jQuery doesn't really make sense as jQuery is a utility
library and doesn't support all of the features that Angular has.

------
spleenteo
for the record: in the second paragraph we can find this sentence:

> we’ve been working with Angular for almost nine months now (the original
> article in italian is dated February 2015)

it means this post is just a translation of something experienced a year ago
(Angular 1.1) A half of the comments reply to solutions arrived on 1.4, with
hindsight.

This delay is definitely not clear, but casts new light on the content.

------
stuaxo
This is all true, but it is still one of the best options for making websites,
onwards and upwards !

~~~
yogsototh
We use reagent with success. We still have some legacy code in Angular. Each
time we need to change something in that old code, it reminds us how Angular
has done a lot of things wrong.

We often qualify Angular as the J2EE of the front.

------
iridium127
It's not worth obfuscating the web for what Angular brings to the table.

------
ldpg
The #6 complaint on "server-side rendering" calls the rest of the article into
question. This illustrates a fundamental "missing the point" of either Angular
or React. Client-side templating is one of the essential ideas.

------
brightball
Things like this reaffirm my old guy decision to do as little in the browser
as humanly possible.

EDIT: Warranted a downvote. Wow.

------
robotnoises
I need to get my butt in gear and finish-up my blog on criticisms of
criticisms of Angular.

