
The reason Angular JS will fail - teemo_cute
http://okmaya.com/2014/03/12/the-reason-angular-js-will-fail/
======
acjohnson55
I think the author is right, if Angular stays how it is today. I've spent a
lot of time trying to learn and believe in Angular. I've failed to be
persuaded that it's the end-all, be-all that many people think it is. Nothing
I've read--not the docs, nor ng-book--have successfully given me the mental
model for what the heck is going on behind the scenes. I think directives are
a horrible hacky mess. I recently struggled mightily to design a simple
recursive tree directive. Apparently it can't be done without hacking the
compile/link plumbing [1].

But my understanding is that Angular is actually going to vastly simplify and
modularize in version 2 [2]. I've read that Web Components will be replacing
directives [3]. Notably Google is also sponsoring Polymer, which is based on
Web Components. Object.observe is going to vastly simplify the scope
situation.

[1] [http://stackoverflow.com/questions/14430655/recursion-in-
ang...](http://stackoverflow.com/questions/14430655/recursion-in-angular-
directives)

[2]
[http://blog.angularjs.org/2014/03/angular-20.html](http://blog.angularjs.org/2014/03/angular-20.html)

[3] [http://stackoverflow.com/questions/18089075/what-is-the-
diff...](http://stackoverflow.com/questions/18089075/what-is-the-difference-
between-polymer-elements-and-angularjs-directives/18092637#18092637)

~~~
JPKab
You've further reinforced my gut feeling of staying away from Angular at the
time.

I'm a data guy, and I only mess with web apps to present my stuff. Recently I
wanted to do a realtime map app to display tweets processed by some ML stuff I
had built.

I started to look at Angular, got a headache, and then built it with Meteor.
It was ridiculously, almost embarrassingly easy. I felt like it was 1996 and I
was sneakily using Microsoft Frontpage to build my web page instead of hand
coding it.

Now, I'm not an idiot. I understand that Angular is a toolkit for building
things which are much, much bigger and more complex than anything I touch. But
if they can make it easier with version 2, I'll wait until then.

~~~
rudasn
if it's for personal projects maybe vuejs will be better for you than angular.
same principles, much simpler execution.

------
pilgrim689
A tool doesn't fail because it's difficult, it fails if its difficulty is not
worth the results it produces. A chainsaw is more difficult than a plain old
saw. You gotta make sure it's fueled up, oiled and whatnot. You might even
have to read instructions the first time! But is it worth it? That's the
question, and it goes completely unaddressed in this post.

~~~
robmclarty
Exactly. If you don't want to burden your little head with OPAs and APIs and
application architectures, just stick the jQuery and happily manipulate the
DOM here and there as you see fit. If you want to make something bigger,
something more app-like (in your browser), something that's not merely a web
page, you're going to need some structure like that found in an MVC framework.

Coming off working on a large Backbone app, I've seen how bloated, needlessly
repeated, and painstakingly verbose things can get. Angular solves a lot of
the problems I have with Backbone by taking care of basic plumbing for me so I
can focus on the unique parts of my app. It's magical, but that's what I want
in a framework: less pounding out boilerplate and more writing application
code.

------
laureny
> The main reason Angular JS will fail is because it’s difficult.

I'm glad good scientists don't stop studying something because it's difficult,
it would have sucked for quantum theory.

Seriously, though, that's the argument? A technology will fail because it's
difficult? Hopefully the OP meant "overcomplicated" or "I tried to learn it
and it was beyond my ability", but saying that something will fail because
it's difficult is just stupid.

Besides, even if Angular were to fail overnight, right now. The download sites
go dark, the team is disbanded and starts working on something else, I'd argue
that Angular has already succeeded by showing everyone a new way to tackle
single apps and how to structure Javascript applications.

Having said that, I'm pretty sure Angular is going to be around for quite a
while.

------
kayoone
Apples and oranges...Coming from a backend developer background i actually
found angular pretty easy to pick up. Most of the backend frameworks are much
more complex. And angularJS is to be compared with application frameworks, not
with a javascript toolkit to enhance static websites like jquery.

Try to build the kind of apps you can build with angular in a few days with
jquery and you will see what mess you end up with.

~~~
vojant
I have exactly the same feeling. I am mostly backend developer who started
with angular this week. After few days I was able to create mvc app, thanks to
the multiple plugins I was able to finish it really fast. DI and other
features make it easy to maintain over time. jQuery is cool for simple
frontend features, but not for maintaining complex mvc frontend.

------
kmkemp
Not a single example of the aspects of Angular that are "difficult" or how
they could be made simpler. I can't take this seriously.

------
cwp
This is a fundamental problem for frameworks. To be better, you have to be
different. People don't like different. They do like better, though, so the
design goal has to be maximize better while minimizing different.

Angular's explosive growth suggests they've done a reasonably good job of
that, and will continue to increase their better:different ratio. You can't
please everybody, though.

------
crazychrome
Google folks don't understand GUI programming. Look at GWT, app script, Dart,
Android and Angular JS. Google folks are brilliant in server side, though,
e.g. Golang!

It's not because google guys are less smart but they are in a very different
working environment than `modern startup`. In today's startup, developers are
designers. We don't have money to hire graphic folks, UX specialists. We learn
by coding, therefore the feeling of having control is essential. The popular
MVC/MVM model is used to maintain flexibility and separation of concerns, not
to dispatch work to different people. The AngularJS framework gives me the
impression that the developers desperately want to hand the sh*tty html/css
parts to someone else as if it's necessary evil. AngularJS projects are
difficult to control since by its nature, users of the framework are
encouraged to let go something that are essential to the control freaks.

Are you a AngularJS advocate and a corp dev?

------
jeremiep
Angular is actually simple once you know it. It just isn't easy to learn.

~~~
tomelders
I am not a smart man. While I have had my struggles with some aspects of
Angular, there is no way I could be delivering projects of the complexity I'm
working on now without it.

I suspect it's only difficult to people who don't make sophisticated things.

------
johnatwork
Angular.js is very different from jQuery, and the two are not comparable.

------
icholy
I guess vim and git will fail too.

~~~
teemo_cute
Actually that same blogger wrote such a piece regarding git:

[http://okmaya.com/2014/03/10/git-kinda-
sucks/](http://okmaya.com/2014/03/10/git-kinda-sucks/)

~~~
meric
For those interested, he's also written a web framework:
[http://okmaya.com/2012/08/08/successfully-completed-the-
fram...](http://okmaya.com/2012/08/08/successfully-completed-the-framework/)

It eschews OOP, for the following reasons:

"1\. Now imagine coming to a website where you have to wait even 30 seconds
for every page to load because it has to build objects. Just doesn’t make any
sense.

2.Why build objects on every page load, when all the objects are going to be
gone once the page is loaded anyway?

3.It’s like building a stock car at the start of every race only to completely
take it apart at the finish line. Pointless."

He also gives out some advice:

"Note to OOP Web Devs. Stop being lazy and learn to actually program."

~~~
mattgreenrocks
No offense to the author, but he's clearly a junior developer with a blog.
Literally every single indicator points to that: overly simplistic, linkbait-y
headlines, complete lack of technical examples, no technical anecdotes, overly
long articles.

We all go through the "all other software sucks, it's too complex" phase. The
difference is how you handle the realization, and how you let that taste
influence your own programming. Some software is necessarily complex.

------
joshdance
Anyone else notice this?

> and AngularJS has only been around for a few years, while jQuery, almost a
> couple of decades.

jQuery was released in 2006. Unless my math fails me, that is less than a
couple of decades.

Opinion is valid and he wrote an article, which is more than most have done,
but some factual discrepancies. The whole # of google results factoid is off
as well -
[http://www.google.com/trends/explore#q=angular%20sucks%2C%20...](http://www.google.com/trends/explore#q=angular%20sucks%2C%20jquery%20sucks&cmpt=q)

------
asattarmd
I fail to understand what makes AngularJS difficult. I believe AngularJS is a
very intuitive framework.

When you write in AngularJS, you forget the nitty-gritty DOM manipulation, you
just care about your data. AngularJS changes DOM for you. A Controller holds
the data. AngularJS keeps the view updated with the data in the controller.
You need to fetch data from somewhere such as REST API? Just ask for it,
AngularJS gives you $resource. Just like that. No initialization, handling
dependencies. Feeling there's code bloat in your controller? Extract a service
and AngularJS will make it singleton for you and pass it whenever you need!
Need to filter data before displaying it? Write a filter! Directives are bit
difficult, I understand, but all the rest of stuff is easy and very intuitive.

Microsoft folks have been writing MVVM apps in WPF and Silverlight for nearly
a decade now, writing their own DelegateCommand, using an IoC container, using
an ORM and plugging all these things together. AngularJS gives you all of
these as one framework! (considering $resource as the ORM). AngularJS got SPA
right and IMO, is _the_ way to build apps. I don't think it'll fail.

------
crucialfelix
Its an advanced framework for building larger scale sites. I've found that it
scales well and my projects can be successfully transferred to other
developers and they can jump right in.

Angular 2.0 addresses many of my complaints. I have a few legitimate ones.

Dependency Injection is being made simpler and I hope less fragile. If
something goes wrong in the minimization phase you can easily get the dreaded
module not found and your whole app/site is broken. But it makes testing clear
and precise and its improved the quality of design of my sites and apps.

Simplify the directive API. Yep, its weird. Its fun when it works though. The
ideas of directives will live on in other frameworks regardless. So Angular
can't fail, it has already succeeded. Even if it dissolves into web components
in the future.

When the animation system gets fully solved then I think angular apps will
look/behave so cool that complainers will be compelled to learn it.

Really, its the Rails of the frontend. Which is both a compliment and a
criticism ;) They both have too much magic.

[1]
[http://blog.angularjs.org/2014/03/angular-20.html](http://blog.angularjs.org/2014/03/angular-20.html)

------
dillonforrest
The author doesn't seem to be building a complex single-page app. If that's
the case, then yes, jQuery is easier than Angular.

If the author IS trying to build a complex single-page app, then I see
absolutely no reason why jQuery would be preferable to Angular. Angular does
one job and does it well. jQuery is a strong candidate for most reasons you'd
ever need javascript in the browser.

Yeah, I do agree that Angular's documentation is lacking, especially compared
to jQuery's docs. Also, Angular is not my personal first choice front-end UI
framework. However, for CRUD application development, I care much more about
Angular's holistic approach rather than being able to procedurally manipulate
each DOM node and event handler as I would in jQuery.

I appreciate the author's passion and think the arguments are valid, but I
also feel that this is an unconvincing apples-to-oranges comparison. In my
completely honest opinion, I'm not incredibly excited about EITHER Angular or
jQuery, but I am grateful for both.

------
all_the_things
Angular allows for a clear separation of concerns and it's easy to teach
individuals standards (isolate dom manipulation, no global state if possible,
clear techniques like promises and data binding). It's similar techniques, if
not easier, than node.js. Should we assume node.js will fail because it's too
difficult for the author?

------
Taurenking
I like the comment and I in part agree with it:

First of all. Yes, Angular IS kinda difficult. The docs sucks and it has a
huge learning curve if you're not doing a stupid app.

BUT

It is not jQuery. It's a full blown mvc framework. And the 2 are completly
different products and they serve different purposes...

\- want to do simple Dom manipulaition? use jQuery. \- want to connect the
_browser_ client with a backend system in an efficent way? Angular may be the
tool you're looking for.

"The problem is that it's backed by Google. Well, Google is composed of many
smart people writing complex apps and inventing revolutionary algorithms. The
people working there are in the top 1% of society when it comes to
intelligence. What about us on the bottom 99%?"

While I do not consider myself amongst the top 1% smart people here
mentionend, I can still find my way out of Angular...Perhaps, it's learning
curve is a barrier between who really wants to invest time in it or not...

------
methodin
This was a terrible article. The bulk of it was talking about jQuery with a
final few sentences alluding to "angular is hard" with no substance or
reasoning.

Personally I find the angular concept easy to follow with the only hard part
"how do I accomplish X" which is pretty easy to find answers for.

------
deedubaya
It may have a steep learning curve, but it is also a massive jump forward in
frontend web dev.

It isn't for every project, but the main project I use it on now would have
been at least 10x as much jQuery style code to write. Writing code isn't hard,
maintaining it is.

------
iomind
jQuery is fine for regular websites and the like, but inadequate for large
scale client apps. That's what Angular is for. There is not much benefit using
angular to build your marketing site.

If you don't understand this, you understand neither Angular, nor jQuery.

~~~
jcvandan
He isn't comparing the features of Angular to the features of jquery at all,
he is just comparing it to a framework that has stood the test of time due to
it's simplicity. He doesn't explicitly say it but I am sure when he talks
about 'easier' ways to do what you can do with Angular, I believe he means
other similar frameworks e.g. Ember, Backbone etc.

~~~
novagenesis
Perhaps, but using Databinding comes at a price.

The moment you databind, you can't use nearly as many other libraries as
easily or safely. This means you want as fully-featured a databinding library
so you don't need other stuff.

There's tons of articles about providing Angularjs updating support when you
use jQuery..it's (or used to be) just painful.

------
thatthatis
Like with Django, I find angularjs difficulty almost always merited.

When I am struggling with "agh why do I have to do it like that" in either
framework I later find that either 1) the difficulty was necessary for some
important reason and they're saving future me from easy mistakes or 2) that
the difficulty was due to me not knowing some really amazing concept or
paradigm or pattern.

This isn't to say that angular is perfect, but damned if it isn't elegant,
powerful, and well thought out.

I've found angular to be by and large incredibly intuitive and easy to use.
But there is also an effect of they're solving pains I've had in prior
projects, and using concepts I'm familiar with.

------
dberg
You can probably apply the same logic to most things, especially something
like scala. On the surface when you see a method definition in scala that
looks like

def split: scala.Seq[Task[Combiner[S, That], FlatMap[S, That]]]

you kinda scratch your head. But once you understand whats happening it doesnt
feel so intimidating. I think technologies that have a good long term benefit,
but a difficult upfront learning curve tend to get this kind of reaction. I
think Angular is a brilliant framework and makes coding in javascript
enjoyable. Yes, I had to read 10 articles before I understood what the hell
transclusion was, but once you invest a little time learning, it doesnt feel
so bad.

------
benesch
I agree with the premise but disagree with the argument.

> Which brings me to the pattern of ever failing technologies. Remember Moo
> Tools? Prototype? ... Prototype and moo tools tried to be innovative, but
> they just made things harder. Not only were they not intuitive to use, but
> referring to the documentation was even worse. Would take hours what jQuery
> could accomplish in mere minutes.

That's just not true. I can't speak to MooTools, but I used Prototype back in
the early Rails days, and it was a pleasure. Great documentation and it jived
with the Rails automagical convention-over-configuration approach. Prototype
failed because a) it stopped being actively developed, and b) it overrode
native object prototypes in a way that could cause other libraries to
catastrophically fail. But Prototype didn't fail because it wasn't intuitive,
and it didn't fail because it wasn't documented. IIRC, Prototype documentation
was actually better than jQuery documentation.

> The main reason Angular JS will fail is because it’s difficult.

This is fair criticism, but there's no supporting evidence provided—only that
Angular JS didn't "feel" right and that more people search for "Angular sucks"
than "jQuery sucks" on Google.

I think Angular got a lot of core ideas right: two-way binding and extending
HTML. But it also comes with an extremely steep learning curve. The directive
definition object, with its pre-compile, post-compile, pre-link, and post-link
phases is too complex and exposes too many warts of using the DOM as a
templating language. The documentation takes several passes to grok, and
you'll more-than-once have to dig into Angular internals. The several ways to
create a service (`.provider`, `.factory`, and the supremely confusingly
`.service`) are unnecessary obfuscation and force you to use singletons;
custom classes/prototypical inheritance in Angular requires some mind-bending
use of first-class functions.

If you're not careful to fully understand Angular, it's easy for your first
Angular app to turn into a mess of spaghetti, since Angular enforces too much
awkward structure at the directive/controller levels, and not enough at the
data management layer.

But these are issues that the Angular core team is well aware of. I'm really
excited about the Angular 2.0 roadmap [0]. And even if Angular fails, some of
its ideas are so good they're being incorporated into ES6, like Object.observe
[1].

[0]
[http://blog.angularjs.org/2014/03/angular-20.html](http://blog.angularjs.org/2014/03/angular-20.html)

[1] [http://addyosmani.com/blog/the-future-of-data-binding-is-
obj...](http://addyosmani.com/blog/the-future-of-data-binding-is-object-
observe/)

~~~
theschwa
I wish there was more discussion of the core concepts in Angular instead of
just the implementation.

Custom Elements + Two-way Data Binding + Services seems to be a pretty
powerful combination.

~~~
ssmoot
Two-way Data Binding is really oversold IMO.

There are few cases where I want such a thing (like say updating the count on
a shopping cart when an item is added). I don't ever want an item you're
adding in a form to be showing up as you type it in a list in the background.
That adds nothing and on the whole it's probably a UX negative effect.

I think it's brought up so much mostly because it's cool tech. But I don't see
it actually solving problems.

MS had the same tech, with an arguably simpler implementation, years ago in
ASP.NET. And while I've been out of MS development for awhile I feel like it's
been largely deprecated. And it was never a "best practice" in the first
place. It was mostly just a demo tool for MS sponsored "conferences" (read
sales demonstrations by MS employees who went on to found Telligent).

~~~
Spongeroberto
The two way binding can be so useful though. The best example I've seen was an
array of coordinates bound to a directive that used D3.js to visualise it.
There were some special function you could call that would affect and expand
your data and immediately update the graph, and you could manipulate the
individual points on the graph and it would propagate to the data seamlessly.

I guess to me two way binding is one of those things that you don't think of
often, but when you don't have it you suddenly find yourself writing tons of
boilerplate code to get the same effects.

The only cases when I didn't want the two way binding were when I was creating
or editing an item. And then it's trivial to bind the form to a separate
object while you work on it, then push your changes to the collection/original
when you're done.

------
nigekelly
I agree that angular is difficult and docs poor. I think knockout has great
docs and is easy to learn. But google trend both and clearly angular is
winning and probably has won the mvc js battle. It defies logic but there it
is.

50% of your article was about how jquery was superior and simpler than
prototype and moo tools. It may have been superior but it's nonsense to say it
was simpler. I used prototype alot and it was simpler. To grab a div you
simply:

$("mydiv")

not:

$("#mydiv")

So much more elegant than jquery!

Prototype comes from a js perspective whilst jquery seems to come from a css
perspective. So I think prototype is better for traditional developers and
jquery for web designers.

------
kennu
It's always a little bit harder to learn an existing framework than to just
write your own stuff from scratch to suit your project. But the former is
pretty much guaranteed to be more productive than the latter.

------
nikon
I'm going to trust your opinion clearly as you built this:
[http://okmaya.com/clean-php/clean-php-step-1/](http://okmaya.com/clean-
php/clean-php-step-1/)

~~~
BarDev
I believe that's sarcasm.

------
jively
"I don't like it because it's hard" is not necessarily a good way to evaluate
a technology.

JQuery does things in a very standard way, and has been the go-to tool for
developers for years. Devs grow up on it, get used to it and find it difficult
to fit new ways of working into their mental model. It's like shifting from
procedural to functional: the concepts are a alien and because they don't fit
& there's a psychological block to learning it.

Not sure that dooms it to failure... maybe to adoption by the masses.

------
untog
I'm not sure I agree with the comparison here. I used MooTools back in the
day, and it was just as easy to use as jQuery to my mind. The syntax was
slightly different but not hugely - when I gave into the inevitable and
switched to jQuery it didn't take long for me to understand it.

jQuery succeeded because it captured the largest amount of mindshare,
particularly important for a library that relies on numerous plugins. Right
now Angular is looking pretty similar - it's not pretty, but it is widely
adopted.

------
vojant
Completely disagree with the author, comparing jQuery to Angular is stupid.

It's similar to situation with php few years ago when Symfony2 and other big
frameworks were introduced, many people still complain and they use simple non
oop php to create websites.

World is changing, php changed and now javascript will change. Some people
will stuck to jQuery but most will move to new mvc frameworks because they are
much easier to maintain, also many backend developers is moving to REST
architecture lately.

------
romanlevin
tl;dr: AngularJS will fail because it is not as intuitive and easy to use as
jQuery.

------
brucehubbard
I think a better argument would have been not adding Angular to every project
by default because it's the new hotness/shiny. There is a great use case for
Angular but if all you need are some onclick's then yeah Angular is overkill
and complicated. But if you need two-way binding and a semi-complicated UI
then it simplifies a lot of stuff vs. straight up JQuery.

------
michaldudek
Waaaat. How can you say Angular is hard? I don't think I ever encountered a
framework or a technology that I picked up so quickly. Hell, node.js took me
longer (with all the callback hell and workarounds for it). I've built several
apps in Angular now (and am close to finishing a very complex one) and I dont
think I have ever gone through a tutorial.

------
AlwaysBCoding
I agree with this post. The worst thing about Angular is how confusing it is,
particularly when it does not have to be at all. There are at least 10 things
I can think of off the top of my head that are so confusing about Angular that
could easily be much simpler that it tells me the framework creators must not
care about understandabiltiy at all. I think for a JS framework this is a
death wish, but we'll see.

Just some examples:

1\. When you create a directive you initialize it with one of three different
kinds of scopes. A parent scope (which is the actual controller scope object),
a child scope (which prototypically inherits from the controller scope), or an
isolate scope (which is an isolated scope with inheritance only to rootScope).
If you don't explicitly define a scope you get a parent scope. If you write
`scope: true` you get a child scope. If you write `scope: {}` you get an
isolate scope. This is so fucking confusing for beginners. Why not just
explicitly define what kind of scope you want so it's clear?

2\. Every single example of learn AngularJS online, even examples from the
'official documentation' (that's in quotes because Angular's documentation is
so atrocious that referring to it as documentation would be bastardizing the
English language) give you examples of defining services, controllers and
directives directly on the top-level ng-app module when in reality doing this
is catastrophic and will make your app IMPOSSIBLE to unit test. You need to
define services in their own modules that get aggregated into the ng-app
module so you can unit test them, but there are no examples of that anywhere.

3\. Speaking of unit testing, because it's supposed to be so easy in Angular
right? You have this thing called angular.mock.module that's the key to
everything. Now 'angular.mock.module' is different from 'angular.module' but
is for some reason aliased to 'module' because that's not confusing or
anything. Now you would expect for angular.mock.module to be just that, a mock
module. BUT it's actually a module that depends on the angular 'ng' module
meaning that it's not really a mock module at all, it's a module that includes
the ENTIRE working Angular library. So you can use the 'mock' module to get
the REAL injector and use that to get your REAL services which you put into
the mock module to use in your tests. The entire flow is so confusing and non-
descriptive that it's a wonder a beginner is ever even able to write a working
unit test much less a good one. The funny part is all you hear about is "unit
testing is so easy in Angular omgz" when really it's confusing as fuck but the
Angular crew seems completely oblivious to that fact.

\--- I could honestly write a book about my Angular rants, this is just barely
skimming the surface, but the point is, Angular makes things hard and
confusing when they don't need to be. I like the way Angular organizes code,
but I'm willing to switch at the drop of a dime if something simpler comes
along.

------
mattgreenrocks
I'm confused.

What's with the win/lose sentiment? Is tooling a winner-take-all, zero-sum
game? I was never informed of this.

------
Arnor
> Even doing a google search on “jQuery sucks” vs “AngularJS sucks” shows that
> there are more results for the latter...

science

------
theDustRoom
Read: "If my tiny brain doesn't understand it - it sucks."

------
jf22
I could earn a billion hacker news posts by not understanding a technology,
posting about how it sucks, or it will fail or "how I was wrong" and blogging
about it.

------
StevePerkins
I keep seeing articles on HN that make me say, "Oh, that is just total click-
bait fluff".

However, I usually click on them anyway. I'm ashamed of myself. :(

------
taybin
And here I was just looking at some jQuery and thinking that it'd be so much
easier if I was working with Angular...

------
lmm
This badly needs rewriting; the argument may be good, but I can't tell through
the terrible English.

------
flylib
why are people commenting on this nonsense? he obviously didn't do the
research to back his logic and made shallow arguments nor did he once address
any of the other competing frameworks to AngularJS does he think none of those
are complicated either?

------
ing33k
while its hard to learn , the results angular produces is very good. Just
don't give up because its hard. Good things are hard.

------
andyl
We found that the Angular learning curve was steep and was difficult to bring
new devs up to speed quickly.

Our solution was to migrate from Angular to ReactJS. Much simpler, faster and
better.

~~~
stupidcar
Simpler, yes, but simplicity often comes at the expense of power. What happens
in a year, when you have a bunch of experienced developers, struggling to
overcome the limitations of ReactJS? Most likely you'll end up reinventing
many of the things that Angular provides out of the box.

It is always tempting to take short-term gains over long-term costs, and in
some situations, it may be the right thing to do. A company that gets a
product out of the door in a couple of months using ReactJS may beat a company
that spends 12 months building a "better" one with AngularJS. But the reverse
may happen instead: The company that adopted a simpler technology may become
bogged down trying to extend beyond its limitations, giving their competitors
a chance to accelerate past them.

It's the old story of the tortoise and the hare. Except, as with any fable,
real life is never so clear-cut, and gains in one area will almost always be
countered by losses in another.

~~~
chenglou
That's a good, albeit very generic argument where you can switch Angular and
React with simply A and B. My guess is that you haven't tried React? It's been
in production at Facebook/Instagram for a few years now and powers the money-
making parts of the site.

Trading simplicity for power is a false dilemma. If there's any library on the
web that demonstrates this, it has to be React.

