
Why you should not use AngularJs - caisah
https://medium.com/@mnemon1ck/why-you-should-not-use-angularjs-1df5ddf6fc99
======
hippich
I am working on a large app based on angular (not my decision - I voted
against it :)), and felt many pain points already, from poor design overall,
to crappy extensions most of the currents apps are using.

It Kinda reminds me whole Wordpress thing. Really subpar codebase - but at the
same time very easy to make simple things, and as a result - a lot of
popularity. And this comes not as surprise to see so many blog posts comparing
Angular to jQuery...

But perhaps this bothers me the most -
[https://www.youtube.com/watch?v=X0VsStcCCM8#t=745](https://www.youtube.com/watch?v=X0VsStcCCM8#t=745)

Guy behind framework openly admits he did not really pay attention to what
other frameworks were doing (and Ember used to be Sproutcore and went through
similar observe-loop pains in the past.) He just transferred his Java-server-
side-MVC experience ($scope/$context - these are very distinct server-side MVC
concepts) as is to the browser, which, as turned out, not quite well suited
for long living in-browser apps..

And then whole dependency/packaging mess. There were already solution and
tooling in place for AMD - but he decided to reinvent it, and as a result
integrating any serious building process is a pain (i am not talking about 1
page apps here, i am talking about apps with 10Mb of JS code bases.)

While this all workable, and this is what I do at my day job, this should not
be necessary. I call it "bullshit job" just like many "create report" type of
jobs - where no real value is created.

If you know 100% that your app will never grow outside small prototype - go
for it, otherwise either have plan in place to redo your app in sane
framework, or do your app in sane framework from the start.

~~~
marcofiset
What would be a sane framework? Every one of them seems to have many pain
points, and every other developper tells you should use X instead of Y because
Z.

~~~
hippich
I specifically did not mention any names to not trigger flamewar. And
mentioned Ember only in relation to the video.

For me personally it is Backbone (very minimal skeleton-like framework),
view/binding library I like today (and can switch tomorrow) and routing I
probably write myself for specific use case.

If this is too "low-level", next what I will check in "higher level" framework
- as least "magic" as possible - i.e. explicit getters and setters with
current state of Ecmascript, clear rules on how and when rendering happens,
debuggable views (which often means views being compiled into JS.), being able
to split large application in pieces which get loaded on demand without
hacking/monkey-patching framework, being able to use jQuery if I want to, and
not include it if I don't need it.

Sorry, no specific answer to your question, as I think it is problem specific,
and even Angular can be used in some limited cases as it turned out.

~~~
_asummers
> debuggable views

One thing I've found while doing Android dev is that views should exist as an
immutable collection of state (POJO in Java), and there should be some
mechanism to inflate a view from that state. I'm not sure how Angular or
Backbone deal with this, but that switch simplified the logic a great deal and
made testing straightforward.

~~~
hippich
this is idea behind handlebars templating - ideally, no logic whatsoever and
you just supply object with data to render. But in reality it gets more
complicated than that and sometimes you need to debug templates too.
Unfortunately, debugging angular templates is pretty much hell (mostly because
of all the "magic").

~~~
_asummers
The way Square's library Mortar handles it in Android is that you essentially
have a Model-View Model-View-Presenter sort of situation, where your View
Model is JUST your data, your View is JUST the view logic, and the Presenter
takes care of knowing how to inflate/deflate the view. It's pretty clean if
your design is clean but can get hairy easily if it isn't; that's a feature
not a bug for me.

------
southpawgirl
After ~1 yr of experience with Angular, I have to say I fully agree. Debugging
is a pain, for a start, and so is delving into the source code. Plus, it's
incredibly complex and opinionated and still it leaves it really easy to slip
into really poor practices and untestable code (observe the complexity and
verbosity of this best practice guide: [https://github.com/mgechev/angularjs-
style-guide](https://github.com/mgechev/angularjs-style-guide)). The real deal
breaker is, however, performance in complex pages.

I much prefer to write my own controllers and models and use Reactjs for the
views.

------
Bahamut
To be honest, this article is pretty poor, and even demonstrates the lack of
understanding of Angular the author has.

The databinding capabilities is said to be at 8000+ watchers now, although not
all watchers are equal. A lot of performance improvements have been made since
2-3 years ago when that post was made about the watchers, which is where that
oft poorly quoted 2000 watcher number originates from.

The two way databinding complaints miss the mark - the point of them in
directives was to mimic eencapsulation and what is now being known as the we
component spec. Web Components are essentially what Angular directives were
meant to be in absence of an official spec for browsers to implement. The
point of two way databinding in inputs also are for encapsulating logic for
each component.

The comments about ng-cloak and ng-bind were also flat out incorrect.

I think most of all, the author doesn't understand context - Angular was
conceived during a different time for frontend, and at a different time with
browser support. Five years is a long time to last in the frontend world
currently, and that it will likely last at least 3 years more is surprising
for a framework that has changed frontend development for the better overall.

Angular is obviously not perfect, and the core team members are quick to point
out flaws in approach, or solutions that were good at the time but don't make
sense going forward due to changes in the browser environment or other
technologies solving problems that Angular had to solve, such as with
Object.observe, ES6 modules, and ES6 promises.

I have built & architected many Angular apps over the past two years, some
being very complex due to the problem space. I have found Angular to be
perfectly suited to the task, and snappy to boot. I have seen very few perf
problems where I could not fix them with a little work - the only one that was
too difficult was dealing with editable tables with lots of data in older
browsers (IE8 - 10), and I believe I could have tackled it, but I was playing
more of an advisor role to another developer, and these sort of problems
usually require the engineer working on the problem to understand the nuances
of the code itself.

~~~
andrewstuart2
Additionally, if you have even 2000 data bindings onscreen at once, your users
are likely going to be looking at too much information no matter how snappy
your UI is. The more info your $watch has to deal with, the more info your
users have to expect to change.

The more you want to throw on a page (say for infinite scrolling), not
surprisingly, the more you'll have to be careful about how you do it. The
benefit with Angular has always been that it brings the difficulty of every
task down a notch or two and limits your cognitive load, very much due to its
design. You still have to design your page and architect your data.

To be honest, after three years with the product, I still think Angular (1.x)
was 10 years ahead of its time.

I've also come to a realization about Angular 2.0 as well: how many people are
still using Windows XP? It's almost 4 versions behind, and closed-source to
boot. I (as many others did) jumped all-too-quickly to the conclusion that I
_had_ to switch to version 2.0 when it came out. That's simply not the case.

Heck, even Microsoft seems to get every other version wrong. Maybe Angular 3.0
will be the time to switch.

------
nsamuell
While I'd be the first to agree that Angular does a bunch of things I think
are a bit crazy, articles like this don't really move the needle for me. The
author doesn't like the design of Angular and feels it isn't efficient enough.
OK, that's OK! However, there's not some massive conspiracy here - go ahead,
use React/Ember. In my own experience, Angular is performant enough for most
web applications, and the convenience the framework offers makes up for a lot
of the crazy, weird things it does to achieve that API.

But to each his own.

~~~
southpawgirl
"there's not some massive conspiracy here - go ahead, use React/Ember" I wish
it were the case; whilst for my own projects I certainly follow such advice,
I've found that in industrial settings Angular is seen like a framework that
delivers quickly and "if you don't like it probably you don't understand it",
and therefore trying to oppose its choice raises eyebrows ("ah you want to
bill us more days", or "duh! our consultant wants us to make exotic||obsolete
choices"), more than it triggers any objective discussion.

------
exratione
Takes all sorts. I put in some time at an office where the team struggled
immensely with Ember but found Angular much easier to pick up and produce
results with.

The scaling thing is just one of the hurdles you have to manage in this
framework. Every system has them. Once you learn where the limits are the
tools exist to manage it:

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

Like all frameworks, Angular isn't suited to every task. If you are rendering
massive tables, to pick the obvious example, then you probably shouldn't be
using any of the modern binding-based frameworks for that part of your
application.

------
afarrell
> There is a fundamental rule in programming, it relates to absolutely any
> technology or language, this rule says that explicit is always better that
> implicit.

Is this a fundamental rule? I thought it was something highly valued by python
culture but not by, say, ruby on rails.

~~~
needusername
Yes it is. That's why explicit memory management is still the standard today
and implicit memory management with garbage collectors will never lead to
understandable or maintainable systems.

~~~
grandalf
more realistically:

app.php

    
    
       <?php
        // logic and state here
    
        include 'some_other.php' // modifies or adds state in unknown ways
    
        // more logic
    
        $some_variable = 3; // does the include below depend on this? who knows.
    
        include 'yet_another.php' // expects state, who knows what
                                 // also modifies state
    
        echo $state; // not sure if we can remove/replace any of those includes and this will be as expected.
    
       ?>
    
    

The includes are being used like sloppily defined function calls which do a
muddled combination of rendering and state modification.

The same can be found in Rails in partials.

Also, in Rails, helpers are essentially crippled presenters that have access
to lots of effectively global state and thus cannot be reused.

------
santoriv
I don't know if I agree with everything that this post says, but I do agree
with the bit about two way data-binding being a problem. Two way data-binding
definitely gives a "Wow that was easy" impression in a tutorial app or
something not too complex, but once you get into the realm of a seriously
complex app, it becomes an anti-pattern. You _need_ to know which direction
the data is flowing and in many situations there can _not_ be two sources of
truth that are always in sync with each other. I'm working with Ember and I'm
really glad that they are moving away from using two way data binding by
default.

------
crazychrome
never tried it. AngularJS gave me a strong feeling of j2ee, bold, tons of
reinvetions of old concepts. most of all, the authors are from google which
never shipped a high quality Js/browser based product. except the original
gmail.

the only problem i have with this article is: i wrote a hatre comment on
angularjs about 8 months ago and got downvoted heavily, but this one just
keeps earning points!

------
bahmutov
Interesting post, not sure I agree that the points raised mean AngularJs is a
bad choice. Consider first objection - two way binding. Not only there are
user-space solutions (bindonce), but now there is standard one-way binding in
ng v1.3.

The Angular does nice job allowing simple interactive apps to be written in 30
minutes by anyone familiar with HTML and JavaScript. At the same time, if the
app performs what is needed by the client, the app can be profiles, and each
bottleneck can be optimized in a couple of steps.

For example, we went through this process and described the steps we used in
[http://bahmutov.calepin.co/improving-angular-web-app-
perform...](http://bahmutov.calepin.co/improving-angular-web-app-performance-
example.html)

------
CSDude
I am not a good front end developer, however I think something like Angular is
very useful to a frontend noob like me, I remember my old Jquery days, it is
much easier to write modular code in Angular. You just have a template, and
its controller. Easy! (For not very complicated things ofc) It might be better
in other frameworks, I agree the docs are somewhat confusing, I still confuse
provider-service-factory however as I said, it simplifies most of my
development, and my medium sized web app runs very smoothly with Angular

~~~
exodust
"a frontend noob like me, I remember my old Jquery days,"

I'm not sure how a frontend noob can have "old jquery days"! Not sure a
comparison with jquery is needed. They're different enough, or do some people
actually consider using Angular a "step up from" Angular? That would be funny.

Personally I prefer the cross browser/device performance benefit of jquery
even for a medium sized app. Potential growth of the app's frontend needs can
be met with jquery. It runs quick I've noticed even when it has a ton of work
both initially and dynamically. I've thrown a lot at it, too much, and Jquery
doesn't mind a high load of elements and updates, especially if you get your
loading spinner graphics and display-timing sorted, complex pages can look
quite smooth even on mobile. It wouldn't be wise to rule out a good performer
like jquery.

------
andrea_s
In my experience, it's very easy to shoot yourself in the foot with Angular,
performance-wise. But this is most often due to poor understanding of how the
underlying update model works (people abusing deep watches would be a prime
example).

Of course, the generally poor documentation does not help newcomers...

------
snarfy
I'll take a good library over a framework any day. Angular is a framework.

------
scottu
There sure are a lot 'Angular is Bad because...' articles out right now. Is it
mainly because of the rewrite?

I've begun using Angular for personal projects. At work we use CANjs. I like
CANjs but I have to say it feels easier to become productive on AngularJS. For
me productivity is most important.

Regarding framework vs library. I heard more than one speaker at Fluent last
year say that Angular was a library and not a framework like Ember. For me
Angular seems pretty light weight compared to what else is out there.

Maybe in a few months I'll feel different. For now I don't hate on Angular.

------
coldcode
While I have no direct experience with Angular (I used to do javascript but
now iOS) the folks in the office using Angular seem testy all the time.

------
SideburnsOfDoom
In the section on minification;

> When you minify your code, it stops working, since variables are injected by
> name. ... You have to use this syntax ...

We didn't have that problem. Or rather we did until we reaised that the
minification tooling can convert it automatically. The author does not know
that his problem is not a problem any more as it has already been solved.

~~~
riffraff
FWIW, newish versions of angular can be set to explode in your face if you use
the shortened syntax even when unminified using "ng-strict-di" which I suggest
everyone to use.

------
sergiotapia
That's all fine but literally the #1 reason you should not use Angular is how
the angular team tossed everything for version 2.

How can you trust such a tool? Do you want to rewrite your applications when
version 3 comes out? Whos to say thy want do the same thing come v3

------
whoisthemachine
I agree with your points, but I can say that I do not have the same hatred
towards the framework as you do. It sounds like I should feel fortunate to
have left that project after only a few months of working with Angular.

------
andrew_wc_brown
I am building larges scale web-apps with AngularJS and I have no issues with
debugging or performance that I need to move to another framework. Once you
know the paint points of any framework you work around them.

------
GUNHED_158
Couldn't find any specific reason in this article to NOT use AngularJS!

One can always talk about any framework like this.

Good reasons to NOT use a framework might be: Lack of hope in future
improvements, Inability to deliver the necessities, etc.

AngularJS delivers and there is a lot of hope around it and that's exactly the
reason people use ReactJS too.

AngularJS is a very powerful framework and implements many of the common
patterns in rich web applications. It has a learning curve which is normal,
and poor documentation which is being improved day by day.

Adopting AngularJS will result in less coding in the near future which in turn
will result in less bugs and support. Therefore making it worth the learning
curve.

