
Angular 2/4 Is Too Little Too Late - Sujan
https://medium.com/@chriscordle/why-angular-2-4-is-too-little-too-late-ea86d7fa0bae
======
rpeden
Re-post of what I wrote about this yesterday on Reddit:

I think Alan Kay was right: computing, at this point, is pop culture. Articles
like this are are kind of like identity politics for programmers.

I don't say that that to disparage the author, because stuff like this is
nothing new. Programmers have divided themselves into warring tribes for
almost as long have there have been programmers. You used to see C programmers
saying that Pascal is for idiots, and Pascal programmers saying that C is for
neckbeards. Or similar arguments between C++ and Visual Basic camps or C vs
asembler. And there are dozens (probably hundreds or more, actually) of other
examples.

So it's not a new phenomenon, and I don't expect it to go away. The way I look
at it, it's usually more productive to mostly ignore the pop-culturists and
just pick tools that allow you to get things done quickly and happily. I've
used Angular 2/4, React, and Vue. I like them all, and I'd be happy to work on
a project using any of them. Aurelia looks equally enjoyable.

At this point, I don't think it's especially likely that a project will fail
because you chose Angular over React, or vice versa. Pick what works best for
you and your team, and don't worry about what the chattering bloggers say you
should be using. :)

~~~
Analemma_
It's even dumber than contemporary identity politics, because at least there
you (usually) can't choose your identity and so there's a defensible case for
firing back at people who try to make your life miserable because of it. But
language/platform/framework fanboyism is just pure sunk cost fallacy: you
spent a lot of time learning X, but if X was the "wrong" choice, then was all
that time wasted? To avoid that outcome, people invest tons of emotional
energy defending X.

~~~
Yhippa
> But language/platform/framework fanboyism is just pure sunk cost fallacy:
> you spent a lot of time learning X, but if X was the "wrong" choice, then
> was all that time wasted?

A lot of these articles give me this vibe. So what if a competing technology
is "bad". What does the author get out of saying "X technology is the best and
Y is fail"? Are these guys now thought leaders?

Also I tend to see these more often in front-end land. Not sure why. Possibly
because the cost of switching technologies is so low that you need to convince
people constantly that X is the best so they stick around.

~~~
thehardsphere
I have a hypothesis about this: The lower your skill is at software
development (or some subset of it), the more likely you are to be strongly
opinionated about these kinds of arguments.

If you are highly skilled, you're far less likely to be married to any one bit
of technology, even if you have prior preferences. You're also likely to have
been through a few fad cycles before, so you probably learned to tune out the
holy wars and focus on being productive. And if some stack X is really a giant
turd, you should be able to figure that out quickly and avoid it, so you don't
have a reason to write about how much it sucks.

On the other hand, if you know next to nothing, you're going to be more likely
to read "Don't ever use X!" stories because you don't know what to use and are
looking for advice. And you may be more dependent on whatever things you do
use, because you don't yet know many other things, and you may be more likely
to believe that it's better for your career to establish yourself as an expert
in whatever you know.

I think the "front-end land" sees more of these now because front-end land is
a new and bizzare place that only came into being a few years ago; people
generally don't understand it as well as they do other things.

------
jamra
This reads as react fanboyism to me. I used React/Redux on a project and was
unable to bring people up in my aging team. Now we are fully Angular 2+. It is
much better for my newly grown team of 15. The action creator approach of
Redux isn't very readable or maintainable. The module system in Angular is
better for us.

You can use webpack with Angular. RxJs is a great addition that will
eventually be removed when Observables become implemented in JS. The
declarative style of templates are different than JSX, but are not hard to
deal with in practice. Native script allows for mobile dev, although I don't
personally use it.

Before I switched to Angular, I preferred React. Now that I use this framework
approach, I am much happier and have more faith that my code base will be
consistent. I read somewhere that google used Angular for adsense so I think
it is good enough for production use for us.

~~~
simon83
I guess when you say "aging" team then I imagine your team members mostly
spent their time in the OOP world, and Angular is definitely a better fit in
this case.

React and Redux promotes a more functional style (even though React components
are classes...), and a lot of OOP people I personally met were not so
comfortable with it.

Personally I love the functional concepts that it taught me, and I would never
want to use a framework like Angular again. I'd rather make the leap and look
into a real functional language for the frontend, like Elm, ClojureScript,
PureScript,...

~~~
jbreckmckye
Honest question: why are React developers so fixated on functional
programming? Why are objects - bundles of state and action that represent
entities in the problem domain - automatically painted as an antipattern?

~~~
pavlov
Because they're not old enough to remember what '80s GUI code looked like when
the "Global god object + functions" pattern was last popular?

That's a snarky reply, but there is a kernel of truth. OO was practically
invented for GUIs (Smalltalk). Throwing it out entirely on principle just
makes large programs harder to understand, IMHO.

~~~
simon83
True, I'm not old enough with my 33 years to remember that ;) But I do have
quite a few years of experience in OOP and GUI programming (not just web
stuff).

------
bdcravens
>> Benchmarks for React consistently show its superior performance over
Angular 2/4: [https://auth0.com/blog/more-benchmarks-virtual-dom-vs-
angula...](https://auth0.com/blog/more-benchmarks-virtual-dom-vs-
angular-12-vs-mithril-js-vs-the-rest/).

Intellectually dishonest. The article linked to was from January 2016, around
the time the first beta of Angular 2 was released. That code has all sort of
debugging code in it, and the architecture changed quite a bit between then
and the release in September 2016. (To say nothing of the fact that those
benchmarks don't cover Angular 4, despite the preface in the article) With AOT
in Angular 4, a site running in production is quite fast compared to JIT.

------
jashmenn
Here's a litmus test for if you should use Angular or React: how do you feel
about the fact that React has ~4 major routing libraries?

I've written a book on both Angular 2+ and a book on React. I've talked w/
hundreds of developers on both sides and I can tell you that people with
different constraints (and backgrounds) will have a different response.

The author of this article cites "more ReactJS libraries on npm" to imply that
React is the better choice. Some people love a la carte infrastructure and the
power that comes from choosing each element in your stack.

Some people love to have those decisions made for them, because they just want
to build their app.

It's often cited that React is "simpler" than Angular, and if you look at just
the core that's true. But by the time you pick a data architecture, styling
choice, router, etc. you're back at the same level of complexity.

Actually in React, you've spent a lot of time researching which components you
want (and if they'll even fit together). The pro here is that you get just the
stack you want! The competitive evolution of these libraries means that you
_can_ have 4 routers and pick the best. But also, if you'd just picked
Angular, you just use their router and move on.

Here's another litmus test: Do you want 'string' templates or JSX? (Now, I
know it's technically possible to do either in both frameworks, but it's
almost never done in practice.)

Almost everything that seems "more complex" in Angular is a result of string-
based templates. DI, AOT, the *ngIf and `let` syntax, is all because you're
doing templates in strings instead of code. How do you feel about that? Would
you rather write templates in JavaScript/JSX? Then use React. Do you have
designers doing HTML on your team? Then use Angular.

(Also the other opens by citing webpack, npm, and third-party libraries as a
React-specific benefit, but that makes no sense because angular-cli uses
Webpack, it's on npm, etc.)

~~~
eropple
_> The pro here is that you get just the stack you want! _

I don't disagree with the facts-on-the-ground of your post, but I think you're
drawing a mighty false equivalency and this line highlights it. The _pro_
here, for a React-based stack is that you are forced to understand the tools
involved well enough to make meaningful decisions (if you're a competent
developer). By the time I was done evaluating routing libraries, I was
confident in my ability to write my own, effectively--and so I didn't have to
because I was able to adopt the library of my choice's mental model
immediately. If you "just want to build your app", your app is gonna blow up
(not might, _will_ , given a long enough timeframe) and you're not going to be
equipped to fix it.

Passive consumption is unwise for programmers. We've seen it bite people
forever (be it the "all things come from Microsoft" era of .NET that they're
just shaking now or the "Spring does it for us" era of Java or most of Rails
pre-3.0).

~~~
jashmenn
The history of technology is using the progress of others as a foundations on
which to build something new. Once it works, it's a given, a building block.
No one can understand it all the way down and we need to be careful about
saying what 'real developers' do or don't do.

~~~
eropple
It's not a given at all. All of your abstractions break. These high-level
abstractions break much, much more often than lower-level abstractions
(because they try to encompass more, it's a surface-area thing). There are
abstractions that are so fundamental to _doing your job_ that you must, must
must must, understand them at an implementation detail and then use them to
improve productivity.

The stump-dumb-simple routing layer of your JavaScript handwavey crap is one
that You Really Just Gotta Know; it's literally central to everything you _do_
in a SPA. And yet the overwhelming majority of AngularJS folks I have ever met
--and, to their discredit, way too many keypuncher ReactJS folks, but a
significantly smaller proportion--have no idea what to do if their web
framework spits the bit. And my contention is that having to make choices
means the likelihood of a baseline understanding of what chose choices mean is
way higher.

There are plenty of capable developers who work on and choose to use
AngularJS. I've worked with _great_ ones. But, like the other environments I
mentioned before, it sure seems like they brought that capability to AngularJS
rather than had that capability fostered by AngularJS in a pedagogical manner.
And that's troubling to me, because these folks are going to be writing
software that you and I depend on, too. I'm not hanging people for not being
able to work meaningfully with the JavaScript runtime or understand how the
browser works internally (though these are handy to know, most of my knowledge
of JavaScript comes indirectly from embedding first SpiderMonkey and then V8
in a game engine once) or how their OS handles process segmentation to sandbox
off their web runtime environment (not a super complicated topic but, sure,
out of scope) or how their OS handles memory (this one, ditto) or or or--I'm
saying _you gotta understand the thing your hands are on all the time_ and
that tools that attempt to swaddle you in a nice comforting "you don't need to
worry about that" are gonna put you in a real rough place when that doesn't
hold.

~~~
pas
So, I've had to maintain (upgrade) a Node/V8 extension, an Angular1 and an
Angular2+ but never stopped to understand routing. (We talked about it briefly
around that ng1 app.) And I have no idea how Node extensions hook into V8
under the covers.

There were no abstraction breaks. C++ compiled, the thing works, the same goes
for ng2 with TS. Ng1 is just plain ugly, but works fine.

I like React/JSX, FRP, I hate the size of the bundles Angular spits out, the
byzantine boilerplate required to put something on screen and to make
components interact, but it works, and it comes as a full package, and it
keeps getting better.

The design principles of Ng are sound. Ng1 was overcomplicated. Ng2 is okay-
ish.

I think ng lacks the "documentation" that the React ecosystem must provide due
to its separatedness/modularity.

But my main point is, that basically good developers will compare those
routing plugins/libs, and those same devs can solve problems when ng2 spits at
them. And newbie frontend devs jump on the React is small and simple hype
train and take the first tutorial and then get lost in that jungle. (And I'm
not saying this can't happen with ng1/2, but neither codebase is about
teaching programmers, so that's a very fringe aspect of this topic.)

------
anton-107
Angular 2+ user here: \- Components have nice API and are pleasant to use \-
Dependency injection containers out of the box are good for those who value
inversion of control in their codebases \- Change detection is good and fast.
Gone are the times of leaky abstraction of the digest loop \- Tooling has
caught up: Angular CLI for rapid start, server-side rendering works just fine.
You are using npm, webpack, typescript (brings es2016 features to you), modern
testing frameworks and what not \- Redux works nicely with Angular2+ as well,
it's not exclusive to React \- You can wrap pretty much any 3rd party browser
widget into Angular component within maybe one hour of work

I guess when your open source library passes a million downloads per month,
you are not worrying too much about marketing anymore. So i'm not quite sure
why it's so important for the author to declare one and only one winner in the
race. Both React and Angular users are benefiting from the competition

~~~
tuan
> Gone are the times of leaky abstraction of the digest loop

But now you have zone and it's leaky. See this stackoverflow question for
example: [https://stackoverflow.com/questions/43097291/firebase-
datasn...](https://stackoverflow.com/questions/43097291/firebase-datasnapshot-
observable-not-updating-immediately-after-login-via-redire)

Edit: wrong link

------
erokar
I agree with the article's main point. In the market share fight between React
and Angular, React has won — and for good reason, I think.

Angular 4 is an improvement over Angular 1.x, but Angular's main problem is
still needless complexity, both in syntax and concepts added by the framework,
and a totalitarian approach, in the sense that Angular seems to want to
replace vanilla JavaScript/DOM/Browser API's with it's own slightly different
and unnecessary versions. What you learn developing in Angular is therefore
specific to Angular and not transferable to other domains. Personally I find
that depressing and demotivating.

Angular 4's HTML templating syntax is terrible. I get the feeling the
deliberately set out to make it as complex and inconsistent as possible — it's
hard to phantom how else they ended up with such a mess.

Angular seems to have been inspired by the worst of Java EE from days of yore,
it's riddled with needless complexity and ceremony. No one should have to work
with that with the nice alternatives we have today.

~~~
uptownJimmy
"In the market share fight between React and Angular, React has won...."

All the data I've seen indicate that both Angulars, combined, account for
twice as many production code bases as React. I wonder where you got the idea
that "React has won"?

~~~
StevePerkins
... and non-SPA, full-page-load-driven, jQuery-based web apps dwarf BOTH by an
order of magnitude, even in 2017. You're just not going to receive many blog
clicks or discussion forum upvotes by pointing that out.

"Won" usually means, " _the thing that people most want to read or talk about
at the moment_ ".

~~~
uptownJimmy
Actually, the same data indicates that jQuery is around 45% market share as
the primary front-end JS tool. That's almost exactly the market share of both
Angulars and React combined.

And yes, this represents a steep drop-off in the number of jQuery-centric
applications in the past couple of years.

Edit: I thought I had bookmarked the Web site where I saw these numbers, but I
couldn't find it before running out the door this morning. Suffice it to say,
the JS landscape is changing rapidly, and assumptions that were safe even 12
months ago are not valid today. jQuery is fading quite rapidly, and though it
won't disappear any time soon, and, increasingly, it is no longer seen as a
good choice for large apps with tons of business logic.

~~~
StevePerkins
I'd be interested in types of applications those numbers are using as the pool
for its comparisons.

What I'm saying is not that jQuery is the end-all-be-all. It isn't, and trying
to build a highly dynamic web application with tons of client-side logic
around jQuery is indeed a recipe for spaghetti.

What I AM saying is that most web applications (especially in the enterprise
business world), simply AREN'T all that dynamic. They are primarily driven by
full page loads rather than AJAX, and server-side logic rather than client-
side code.

On HN, the terms "web application" and "SPA" are practically synonymous. But
outside of a few social media titans, and the startup community, that's hardly
true.

------
forgottenacc57
>>time-travel debugging, hot module reloading, and simple and easy undo/redo
capabilities

These things are prime selling points of Redux and it's interesting that they
are simply unimportant bells and whistles not worth the massive increase in
complexity and cognitive load that Redux brings to ReactJS applications. Use
Redux and you have to write a lot more code, really for no good purpose when
in most cases you can just store a (HERESY!) global variable and get straight
on with the job without twisting your mind around actions and all the other
Redux guff.

Redux is an anti pattern.

This article also breathlessly praises webpack, which is a massively complex
and configuration heavy JavaScript tool and one of the prime culprits
responsible for the JavaScript build tool ecosystem being so damn complex.
Webpack needs to go the way if it's predecessors and he replaced with
something simple.

~~~
onion2k
I don't know enough about React to say whether or not I like Redux, but I've
written enough Angular code to know that Angular's lack of a good state
manager _is_ a problem. A lot of Angular apps end up storing an object in
$rootScope that's treated like a global state, and that leads to weird side
effects and bugs if you're not careful. Something like Vuex would be be a
great addition to Angular.

~~~
forgottenacc57
Maybe I'm doing it wrong but when I (rarely) need state between components I
just plop it into a global variable, of which there only ends up being s
handful, and it's never been a problem. When I tried to use Redux first it
burned my brain trying to grasp its architecture and how to write the various
bits of code it needed, all replaceable with this.app.globals.foo=42

------
jinder
The prevailing opinion on HN seems to be that React is great, and monolithic
frameworks are bad bad bad - especially Angular.

On a recent project I started for a client, we did a full evaluation of React
+ Redux vs Angular 2/4 and NGRX.

Angular's first-class support for TypeScript, and RxJS is incredible when
leveraged properly. Integrate this with NGRX for Redux style state management,
and you get a compelling solution that is miles ahead of the React/Redux combo
_if_ you can get over the template syntax (instead of JSX) and the opinionated
flavour of Angular.

It's difficult to offer an alternative opinion in the HN echo chamber, but
we're having _excellent_ results using Angular CLI + Angular 4 + RxJS + NGRX.
It's worth the steeper learning curve, IMHO.

~~~
Stoids
To add to that, most new React/Redux projects are settling on the same
technology decisions as the Angular team. TypeScript/Flow, RxJS for
async/effect handling (or Sagas). React vs Angular is pretty negligible at
this point. They are both component focused frameworks and that's the
important paradigm and shared quality amongst all these frameworks.

Anyone who understands the architecture of one should be able to learn the
other relatively quickly. I haven't personally used Angular 2/4, but it looks
like a really solid and opinionated solution. Some people don't want to spend
3 days researching thunks vs sagas vs observables, so I'm glad something like
Angular exists.

------
romanovcode
I am using Angular4 and am pretty happy about it. Especially I am happy of the
fact that Angular is opinionated framework thus it is easier to work in teams
on one project because there is usually just one way (angular way) of doing
things instead of 100 different ways in React.

Also, author is praising features like rx, time travel, webpack but does he
know that all these are baked in angular as well? ngRx is very solid
maintained project that actually works with all time-travel debuggers. And
webpack is built-in in every angular project.

------
Wintamute
I agree with this. It's a mistake to characterise this solely as Angular vs.
React though. It's really about these things,

\- Declarative UI as a pure function of state

\- One way data flow

\- Frameworks that use plain language features and functions, rather than
template-like DSLs

No need for framework holy wars, but objective speaking these sorts of
approaches are objectively the right future for UI development imo.

~~~
jamra
Angular is mostly a declarative UI. I don't usually put logic in my templates.
I do, however, like how react leans towards using language features instead of
abstractions.

Angular does one way data flow. It also allows for two way binding. The choice
is the developer's.

So your argument boils down to using language feature over the template DSL. I
think it's more important to consider state management, code reuse, and inter
component communication (perhaps also a part of state management if using
something like Redux).

------
aeturnum
I'm a mostly-backend dev that's been pressed into service on the frontend
recently and I've worked on React and on Angular.

In my experience, I like the React way of defining components and
functionality a lot better. The errors that Angular spits out from the HTML-
templates are difficult to parse. There's also an unfortunate combination of a
fractured community and incomplete first party documentation that makes
Angular hard to ramp up on.

That said, Angular has a huge advantage that has made developing in it a lot
faster for me. It's got everything right there. Angular doesn't have unique
functionality, but it starts you off with a standard set of design patterns
that stand you in good stead. React is just a frontend and when you're new to
the space you don't know what else you need. Frequently, the productivity gain
of not having to think about how to solve a problem is greater than solving
the problem the "right" way.

Realistically, most teams solve this problem by having a senior team member
who can pick technologies and design patterns. I haven't had that luxury on
this last project, so I appreciate the Angular ecosystem. Javascript is great,
but it's still very wild-west like.

------
water42
How to get upvotes on hackernews: write yet another clickbait medium article
on how bad angular is.

I don't think the OP has ever used Angular CLI or followed Angular
development. If he had then he would have not written this article since a
majority of his claims about Angular are wrong.

------
laichzeit0
I moved to Vue from Angular 1 instead of React when I started a new project
last year.

I regret nothing.

~~~
jamra
I keep hearing good things about Vue. Do you know how it compares to Angular
2? More framework than library? State management built in?

~~~
iamacucumber
The Vue guide has a comparison just for you. (might or might not be too
biased, I don't know ng2) [0]

Vue deals only with the view layer. So I would't directly compare it to
Angular. But the authors do give you Vuex, for Redux-style state management,
and Vue-Router which does exactly that.

Alternatively:

\- use a second Vue instance as an event bus. Bonus points as the Vue devtools
list all the events fired. Makes it easy to debug.

\- due to it's reactive nature, Vue let's you implement a single source of
truth quite easily. [1]

\- Using dynamic components, you might not even need a router [2]

Personally, I've tried to use the single source of truth pattern but quickly
resorted to Vuex. It just resonates with me.

[0] [https://vuejs.org/v2/guide/comparison.html#Angular-
Formerly-...](https://vuejs.org/v2/guide/comparison.html#Angular-Formerly-
known-as-Angular-2)

[1] [https://vuejs.org/v2/guide/state-management.html#Simple-
Stat...](https://vuejs.org/v2/guide/state-management.html#Simple-State-
Management-from-Scratch)

[2] [https://vuejs.org/v2/guide/components.html#Dynamic-
Component...](https://vuejs.org/v2/guide/components.html#Dynamic-Components)

------
mnm1
React won and those of us stuck on Angular 1 are mostly fucked. From that
perspective, you'd have to be absolutely fucking insane to even consider
Angular 2 after how badly the Angular team fucked up Angular 1 and all its
users, leaving them in the dust. It's not about tech. Tech is irrelevant. I
cannot trust this team to stand behind their software. Maybe that's because
they build really shitty software. Fool me once and all that ... but IMO,
you'd have to be a fool to use Angular 2+ after this fiasco.

~~~
exclusiv
Is your problem more with the lack of proper migration to Angular 2 or with
the differences between 1 and 2?

~~~
mnm1
My problem is that I don't trust the Angular team not to abandon Angular 2
like they did with 1. Angular 2 should have been named something else to avoid
all this confusion around Angular 1's abandonment.

------
GiorgioG
It's hard to take this post seriously when this guy has barely 5 years in the
industry.

If you're building a large enterprise app with lots of engineers not familiar
with either framework, Angular 2/4 wins hands down.

~~~
chrisco255
Angular 4 is a few months old. It's not mature and the ecosystem is immature.
Even the official Angular Material2 project is still in beta. You contrast
this with React's ecosystem of UI components that have been built up over
years...it's no contest. You can build better looking, better performing UIs
with much less effort and they work great, even in IE11 and Edge.

------
skylark
I can't help but feel like all of these posts are a bit overly dramatized.

As much as people complain about Angular, I think it's completely fine for the
majority of use cases at large scale. So is React. So is Vue. Even Angular 1
is fine. In practice I've never run into most of the issues people preach
about. Two way data binding isn't the devil. One way data flow isn't a
panacea.

My developer happiness has always been contingent on the quality of my
coworkers, and not on the framework itself (all of which, I feel, are great in
their own ways.)

------
addicted
Occasionally I have thoughts like these. And I often write them down. But
rarely (never) publish because I am always hit by the idea that no matter how
bad a certain framework/project is (especially open source), unless it's
actively malicious, there are real people who are actually putting time and
effort building and maintaining these projects.

There is absolutely no reason to dismiss all their efforts.

I can provide a critique and state my preferences for a certain framework over
another without demeaning the project I don't find preferable.

The O/S

------
Draiken
I stopped reading at

> mature ecosystem of tooling and libraries

That tells me the author is either blind or so lost in his world that he
thinks this is actually true.

This fanboyism around languages and frameworks is apparently ever-growing.
Haven't we learned by now that everything is about trade-offs and there is no
One True Way?

~~~
SamUK96
Unless you're coding in
[https://en.m.wikipedia.org/wiki/Brainfuck](https://en.m.wikipedia.org/wiki/Brainfuck)

------
Nekorosu
Though I do think Angular 2/4 is inferior to React/Redux combo this article is
very biased and not good for a constructive discussion and comparison of those
frameworks.

------
theodorejb
I strongly disagree with the claim that "React Is Much Simpler." React on its
own may be simpler, but by the time you add libraries for routing, HTTP,
dependency injection, date/currency formatting, animations, and all the other
stuff that Angular provides out of the box, the complexity starts to look
pretty similar.

Furthermore, because you have to rely on third-party libraries for all the
features that React doesn't provide, you have to worry about separately
keeping them all up-to-date. What if there's a critical bug fix in the latest
version of your HTTP library, but it's only compatible with the latest version
of React, which isn't compatible with the router version you're using? In my
experience it takes a lot more time to keep dependencies up-to-date and
working together with React than with Angular.

~~~
TheCoelacanth
There are already browser standards for HTTP and date/currency formatting. At
most you need a polyfill if you want to support really old browsers. CSS
transitions also take care of most use cases for animations. A library for
dependency injection is just over-complicating things. You don't really need
it.

The only thing in that list that I have ever felt a need to use a library for
is routing.

------
pjmlp
I doubt we will ever do React.

All the SPA projects at our company are Angular based and I don't see any
plans to change it.

------
bob1029
My experience with Angular is that it was sort of the gateway drug of SPA
architecture.

Back in 2010-11 I first tried out Angular to experiment with the SPA concept.
This was hard to reason with back in those days, as most client DOM was still
server-generated (at least for initial requests). It was really a big paradigm
shift for a lot of developers, myself included. I found that Angular's
foundations (directives, services, controllers, etc.) helped to constrain my
thinking in ways that made the SPA concept more clear. The angular ecosystem
in those days was really a haven of SPA-oriented thinking that couldn't really
be found elsewhere on the web.

Fast forward to now, SPA architecture is essentially the norm. Almost every
web-enabled device now has a full javascript runtime. Additionally, it has
actually become an anti-pattern in some cases to force server-generated DOM on
the client, as each clients' JS runtime is usually better suited for
interacting with its specific DOM quirks and handling device features.

Now that SPA has become a more mainstream way of thinking, developers have
begun to seek out ways of implementing this architecture with fewer
constraints (and arguably bloat) than Angular could bring to the table.
Frameworks like RiotJS are starting to explode in popularity because
developers still want some fundamental SPA-style framework, but also want to
maintain the ability to interact with the DOM in a more direct and vanilla
way. When working with Angular, I found myself constantly trying to find (or
god forbid write) the angular-compatible directive wrapper for whatever 3rd
party javascript component I wanted to add to my project. Being able to simply
include something like moment.js directly in my project and use it exactly as
their documentation indicates has been a massive productivity gain for me and
my team.

I took a few cracks at Angular 2, but there was something that always felt off
about the component system and how more complex pages were composed. Their
attempts to bring typescript into the fold only served to confound things even
further for me. I know this is a hugely-subjective thing, but it was basically
the end of the road for my Angular experience. It took me 5-6 weeks to get my
team truly productive on Angular 1.x. I was able to bring them up to speed on
RiotJS in a single afternoon (the router being the hardest bit).

------
sopooneo
This article includes a statement I've seen several time before: "flux is more
of a design pattern then a library or framework". This statement drives me to
unspeakable levels of fury. What does that mean? It's like saying "Alvins ball
is more a boulder in Yosemite than a mid century school of literary
criticism". They're two totally different things!

Someone who understands the statement, could you help me? Does it mean that
there is a design pattern so light that some particular library which implants
it would be trivial to recreate?

Any answer, I beg you, please clearly distinguish between the very different
concepts of design patterns and named code projects which implement them.

------
rickcnagy
Having just seen a whole bunch of React shops when interviewing for a front
end position, a _lot_ struggle with React but also really enjoy it. Definitely
don't see a significant difference in the end from Angular, they're really
similar frameworks.

I think the ones that really have invested in making React work in their org
but move a _bit_ faster, but Angular making strong decisions and providing
really good patterns out of the gate is extremely valuable.

Both are great frameworks, so adopt works best for your company, your team,
and your product!

------
javiercr
From the article:

> We can be almost certain that React & React Native are a competitive
> advantage. We can see evidence in how Facebook simultaneously launched
> Snapchat-like “Stories” across four applications (WhatsApp, Messenger,
> Facebook, and Instagram) in its product suite.

> It’s not hard to infer that React was a key reason why Facebook was able to
> do this so rapidly.

Is there any actual evidence that React / React Native was used to build the
Stories feature for any of these apps?

~~~
chrisco255
No. And it's a fair point. I might be reaching a bit. But I do think Facebook
sees real productivity gains from using React Native in production and those
gains benefit their velocity as a whole.

------
bla2
_At the peak of JavaScript fatigue in 2013_

I don't think JavaScript fatigue peaked in 2013. FTA:

 _it is quite easy to maintain a large, flexible, well-engineered SPA with
React, Vue, or other lightweight JS libraries, even at enterprise companies
with large teams._

Vue's initial release was just over three years ago. Other technologies used
by enterprise companies has usually proven itself for a decade or two.
Articles like this don't help with JavaScript fatigue.

~~~
chrisco255
Front end technology has advanced rapidly in the last 5 years. You can't
compare the back end as much. Although there's innovation there too from new
languages and functional paradigms.

------
colonelpopcorn
This article ignores the power of Microsoft backing Angular in ASP.NET as a
first class citizen with typescript. Most companies don't care about what
stack they use, and if their Microsoft partnership agreement offers free
Angular + TypeScript training? Most companies will go with Angular if they
don't have specific performance needs.

------
Achshar
I'll just be the sad puppy sitting in the corner writing everything in vanilla
es2016/17\. I never had any problems and everything works. The amount of code
I write is no more than the angular code I write at work. Never used react but
it looks like a jumbled mess. Vanilla JS is pretty sweet and has everything I
could ever need.

------
ratbeard
I'd agree that angular 2 was a letdown. Seems like most people are like me and
like typescript, the cli, and a better router, but those could have been
incrementally added instead of starting from scratch.

It still boggles my mind thinking about the massive amount of effort google's
large team spent on ng2, library authors spend porting ng-bootstrap, plus
every app that will be rewritten, plus the interim confusion of having 2
versions of libraries, documentation pages, etc. For improvements in some
areas, more complexity in others. And I think to the point of the article, it
feels far behind react in a lot of advanced development features as it is
still trying to get a solid footing. Just saving a file and waiting a few
seconds for a full page reload is much worse than the gulp then webpack
browserupdate system I setup for ng1 apps, and the cli is not _that_ much
better than a custom gulp task I setup to generate new components and services
in ng1.

My theory is the primary motivation for ng2 came from the angular team not
wanting to maintain a js and dart version of the library, so they wanted to
move it to a single codebase that could compile from nativescript/typescript
to both, and it was an easy sell to all the people who identify in the angular
tribe.

Some specific things I don't like in ng2:

\- Too many ways to do forms. Template driven vs reactive, with some things
like mdAutocomplete I could only get working w/ reactive. You can do [ngModel]
+ name attribute, [ngModel]="name", [(ngModel)], formControl, formControlName.
Little things like adding `Validators.required` isn't picked up by the view,
so you have to specify required there too to get the little (*) asterisk in
the view for mdInput

\- Testing got much harder to do, with mocking every dependency. Just when ng1
made frontend unit testing pretty painless to do, it feels like a step back.

\- The DI system in general feels like waaay too much complexity for the much
smaller benefits it brings now that `import`s are available. I was reading the
docs to try to figure out an equivalent to a factory function and I realized
even if I could figure it out, another developer or myself in 6 months would
not understand it. Mocking imports for testing would be good enough, I think.

\- Unless you plan to be an "ng2 developer", dipping into the 100+ ;) rxJS
observable methods is a good way to confuse your teammates or future self.
Have fun remembering what mergeMapTo vs switchMap vs forkJoin do. Observables
are cool, but imo another case of too much complexity and too many ways to do
things for the benefits. I haven't seen good guidelines of at which point in
your app do you transition from observables (returned from http request) to
plain objects - should you pass observables down through components for things
that can change, or rely on the component seeing its input property changed?
Should I implement a snapshot property on my objects that can change, similar
to how they do routes? It is silly to me an http request response is modeled
as an unending sequence of events, instead of a promise. The only benefits I
see like being able to specify `retry(3)` could be implemented as an option in
your api service that wraps http, and would probably be more consistent that
way.

\- A lot of small things are gone, like a capitalize pipe, ngFor iterating
over objects. A little slower when getting started on an app when you have to
add them yourself. They got rid of things like http interceptors and route
resolves, and are adding them back in now after people complain. Even stuff
like adding a query param to a url required a bad java-like api and multiple
lines of code. They improved that since, but why start w/ a step back from
ng1?

\- Speak of route resolves, they have gone from a simple 1 liner in the route
definition to being a 10 line standalone service, which you have to import and
add to your providers array.

\- Hasn't been an issue for a while, but having your global ng-cli which
housed the webpack and typescript config(?) go out of sync w/ your local
version, and your angular/core version, was a really confusing and painful
upgrade.

\- I like typescript, but it does have strange errors where it seems to have
an older version of a file cached and you need to restart the server to fix
it. Seems to happen more when importing a class that isn't @Injectable()?

\- It is slower. My livereloading browsersync ng1 apps were faster and more
fun to work on.

\- It is a huge pain to rename things or reorganize your files. VSCode was
rename symbol which is nice, but to stay consistent when renaming a component
you need to rename: each of the 4 files+directory, all the imports, the
`selector` and all tag references to it across the app, the `.my-component`
css classes. I do a lot less refactoring of component names or directory
structure in ng2 than a glob import style ng1 app, where you don't need to
manually requiring everything.

Hmm, maybe should write a blog post about this.

~~~
emodendroket
> It is slower. My livereloading browsersync ng1 apps were faster and more fun
> to work on.

Wasn't performance meant to be the whole raison d'etre of the rewrite?

------
emodendroket
What I'd like to see is really mostly for them to just keep maintaining
Angular 1.x. I don't care about "microlibraries;" I want a sane set of
components that work well together, even if they're not all necessarily the
absolute best in class.

------
ernsheong
I'm hoping Polymer 2 will gain more traction. Anyone out there hoping for the
same thing?

~~~
ergo14
It is gaining traction - almost 8k users on slack channel stedily growing -
new components are getting released on webcomponents.org every day.

~~~
ernsheong
I somehow find the dependency management system of Polymer 2 (loading script
tags in a component), is going back to the old school ways/days. There is no
dependency isolation, modules are loaded to the Global... v.s. ES6 imports via
webpack, for example. Granted, module imports are not browser ready yet. Guess
we'll just have to live with it for now.

Happy for someone to point out a better way for Polymer 2 dependency
management that feels... less dirty.

------
luord
> Two way data-binding was a feature in 2013 and Facebook said it was a bug.
> It turns out they were right. Ember, Angular, Vue, and others would later
> adopt the one-way model.

No, they weren't. It's just a different way to manage state. And VueJS employs
two-way binding so I'm not sure what was the intent here.

> Redux brought predictable, functional, maintainable state management to
> JavaScript.

Stopped reading here. Too sensationalist.

~~~
ElatedOwl
>And VueJS employs two-way binding

Two way binding is an anti-pattern in Vue.
[https://vuejs.org/v2/guide/components.html#One-Way-Data-
Flow](https://vuejs.org/v2/guide/components.html#One-Way-Data-Flow)

You actually get console warnings if you try to affect state in that manner.

~~~
luord
That's about parent and child components, not about the state of a particular
component. VueJS keeps two way data-binding between the template and the
component; react does not and needs to handle events from jsx (or whatever one
is using as template) explicitly.

And making child controllers directly alter the state of their parents is
generally thought as an anti-pattern in angular 1 too, as far as I understand.

~~~
ElatedOwl
Thanks for the clarification but I'm still a little confused.

>VueJS keeps two way data-binding between the template and the component

In what sense? If you need to update your data on the JS side from the DOM you
have to use events. There's v-model, but this is just syntax sugar for binding
an event on input to update the value prop.

~~~
luord
> In what sense? If you need to update your data on the JS side from the DOM
> you have to use events. There's v-model, but this is just syntax sugar for
> binding an event on input to update the value prop.

Which is why calling two-way data binding in js a "bug" is so weird (for lack
of a better word). In angular, two-way data binding is, ultimately, also
syntactic sugar over DOM events.

For that matter, _everything_ every frontend framework provides is syntactic
sugar over vanilla javascript.

~~~
ElatedOwl
All I'm saying is that Vue doesn't do two way binding. v-model translates
directly into a DOM event, ie

<input v-model="someProp">

is equivalent to

<input v-bind:value="someProp" v-on:input="someProp = $event.target.value">

Which, as far as I understand, is exactly how React handles it and is deemed
one way binding. ¯\\_(ツ)_/¯

~~~
luord
We seem to be about to start going in circles so I'm cutting here with one
last remark: For what it's worth, in Angular one can also make the events
explicit, and yet in there it is called two way binding.

------
gregors
Chocolate vs Vanilla argument here

    
    
        while(true){
          if(dislikeAllCurrentFrameworks?()){
            inventNewFramework()
          }
        }

------
brawny
This is why I like Aurelia, its much lighter in terms of speed and amount of
code, while still being a fully flared framework like Angular. Sure theres
React/Redux Vue/Vuex but why do that setup when you can literally go au new
hit enter about 4 times and your app is ready to code and build.

------
Manager
Article is basically why use React over Angular.

One thing though - Facebook succeeded because of the sheer amount of money
plowed into the team. Our team is succeeding with Angular at the moment and
feel pretty strong that it solves our front end rather splendidly.

Disclaimer - I do like React, it has its place.

