
React vs. Angular 2 - kevindeasis
https://docs.google.com/document/d/1Ah9IJ72DhV4AzoZ1TJUnMzj42PzQrLrwQUkg9koO0dg/edit
======
OrthoMetaPara
Isn't this like comparing apples to a fruit salad? Quoting from the React
website, "Lots of people use React as the V in MVC," whereas Angular is the
whole kit `n' kaboodle.

I thought React was supposed to be used in tandem with a Flux-like component
that stores the state of the application, thereby allowing the developer to
adopt the functional reactive programming style.

Anyways, I think React will be short lived, because anyone who _really_ wants
to hop on the FRP bandwagon will pick up something like [http://elm-
lang.org](http://elm-lang.org) in order to fully achieve Satori. I mean, if
you're going to drink the Kool-aid, you might as well down the whole pitcher.

~~~
spankalee
React will be short-lived because of Web Components, not because of Elm.
Either that, or React will evolve to be a Web Components framework. The days
of proprietary component silos are numbered, IMO.

~~~
citrons
Here a discussion on React github about WebComponents:
[https://github.com/facebook/react/issues/5052](https://github.com/facebook/react/issues/5052)

------
idibidiart
Maybe React core is in ES5 but most React components are now bejng written in
ES6/7 with things like decorators and async functions, not to mention
immutable data structures, and you may use Flow to substitute for static
typing.

I can't believe in the team behind Angular 2.x they STILL have the same basic
flaw in their thinking about UI development: their ideology is in
contradiction to the idea of keeping it simple yet flexible.

------
spion
Two corrections:

1\. You can use types with React, either via Flow or in TypeScript with TSX.
Unlike with Angular, with React you can also get type checking even in the JSX
template (checking for valid component property types included, even with
TypeScript)

2\. You can "externalise" your render method if you really want to by simply
writing

    
    
      import MyComponentTemplate from './external-template.tsx'
    
    
      let MyComponent = React.createClass({
        ..
        render: MyComponentTemplate
        ..
      })
    

then in external-template.tsx

    
    
      export default function render() {
        return <template goes here>....
      }
    

Most React users think its unnecessary, but it doesn't mean its not possible.

~~~
tlrobinson
React v0.14 adds "stateless functional components" syntax, which essentially
makes your external-template.tsx a valid component on its own (with the caveat
that no state or lifecycle methods are allowed):
[https://facebook.github.io/react/blog/2015/10/07/react-v0.14...](https://facebook.github.io/react/blog/2015/10/07/react-v0.14.html)

~~~
tracker1
There seems to be progression into breaking apart components that have
decision trees with components that are simply rendered... I've had a tendency
to favor this myself.

Also, simple components can defer events to prop/parent binding.

------
Omnipresent
For someone who hasn't had to do much work on the front end JS technologies
like Ember, Angular, React, etc. What is a good resource to start learning
Angular 2 (even though its not out yet)? I came across ng-book2 [0] but I've
heard mixed reviews about their first book.

[0] [https://www.ng-book.com/2/](https://www.ng-book.com/2/)

~~~
terda12
Honestly? I would start with React. The way Angular 2 has been going, they are
adopting a lot of new ideas from React.

~~~
roebk
The team I'm apart of started a project 2 months ago. We chose React and Redux
over Ember, Angular, et al. A main decision factor was that we needed the
server to render our initial HTML, neither Angular nor Ember can achieve this
easily, we'd most likely have to lean on a third-party service. Angular looked
particularly unattractive with Angular 1 being as good as dead and we didn't
feel confident starting with Angular 2, there we're simply too many unknowns.
We loved the hot loading & the redux-devtools features, turns out these have
given us a decent productivity boost.

2 months into the project I'm confident we chose the best tools for the job,
there's been absolutely no regrets from the team members.

~~~
pluma
The problem is that the surface of Angular is incredibly complex.

With React, you have components, which are just things (classes or functions)
that convert a set of properties to a subtree of more components (ideally
mostly ones that directly represent DOM elements) and do so deterministically
and reproducibly.

With Redux you just have objects ("actions") representing changes to your
application state and functions ("reducers") that convert an action and the
current state into the future state. There are also functions ("action
creators") that help you create the former and functions ("middleware") that
affect how Redux processes them.

With Angular1 you have templates and directives and components and models and
scopes and controllers and filters and injectors and services. And services
can be constructors or factories or providers or values or constants or
decorators. And scopes can be isolate or nested and there is the digest cycle
and there are watch functions and if you do anything async outside of Angular
you need to make sure to trigger the digest cycle (but not if you're already
in the digest cycle) and I haven't even talked about interpolation yet.

Angular2 is slightly better but the docs are pretty sparse and many people's
brains will still shut off as soon as they hear "dependency injection" and
have you fucking seen what they have done to HTML to maintain their false
illusion of "it's just HTML and JavaScript, designers can understand this"?

React doesn't need you to think. Initially the API made you define components
by using a magical function, then they extended it to allow just using ES2015
classes, now you can even define simple components as plain old functions. The
surface has shifted from minimal to nearly non-existent.

Redux has more conceptual overhead than React ("Wait, reducers can't have
side-effects? Where does my AJAX go?") but most of the learning time is spent
un-learning concepts you take for granted (e.g. you shouldn't mutate state,
your components should ideally not have any state at all and it's perfectly
fine to normalize your state because you only need to derive it when it
actually changes). The number of actual concepts Redux brings to the table is
fairly low.

Angular is a battleship. React+Redux is an attack submarine.

~~~
hitekker
> Angular is a battleship. React+Redux is an attack submarine.

> The value of the battleship has been questioned, even during the period of
> their prominence.... battleships were increasingly vulnerable to much
> smaller, cheaper weapons...[11]
> [https://en.wikipedia.org/wiki/Battleship](https://en.wikipedia.org/wiki/Battleship)

I'm not sure if your metaphor was intentional, that Angular is like a flashy,
seemingly powerful but ultimately archaic, dead-on-arrival platform, but I
appreciate it nonetheless.

~~~
pluma
> I'm not sure if your metaphor was intentional

I'm not denying it was...

------
vertebrate
What is this FRP thing JS developers talking about? What I should read to
learn more about it?

~~~
tunesmith
If you ignore the whole thing about how frp is not FRP, and how javascript
developers really only mean frp, then a good place to start would be learning
about RxJS.

FRP is deterministic and referentially transparent, frp is not. Key concepts
in FRP are behaviors, events, signals; key concepts in frp is streams,
observables, subscriptions. Although I'm not expert with either, there's a lot
of overlap and term overloading, and I might be explaining this all badly
anyway.

~~~
spion
AFAICT, the simplest way of explaining the difference between FRP and "popular
frp" is that in FRP things are described as functions of time, whereas in
popular frp they are streams of events.

The "real" FRP is great for describing non-interactive things. They can be
used to describe anumations: e.g. a FRP behavior can describe the position of
a ball as a function of time:

    
    
      ballPosition :: t -> Position
    

whereas in "quasi" frp, the ballPosition is a stream of Position values:

    
    
      ballPosition :: (Stream Position)
    

Basically, quasi FRP is what you get when you sample real FRP at certain times
:)

------
pjmlp
\- Dojo

\- Prototype

\- jQuery

\- Ember

\- ExtJS

\- YUI

\- Knockout

\- Angular

\- React

\- place for the next cool framework in the upcoming two years

------
j1e
For job postings, it's still an Angular 1.x world out there:

[http://www.indeed.com/jobtrends?q=%22angularJS%22%2C+%22Reac...](http://www.indeed.com/jobtrends?q=%22angularJS%22%2C+%22ReactJS%22%2C+%22EmberJS%22&l=)

------
kevindeasis
I am hesitant to spend time learning on react because of this:

" SomeCallMeTim: I have been learning new technologies pretty much
continuously. It's not impossible, especially if you follow sites like Hacker
News, to keep a finger on the direction of the industry, and then try to stay
on top of the next new hot technology of the year. But I hear you on the
"worse" technology sometimes winning. You mentioned Java; it was worse than
just about all other major contenders, and is only finally losing popularity.
On a current technology fad: React seems to be designed to ignore 40 years of
accumulated software best practices. [1] Separation of concerns? Who needs
that any more? And the rationale for it is that it allows teams of 100
developers work together on an app. Open standards? Nah, how about lock-in to
custom language extensions that will prevent you from migrating your code to
the next web standard! Much better. And how many app teams have 100 or more
active developers? Probably fewer than a dozen, and I submit that none of them
probably should. Certainly not the Facebook app: It has a lot of features, but
not that many features, and yet it has a 150Mb footprint. When I hear things
like that, I can't help but fill in "junior" or "mediocre" in front of
"developers." React helps to prevent people from breaking each others' code
when you have bloated development teams filled with junior developers. React
has some cool ideas, but all told I think it's a step backward for software
engineering, and certainly isn't as much of a help for small teams, especially
if you want to have a CSS/SCSS/LESS expert styling your product without having
to dig through JSX files, for instance. The Java rationale was similar, IMO:
You can use the Java abstractions to allow lots of mediocre developers to make
contributions to a product without breaking each others' code. At least not as
frequently as when they can poke right into random data structures and change
things arbitrarily. If it weren't for Google's decision to require Java for
Android, I think Java would be relegated to big company web backend
development. I do like React's idea of the Virtual DOM for optimization, but
you can get that without using React. [2] React Native is great for using
native components and driving them from JavaScript, but it's also not the only
game in town. [3] Back to the original point, though: You can stay on top of
the Hot New Technologies, but when there are good technical reasons to use
alternate technologies, stay on top of those as well. And then explain clearly
to your clients (or employers) why the current fad is a fad, and how to get
the key benefits of that stack without its drawbacks. Oh, and choose clients
(or employers) who will listen to strong technical arguments. :) [1]
[https://www.pandastrike.com/posts/20150311-react-bad-
idea](https://www.pandastrike.com/posts/20150311-react-bad-idea) [2]
[https://github.com/Matt-Esch/virtual-dom](https://github.com/Matt-
Esch/virtual-dom) [3]
[https://www.nativescript.org/](https://www.nativescript.org/) "

