
Angular 2 versus React - ihsw
https://medium.com/@housecor/angular-2-versus-react-there-will-be-blood-66595faafd51
======
plexicle
To me it really feels like Polymer is taking all of the pros from both of
these "libraries" or "frameworks" or whatever you want to call it and none of
the cons. Why aren't we talking more about that? Polymer is a fraction of the
size. It's one of several ways right now to write custom components. React and
Angular2 do the same thing yet they are both bloated and force tons of tools
and tech down your throat. For what?

Sorry, no. My 2016 isn't going to come down to me deciding between React's
perverted DSL and crazy toolchain or Angular2's massive cluster$&!% of a
bundle with cringe-inducing template syntax. No thanks.

I have followed this long enough. To a lot of people, adding Flux, Webpack,
TypeScript, whatever, might seem like the beginning of the future of front-end
development, but I see something different. I see 2016 as the year that people
slowly begin to realize that while components ARE the future, you don't need
big frameworks or libraries or 4000 node modules. This is the year of pure,
well-written, and fast web apps. This is the year of framework fatigue.

~~~
Kwastie
Why did Google create Polymer? Google isn't using it. This is almost the same
'problem' with "AngularJS by Google", it's almost never used by Google.

Edit: The reason I like React more is the fact that Facebook uses it in a high
traffic production setting.

Edit 2: I think the whole Javascript (or framework) fatigue is just a
'transition problem'. Old tools are getting replaced by new tools, causing
confusion..

~~~
sehr
YouTube Gaming & the new Google Play Music are both built with Polymer, both
moderately complex consumer facing sites.

~~~
mkawia
Google Play was poorly made

[https://play.google.com/store/apps/developer?id=itdisplayswh...](https://play.google.com/store/apps/developer?id=itdisplayswhateversattachedtheid)

~~~
sehr
Kinda beside the point, and I'm not sure the play store is using the same tech
stack as play music. Two different things

------
coldtea
> _Sigh. Yes, Angular is a framework, React is a library. Some say this
> difference makes comparing them illogical. Not at all!_

Agree. This BS "oh, it's like comparing apples to oranges" knee jerk reaction
should stop.

For one, even if Angular is a superset, we can always compare the parts that
both have: component model, templating, etc.

Second, when we say React we almost ALWAYS mean React + Router + some Flux
lib, etc. -- so all the same things you get with Angular, just cherry picked.

Third, we can just as well compare Angular (or any framework) with building
something from scratch with vanilla JS too. Nobody said we have to compare
them "as frameworks". We can compare them as different "ways get a web app
done" (with/without framework, without framework but with x lib, etc).

Fourth, we can always compare apple's to oranges. Here's a comparison: oranges
have more vitamin C than apples, and are better for scurvy (haven't checked
the actual vitamin C stats, but you get my point).

~~~
ebola1717
Can you use Angular's components & templating outside of the rest of its MVC
architecture? Despite the insistence on HN that React = React + Router + Flux,
I've been using just React with plain js objects for models, and I like it
exactly because it's an easier way of writing simple interactive views.

~~~
zeppelin
What if it can't? (I don't develop apps using Angular, so I really don't know
the answer...)

Then it's just a con for Angular, but also a pro for providing a default MVC
architecture to rely on. It's a design choice that can be both good and bad.

------
PaybackTony
This is continuing to shape up to be another one of those preference debates.

I prefer the Angular approach, as its end goal is to simply make web markup
what it should be: Interactive. The downside being that you're forced into
Angular's opinions for better or worse.

I don't prefer the more "tangled" approach of React. I call it tangled as it's
mixing two flavors in one "view", whether you like it or not: JS and HTML.
Many people like the approach, and I can see why they do. I don't.

Those are preferences. So much more goes into making an app efficient,
testable and expandable. The biggest ingredient is comfort. If you and your
dev team are comfortable with React, that's going to be your best option. It's
not the wrong option, it's a great option. For me, it's Angular.

However, I feel compelled to say that the debate should be Angular 2 v React.
Having used others (... Ember....) it just doesn't make much sense to use
anything outside these main 2 contenders unless you're using some of the new
"cool" web components based stuff. Angular is solid. React is solid. Compare,
contrast and make your decision based on how comfortable you feel with the
getting started docs.

~~~
vdnkh
> I call it tangled as it's mixing two flavors in one "view", whether you like
> it or not: JS and HTML.

Doesn't Angular mix HTML and JS too, except in the HTML file?

~~~
EvanPlaice
> Doesn't Angular mix HTML and JS too, except in the HTML file?

Angular2 doesn't. Like React it uses a HTML-like templating syntax to generate
views. Nothing is mixed in Angular2, everything is defined in JS and rendered
as HTML.

------
onetwotree
React's learning curve is _tiny_ compared to Angular. With React, you need to
understand the component API, which consists of about 5 methods that one uses
regularly, and the top level API, which consists of 2 (or just 1 if you use
ES6 class syntax to create components).

And as the article points out, it's just JavaScript.

~~~
guftagu
When you factor in the learning curve of the usual tools that go with React
like Flux/Redux, Webpack, Router and whatnot, the combined cognitive load
becomes a lot.

~~~
Reedx
Yeah, additionally React has a serious paradox of choice problem.

Which of the dozens of CSS solutions should I use? Inline styles or not? Which
of the dozens of Flux libraries? Isomorphic/universal or client side? If
Isomorphic, Express or Koa? Does react-router work with the choices I've made?
Webpack or Browserify? It goes on and on...

I love React, but the environment and best practices are unclear to say the
least.

Just look at how many starter kits there are and how big they tend to be:
[http://andrewhfarmer.com/starter-project/](http://andrewhfarmer.com/starter-
project/)

Can only imagine how many of the choices made are going to be deprecated in a
couple months.

Edit: Heh, and now that I've read the article, I see they hit on this issue.
:)

~~~
aboutabel
There is also a lack of best practices, combined with constantly breaking
changes. Every tutorial before the last month is already outdated, and
everybody has a different way of setting up webpack / isomorphism /
templating.

~~~
Kwastie
>lack of best practices

How many 'best practices' do you need? What about 'higher order components'?
Use proptypes in development? 'Avoid local state'?

>constantly breaking changes

I call bullshit, what was the last breaking change? Every large release still
supports the old deprecated syntax, but with warnings.

>Every tutorial before the last month is already outdated

That is a big exaggeration; I wouldn't advice anyone to use 'pre es6'
tutorials, but the concepts still apply.

>everybody has a different way of setting up webpack / isomorphism /
templating.

No they don't, maybe a small differences and what do you mean with
'templating'? It's not Angular.

~~~
deboflo
I call bullshit on you calling bullshit on every point of this comment.

> How many 'best practices' do you need?

Actually, there should only be one way to do something in a framework. While
not a framework, think about the Go language. Go is a very strict, almost
paternal language that 'enforces' best practices in the language itself by
giving you only one way to do something. Angular, on the other hand, provides
numerous ways to create a service. Because of this confusion, the Angular team
provides best practices. It's like saying, 'we screwed up in designing this
thing, so you have to read all the documentation to find out the subtle
differences in all this bullshit.' It's not the lack of best practices that
concerns me, it's the abundance of them that gets shipped with a bloated
framework that wasn't designed well.

>Every large release?I seriously doubt it.

Think of all the pain involved in removing all of the digest cycle code when
switching from Angular 1.4 to Angular 2.0.

> No they don't, maybe a small differences and what do you mean with
> 'templating'? It's not Angular.

Seriously? There are no small differences between Django templates, Soy
templates (client and server side), and Angular templates to name a few. They
are all very different yet they do essentially the same thing. At least Soy
templates can be used outside of a framework (with either JS or Java).

~~~
Kwastie
My comment is about React. I am not defending AngularJS.

------
jerf
Or, much shorter, Angular is creating an inner platform [1], and React is
extending the platform that already exists to do more work.

[1]: [https://en.wikipedia.org/wiki/Inner-
platform_effect](https://en.wikipedia.org/wiki/Inner-platform_effect)

------
antoaravinth
If anyone is new to both frameworks Angular 2 or React; I would prefer React.
I have learned React in a day. I can use my existing knowledge of js in React
(for, if etc), whereas in angular learning those directives is still a pain
(in Angular 2 as well).

I love the fact how each component in React can be composed! Its just beauty!

~~~
eruditely
What other tools do you use alongside it?

~~~
legutierr
Not OP but...redux and react-router, both mentioned elsewhere in the thread,
and both maintained here: [https://github.com/rackt](https://github.com/rackt)

------
Bahamut
There are some slight inaccuracies here, such as file size reporting - Angular
2 is fat at the moment only because it is bundling the whole kitchen instead
of just the one piece that is the library itself. The Angular 1 number also is
off too - this link is giving me 52.8 KB for example (minified + gzipped):
[https://ajax.googleapis.com/ajax/libs/angularjs/1.5.0-rc.0/a...](https://ajax.googleapis.com/ajax/libs/angularjs/1.5.0-rc.0/angular.min.js)
(all numbers I remember seeing for angular 1 were around 120 KB IIRC). I'd
suspect all the other numbers are off too, but I haven't investigated.

There is a strong argument against doing what JSX does in moving the HTML to
JS - you allow developers to fall into the trap of creating complex
conditional DOM that is hard to read without a disciplined team (if statements
all over the place with imperative DOM construction for example). Neither
approach of JSX or Angular's templating (or any other similar system to
either) are without its warts, and this falls into an opinion discussion
without real winners excepting for however a particular team prefers their
templating.

One thing that wasn't discussed but that may come into play - the performance
numbers out there for Angular 2 currently is extremely impressive. Optimized
Angular 2 code is generally performing at about 2x the rate of other
frameworks/libraries out there for UI rendering/repainting, and unoptimized
Angular 2 code is performing at roughly the same parity as optimized React
code (although optimized/unoptimized React code performs very similarly in
many situations, which is a huge benefit of React).

I'm personally on the Angular side of the fence, I prefer the more declarative
style to avoid the imperative DOM construction, but I could work with either
(and have worked/am working with both) if they are done right. Both are
impressive libraries though, and both have strong merits - at the end of the
day, it comes down to how your team works, and what they're productive with.
Both libraries are bringing excellent changes to how we do things in the
frontend...I just wish tooling was there in maturity, that seems to be the
greater pain point currently.

~~~
lewisl9029
> I'm personally on the Angular side of the fence, I prefer the more
> declarative style to avoid the imperative DOM construction, but I could work
> with either (and have worked/am working with both) if they are done right.

If by _declarative_ , you mean artificially limiting, then I agree with you,
but in my humble opinion, the React approach allows for far more declarative
UIs than approaches that come before it.

Templates ultimately limit UI semantics to the subset designed into the
template language. Modeling the DOM as a pure JS data structure gives you the
entirety of the expressive power the JS programming language, and allows you
to construct your UI as a pure declarative mapping between components/elements
and your app state (the approach taken by Redux and many ClojureScript
frameworks), with no imperative manipulation whatsoever.

~~~
Bahamut
React uses an imperative style, not declarative - when one uses
this.items.map(item => <li>{item.name}</li>), this is imperative, not
declarative. You are describing the DOM with imperative language - JSX cloaks
what is truly an imperative nature. This is made more clear with the non-JSX
equivalent. When one uses an if else-if else, while, switch, or other similar
control flow statements, one departs from describing, to imparting the details
of the implementation. The only part declarative about JSX is the conversion
of certain code into valid text/attribute values/etc. into the HTML, which I'd
hope is a minimum requirement of a useful templating language.

Angular's templating is clearly declarative since one is not making a
statement about how it arrives at its result, but purely describing it and
leaving the implementation elsewhere. Something like <ul><li *ng-for="#item of
items">{{item.name}}</li></ul> leaves the iteration implementation away from
the view completely. Every piece here is descriptive, not something more.

It should be noted that Angular 2's DOM model uses an AST under the hood, just
like React - fundamentally they are the same in the virtualization of the DOM.
Angular 2's templates are not true HTML either, but is closer to HTML than
React is in its syntax. It does limit what you can do, but that is the purpose
of templating languages - it limits what you can do to increase readability,
increase consistent patterns, and steer users away from dangerous usage. That
is an argument aside from declarative vs. imperative templating, and more
emotional than useful.

Now, both approaches have obvious flaws - both styles are easily (and often)
abused, but both also have simple conventions to keep it clean. Imperative
construction (ala React) requires one to carefully organize the control flow
to avoid convoluted template construction. Declarative construction (ala
Angular 1 + 2) requires one to avoid tossing too much in a singular template.
What is easier to work with, that is not for me to say as an absolute, but IMO
carefully organizing the control flow in template construction requires more
mental overhead to avoid constructing the template in a hard to read fashion,
and yet still involves the same ultimate basic strategy of having to create
separate components to avoid overly complex templates, which is what one has
to do with declarative template languages, but without the mental overhead of
accidentally abusing control flow in its construction.

~~~
barrkel
A pure functional map is imperative?

Defining UI as a functional map of the state is the one of the most
declarative ways of viewing the problem, IMO. Templates are maps too. The
problem with templates, historically, is that they've been used only for the
initial state, and abandoned for later changes because rerendering is
expensive.

------
DonHopkins
The foolish, totally avoidable, misguided and completely pointless mistake
that Angular 2 made was using a template syntax that was almost but not quite
completely unlike HTML:

    
    
        <ul>
          <li *ngFor="#hero of heroes">
            {{hero.name}}
          </li>
        </ul>
    

or:

    
    
        <web-component [title]="exp1" (close)="exp2()">
    

That is INVALID html and INVALID xml. That means you can't edit or process or
generate or validate Angular templates with any of the millions of existing
HTML and XML processing tools. They have completely forsaken the entire
universe of existing tools, for no good reason.

The Angular 2 template language gets absolutely zero benefits from arbitrarily
disobeying HTML syntax. There's nothing about the broken syntax that makes it
any more powerful or tangibly convenient that could be done by an HTML or XML
compatible syntax.

Maybe it appeals to Perl brogrammers, but the hip stylish syntactic appeal of
peppering templates with unique special snowflakes of punctuation like they
were so many christmas tree decorations does not outweigh the dire consequence
that you can't use an off-the-shelf HTML editor to edit and preview templates,
or use any of the many other existing HTML tools to do whatever they're
designed to do.

I've encountered Angular 2 proponents who were such blind zealots that they
actually refused to see any benefits of sticking to standard syntax and
enabling the use of existing tools. They would ask things like "why would you
ever want to edit an Angular 2 template in an HTML editor?" or "why would you
ever want to generate a template from another meta-template?" or "why wouldn't
you want to write your own Angular 2 template validators and editors and
processors?" or "why wouldn't you want to retrain all of your html designers
who can't use the tools and syntax they're accustom to?"

Yet they were still unable to name any tangible benefits of the broken Angular
2 template syntax, that couldn't be achieved with a non-incompatible HTML
syntax.

I'm afraid that they next thing they'll do is invent their own incompatible
version of Unicode.

------
JStanton617
React has a non-open license:
[https://github.com/facebook/react/blob/master/PATENTS](https://github.com/facebook/react/blob/master/PATENTS),
which basically says that an organization can no longer use React once it sues
Facebook for any (unrelated) patent infringement.

This is an automatic no-way for React for any major company

~~~
JoshMnem
Yes... I'm really surprised that people aren't talking about this more
seriously. They have removed the worst of it, but it still looks like it gives
Facebook an advantage in any patent conflicts with any company that uses
React, Immutable, Hack, HHVM, GraphQL, etc. anywhere in the dependencies. It
appears that the PATENTS file claims that if Facebook infringes on _your_
patents, you can't defend your patents without a risk of immediately losing
the ability to use React (or other Facebook library). Maybe a lawyer would be
able to make more sense of that PATENTS file.

I'm surprised that Apple might be using React, since they have had big patent
battles with Facebook:

[http://www.meetup.com/ReactJS-San-
Francisco/events/227071839...](http://www.meetup.com/ReactJS-San-
Francisco/events/227071839/)

[http://www.theguardian.com/technology/2015/jul/21/facebook-g...](http://www.theguardian.com/technology/2015/jul/21/facebook-
google-dell-hp-ebay-samsung-apple)

I've heard that Google doesn't use React, but I don't know how long companies
will be able to do that as Facebook libraries increasingly become dependencies
of other libraries.

~~~
spicyj
Google does use React now; as far as I know they are happy with the current
version of the PATENTS file.

~~~
JoshMnem
The last I heard, they weren't allowed to use it. If you could link to a
Google product that uses React, I'd like to take a look.

~~~
spicyj
I don't have links to any; they might be all internal. The current iteration
of the patent grant was developed in collaboration with Google to meet their
needs, so if there is any complaint they still have with it, that is news to
me.

Only public evidence I have of this is Firebase (owned by Google) being
unwilling to use React and then happy with the new license:

[https://twitter.com/KanYang/status/586636624349569024](https://twitter.com/KanYang/status/586636624349569024)

~~~
JoshMnem
I would like to find out more specific information. It seems like the section
of the license below says that you can never make any patent claim against
Facebook or you lose rights to use the software. Doesn't that mean that Google
could never initiate patent claims against Facebook, while Facebook could
still initiate patent claims against Google? It seems strange that Google (or
Apple) would do that. I am not a lawyer though, and the PATENTS file may not
mean that.

> The license granted hereunder will terminate, automatically and without
> notice, if you (or any of your subsidiaries, corporate affiliates or agents)
> initiate directly or indirectly, or take a direct financial interest in, any
> Patent Assertion: (i) against Facebook or any of its subsidiaries or
> corporate affiliates, (ii) against any party if such Patent Assertion arises
> in whole or in part from any software, technology, product or service of
> Facebook or any of its subsidiaries or corporate affiliates, or (iii)
> against any party relating to the Software.

------
novaleaf
I went "all in" on React a few weeks ago, but one probelm I had is the
complexity of the various samples/starter kits.

If anyone knows basic React and uses Typescript, and want to start using
Redux/ReduxSimpleRouter, you'll find this interesting:
[https://news.ycombinator.com/item?id=10837377](https://news.ycombinator.com/item?id=10837377)

~~~
silviogutierrez
Does this work with the new react router that was just released?

And did you try using Immutable.js ? From my understanding, it doesn't work so
well with simple router.

~~~
mambodog
The only reason you could have a problem using Immutable.js with redux-simple-
router is if you're trying to make the router's state into an Immutable.js
data structure, but there is no reason to do that. redux-simple-router manages
it's own part of the state, and you don't need to directly mutate it. You only
read it or dispatch an action to update it.

You don't need to make the entirety of your state tree an Immutable.js
structure, just the parts which are managed by the reducers you write.

------
sayem_
IMO the standout difference between Angular and React is how you think about
your application. Do you like functional programming paradigms and want to
apply them in writing your components? Use React. Do you think immutability is
too restrictive and love things like two-way binding? Use Angular.

That being said, I'm a bit disappointed to see no mention of Aurelia although
the author has mentioned other frameworks like Emberjs. I have been writing
production code with Aurelia for about a month and this has been so far my
best experience with any client side javascript framework. ES6 is very capable
and Aurelia did it right by staying out of your way for most of the times by
letting you write your components in plain ES6. All the while providing
binding capability(with beautiful syntax), a very powerful router and out of
the box package management support. I feel with all the commotion in framework
space, more people will appreciate the simplicity of Aurelia and that camp
will get bigger as time goes by.

~~~
dev360
> Do you like functional programming paradigms and want to apply them in
> writing your components? Use React.

s/React/Elm/g

------
pdeva1
Its the Angular 2 router that currently needs a lot more work. Currently
things like passing data down to child routes [1], getting current route
segments[2], checking active route etc are still not easily possible[3].

imho router is a big part of any large app and getting the details right is
essential there.

1\.
[https://github.com/angular/angular/issues/5330](https://github.com/angular/angular/issues/5330)

2\.
[https://github.com/angular/angular/issues/6260](https://github.com/angular/angular/issues/6260)

3\. [http://stackoverflow.com/questions/34571517/angular-2-how-
to...](http://stackoverflow.com/questions/34571517/angular-2-how-to-determine-
active-route-with-parameters)

------
rmanolis
I prefer angular over react. 1) It is opinionated (wasting time for decisions
is bad) 2) It is simpler to organize the code (it is MVC) 3)
(click)="onSelect()" is simpler. You dont have to create an object with "bind"
function like in react. 4) I dont want web designers mess with my code. So
putting html on JS is bad decision.

~~~
mercer
But do you want web designers to mess with your markup? Many of the projects I
work on still involve the 'old-fashioned' server-side rendering approach with
bits of jQuery for interactive elements. If a non-coder webdesigner were to
mess with my markup, everything would break anyways.

I guess what I'm saying is that I've worked on many types of projects in many
kinds of environments, and whenever a front-end framework was necessary, the
'webdesigners' were not. I've just never run into the situation where it
actually ended up being useful to create logic-less templates...

~~~
eseehausen
I don't have a horse in this race, but do you think that learning JSX is going
to be any easier for non-coders?

~~~
iLoch
Honestly I wouldn't hire a web designer that can't code a little Javascript.
It's been a while since knowing only HTML as a web designer has been
acceptable.

To answer your question though: they're probably about the same level of
difficulty, and I don't think it's a great argument for vanilla/React/Angular
because a person who doesn't understand code trying to modify stuff that is
controlled by code is going to break something regardless of what JS framework
you're using.

I prefer JSX because it's not pulling wool over your eyes - you're building a
JS app, not an HTML app - so let's stop pretending. The ESX syntax is just a
nice way of forming a hierarchy of class instances. The beauty of React is
that you could come up with your own syntax for doing that and use it just the
same, because React is just Javascript.

~~~
mercer
> I prefer JSX because it's not pulling wool over your eyes - you're building
> a JS app, not an HTML app - so let's stop pretending.

Yeah, that's what it really boils down to. Many of the principles we apply are
holdovers from when we used HTML and CSS for what it was originally intended:
pages with content.

The way I see it, HTML and CSS were not meant for any of these apps. But if we
are going to 'abuse' these technologies, we might as well chuck out the
rulebook and optimize for what _apps_ need to do.

That said, please don't do this if what you're making _is_ 'pages with
content'!

------
fouadf
What's your take on vue.js?

~~~
mercer
I quite liked Vue.js, but I really don't like how it takes the Angular
approach of putting 'js in your templates' (sort of). Furthermore, while I'm
holding off on 'universal apps' for now, I love being able to use React
server-side. If a component needs client-side functionality (sliders,
navigation etc.), it's trivial for me to create one component that renders a
simple server-side version and then initializes the same component client-side
with all the logic it needs.

Last I checked (about two weeks ago I think) server-side rendering was not
possible yet in Vue.js.

All that said I'm quite likely to use Vue.js instead of jQuery for many of the
use-cases where I would use jQuery instead of React. It's quite impressive!

------
EvanPlaice
tl;dr: The author is asserting that React > Angular2 because he's already
emotionally invested in the former.

React's greatest strength is also its greatest weakness. It requires devs to
compose their app out of multiple de-centralized parts. See 'javascript
fatigue'.

If your aim is to write an isomorphic React app, you CAN"T just use 'plain old
javascript' or anything that touches the DOM. If you care about SEO, this is a
very important implementation detail to consider.

Angular2's greatest strength is also its greatest weakness. It provides a
unified API for building apps. It forces you to do things the 'angular way'
which is no different from Angular1.

So far Angular2 is heavily biased toward Typescript because it was written in
TS and it was literally just released to beta 2 weeks ago. TS is good for devs
bridging over from strongly-typed OOP languages, and TS provides better
support for autocomplete in IDEs. TS is bad because it's not an 'official'
standard and it may be an awkward transition for existing JS devs.

TS is not required, I have been writing an Angular2 app in strictly ES6
despite the lack of documentation/support.

Both: require transpilation; use observables (ie redux vs rxjs); use a HTML-
like templating language for data binding; use the virtual DOM to speed up
rendering; discourage mutating the DOM directly to encourage rendering on
other platforms (ie mobile, isomorphic); require platform-specific shims that
don't touch the DOM; etc...

The underlying technologies of both are more similar than different. React
favors a more decentralized architecture. Angular2 favors a more monolithic
architecture.

/axegrinding

~~~
dev360
My understanding is that the SEO argument is becoming moot.

With emphasis on the word 'generally': "We are generally able to render and
understand your web pages like modern browsers."
[https://googlewebmastercentral.blogspot.se/2015/10/deprecati...](https://googlewebmastercentral.blogspot.se/2015/10/deprecating-
our-ajax-crawling-scheme.html)

------
scotchoverwine
As a new web developer, where do you draw the line between a web application
rendered server side and a SPA? I'm trying to develop a web app for creating
invoices for a niche market but in this case I don't see huge advantages for a
SPA over rendering HTML server side, the added complexity of a SPA doesn't
have that big of a reward, I still plan to separate the frontend and backend,
for example, writing a HTTP API that outputs json and in another process(or
server) consume the json and render HTML in the frontend server (and maybe add
some JS to improve interactivity). But everything this days seems about
creating SPAs for new apps and that's definitely the future it seems, I'm
wrong following this route or is that I'm just consuming to much SPA hype?

~~~
mercer
Perhaps in the future there will be a time where an 'old-fashioned' server-
side app is a bad idea, but right now I think it's still a perfectly valid
approach, and even preferable in some cases.

Consider whether your app will _actually_ benefit from being an SPA. Does it
negatively impact the user experience to have page refreshes? Or does it
provide significant benefits to do things client side? If the answer is 'no',
you might as well take what is currently still easier and more standardized,
and go for server-side.

But the next step is to ask these questions about _parts_ of your app. In
those cases using React or Vue or something similar for just those parts might
be a good idea. And if you've already separated front- and back-end, it
shouldn't be too difficult to realize (and it's a good reason to use React
server-side even if that's all you use it for initially!).

------
jlas
> You spend your time writing plain ‘ol JavaScript. That’s the future I
> believe in.

How about a future where you don't write any code at all? This is the beauty
of Angular's markup-centric approach, it's declarative so that means less
code, which means less opportunities for devs who _enjoy typing_ to screw
things up.

Jeremy Keith made a good point in his An Event Apart talk [1], where he talks
about HTML slowly subsuming interactive elements (e.g. like how HTML5 adds
better form type support). Angular is pushing things into this realm by
helping to take code out of the picture more and more.

[http://aneventapart.com/news/post/the-long-web-by-jeremy-
kei...](http://aneventapart.com/news/post/the-long-web-by-jeremy-keith-an-
event-apart-video)

~~~
jerf
If you're writing loops, and especially if you write loops that have
conditionals inside of them, you're writing code. "Declarative" is saying "I
want a list of all users", "For every user, display their name like this" is
just code.

I've seen a lot of template languages that claim to be declarative, I'm yet to
see a production template (that is to say, not an "example") that actually
_looks_ declarative and isn't just writing code in a language with poor
constructs for writing code.

~~~
mercer
Agreed. In every single project I've worked on that used mustache/handlebars,
haml, or some similar 'restricted logic' approach, the long-term result
consisted of view templates that contained hacks, a lot of logic hidden in
helpers that were often only used in one place, or just plain convoluted
solutions.

Furthermore, the main argument I hear is that these logic-less template
approaches benefit designers/front-enders, which doesn't make sense to me. If
your project is complex enough to require Angular or React, a non-coder front-
ender probably will have trouble working on it anyways. That's been my
experience at least.

------
pinchn
Angular is HTML-centric whereas React is JavaScript-centric. Succint!

------
spectrum1234
It seems like Redux + React is clearly going to win out. What am I missing?

Yes the ecosystem is constantly changing right now but the oscillations are
getting smaller not bigger. In my opinion Redux is the highest level and most
intuitive, just like React was for the view when it came out. It's only a
matter of time.

~~~
marknutter
Why does Redux imply React? I use Redux with virtual-dom and end up with far
less bloat.

~~~
spectrum1234
Interesting. Didn't know about that

------
Negative1
His argument about the 'Unix Philosophy' reminds me a lot of the argument
between using big web frameworks like Django vs smaller micro-frameworks like
Flask. Personally, I prefer Flask for the small projects I make because of how
nimble it is but it's hard to argue with the large organizations using Django
for massive projects to (seemingly) good effect. Ironic since I actually do
like Angular (sorry)!

Overall I felt the article was preachy and extremely biased. It's as if the
author was trying really hard to convince as opposed to just presenting the
facts and letting the reader make a choice based on the evidence.

I have concerns about ng2 but having made an effort to learn React as well I
think he dramatically oversimplifies it's ease of use for large scale projects
(where Angular shines, IMHO).

------
franciscop
From someone with years of experience with javascript, how is this "plain 'ol
javascript"?

<ul> { heroes.map(hero => <li key={hero.id}>{hero.name}</li> )} </ul>

~~~
insin
It clearly isn't, but it starts to _feel_ like it once you get used to JSX
syntax as sugar for nested function calls with attribute object arguments.

------
craigvn
"Angular 2 continues to put “JS” into HTML. React puts “HTML” into JS."

It seems fairly obvious to me that both approaches are wrong.

~~~
iLoch
Have you tried either? What is your concern with mixing the two? JSX is
optional, by the way. I have a problem with JS into HTML because that's
pseudo-coding. JSX tags are representations of classes and class instances,
which makes a lot more sense than a totally new DSL for scripting.

------
ry_ry
More importantly, when is the Flux Influenced, Stateful Template Enterprise
React methodology gonna get a catchy acronymn?

Asterisk-ux isn't cutting it, and god knows we need a buzzword.

------
EugeneOZ
"Yes I'm biased" was tl;dr actually. Or "I love JSX so much I can't even think
about frameworks without JSX".

------
bhanu423
I found smaller frameworks like riot.js easier to reason around and light on
almost all use-cases.

------
danso
> _React is a library. It’s precisely the opposite philosophy of large,
> comprehensive frameworks like Angular and Ember. So when you select React,
> you’re free to choose modern best-of-breed libraries that solve your problem
> best. JavaScript moves fast, and React allows you to swap out small pieces
> of your application for better libraries instead of waiting around and
> hoping your framework will innovate._

Just an aside, but who would've thought that Facebook would be the one to
develop around the Unix philosophy? Yes, I know that Google is a monolith, but
it became a monolith over one very specific feature and mission, whereas
Facebook had to accompany many kinds of user-interaction and behavior right
from conception. When Zuckerberg guest lectured CS50 (more than 10 years ago),
he didn't foresee FB doing open-source:

[https://youtu.be/xFFs9UgOAlE?t=17m25s](https://youtu.be/xFFs9UgOAlE?t=17m25s)

Excerpt: _" There's a lot of work that goes into making stuff open source. And
it's on top of whether or not you want to lose the competitive
advantage...there's a lot of support and licensing and all that stuff. We
found that it's been annoying"_

Yes, I know FB of 10 years ago is nothing like it is today, with much
different people and components...didn't React arise partly/mostly from
Instagram? Either way, I was encouraged to use it early on because it was
purportedly being used in Instagram production. Angular 1.x wasn't in any of
the big sites (other than DoubleClick?). It's nice to see it in more of
Google's sites now...but honestly, how it has currently been used has left a
bad taste in my mouth. I'm thinking of the Cloud/Compute Dev console. I spun
up a machine, thought I shut it off, found out I was $30 in the hole at the
end of the month. No big deal, I've done that with EC2 too...but the
difference is that AWS's interface, ugly as it may have been, was very easy to
use to shut down a machine (right-click, Terminate). I'm ashamed to say it
took me about 10 minutes to do it in the Google console. Part of it is
unfamiliarity, sure...but nothing interacted the way that I, as a developer,
expected it to. I finally found the button or whatever that brought up the
panel to show the Terminate option -- it was on the very bottom of my
widescreen monitor window...which is a huge visual gap from where the
instance-icon is. Maybe it's different when you have several instances spun up
and your eye is naturally drawn to the bottom...

Anyway, I know overly-enthusiastic-responsive design is not something that can
be blamed inherently on a framework. But it doesn't inspire enthusiasm when it
is poorly dogfooded on a developer-facing UI. I mean, it's _beautiful_ , but
in all the wrong ways, with boxes of live-updated charts showing
performance/activity metrics, but in no discernable hierarchy, as if someone
wrapped the page container with jquery.isotope. It's something I would show my
boss to make it look like I was doing something impressive but it was not
great for productivity.

In contrast...the way that React was justified in its announcement had
immediate appeal. The number of UI/UX things that FB and Instagram have to
constantly update because of their dataflow required React's kind of overhaul,
and it was easier to trust that they would not only maintain React, but design
and add features only as necessary.

~~~
debaserab2
> I'm ashamed to say it took me about 10 minutes to do it in the Google
> console. Part of it is unfamiliarity, sure...but nothing interacted the way
> that I, as a developer, expected it to.

You can make sloppy interfaces with any library or framework. Angular is no
exception. Neither is React.

------
dimgl
Oh my Christ, not this again. The framework fatigue is real. Why are people
trying to push Angular 2 or React even? The former is still under heavy
development and the latter is such a painful pill to swallow.

