
ReactJS vs. AngularJS - freezepro
http://freezeprosoftware.com/news/reactjs-vs-angularjs.aspx#.V4S5GJN97pA
======
danso
From the giant table-as-JPG:

    
    
        | metric | AngularJS | React |
        |--------|-----------|-------|
        | speed* |    1.35s  | 310ms |
    
    

-* "based on loading 1500 rows [according to some 2014 blogpost]

Also, the OP recommends AngularJS for "Experienced developers and coders",
while React is for "Casual developers and designers"

edit:

The narrative text is not much better. This sounds like something generated by
a Markov chain:

> _I’ll just mention that “one-way binding” in AngularJS 2.x and in ReactJS
> isn’t the same thing. The binding mechanism is completely different. It
> provides wider functionality in AngularJS 2.x compared to ReactJS. We’ll
> have to wait and see how it works in AngularJS 2.x. In ReactJS, the one way
> rendering flow is very straightforward, fast and easy to understand, debug
> and trace in comparison to “two-way binding” implemented in AngularJS 1.x._

~~~
Shengbo
>Also, the OP recommends AngularJS for "Experienced developers and coders",
while React is for "Casual developers and designers"

Yea, I'd like the author to explain why.

~~~
sgk284
He's trying to force a narrative, likely to justify his own personal choices
of technology.

------
kozak
While I'm totally pro-React for my own development projects, I appreciate the
fact that Angular 2 comes will a full set of predefined practices, so that
people who work with in are more "interchangeable" than in case of React. If
two different developers write a project in React, the project will likely
have very different sets of libraries and approaches. With Angular 2, it's the
opposite: two different developers will write their Angular 2 projects more or
less the same way. This can be valuable in enterprise environment.

~~~
hjnilsson
Yes, I think this is what will make Angular 2 win out over the long run.
Unless an ubiquitous React bundle comes along to solve that problem with the
React ecosystem.

It's just so much easier to build large projects when the framework solves
common problem for you in an opinionated way. Saves a whole lot of arguing
among developers and reduces the need for education when transferring between
projects.

~~~
kozak
Considering my arguments above, I can conclude that React and Angular 2 have
niches that only moderately intersect, so it's not going to be a single winner
out there.

------
49531
I don't think I've seen an article on this subject with more misinformation.
How is this even on the front page?

~~~
chvid
It is weird - and the recommendation of using angular for model/controller and
react for the view is more peculiar - how would that work?

~~~
49531
I mean, I'm sure it's possible... but definitely not recommended.

------
Kequc
Every time I've noticed I'm on a page using Angular or React the experience
feels terrible. Like there are 100 different unnecessary things going on in
the background. Though to be fair these are only the times I've noticed I'm on
a page using one.

Every time I've tried to pick up and learn Angular or React or etc, I've
gotten the impression that it is wildly over engineered and ultimately just
bloat. Like if I tried to do something with it, there would be 100 different
unnecessary things going on in the background.

I've been happily and successfully building javascript heavy apps for the
client side which work very well and are quite functional without the need for
a giant framework. I never feel this way about the server, on the server
frameworks seem elegant.

Why is it as soon as I move client side I'm overcome with the feeling it is
over engineered? My theory is that none of these things are even necessary
there.

~~~
qud
Wow I never thought I'll see someone else with my same concern. I really hate
using too much third-party code (to the point that I need a generator just to
start), and I like knowing what each and every file in my project is for/does.

I would really appreciate it if you'd share the application structure you use
when building a client side MVC with vanilla JS/Jquery.

I know there wouldn't be a single structure to rule them all, but I think if
developers start sharing structures that work regardless of frameworks used,
it would be much better than sharing frameworks that are very complex and get
replaced every year.

~~~
Kequc
I create a separate file for each concern, and I dump them into the same
directory together. If the files list become significantly long I separate
them into subfolders of more general concerns. For example a folder for
everything to do with "recording" functionality.

Views are very simple. There is generally a class instance which is using a
DOM element somewhere. So I store a reference to that element on the instance.
Then I have a simple object containing references to all of the important
elements within it. I have a function which generates the element if it hasn't
been created yet and adds it to the page. Now I can change whatever I want to
about the element or any important elements within it. I use classes like "is-
hidden."

Sometimes I'll decouple the UI from it's functionality. In which case I
usually implement a simple eventer system on the underlying code which the UI
connects to for status updates.

Bingo bango. I haven't run into a circumstance yet where any one file was
longer than maybe 200-300 lines total. It's simple to read, it does anything I
want.

I have never needed to construct anything client side that warranted laying it
out like a server implementation. But maybe that's my issue, I'm thinking too
small and other people have a better idea of what the future of the web looks
like than me.

I still prefer having control.

------
happyslobro
The article seems to be biased in favour of Angular.

The option of using any flavour of JS or compiles-to-JS is presented as a
negative for React, compared to Angular's decision to go all in on Typescript.
I would say that being able to stick with standard JS, for varying values of
"standard", is a good thing for library developers and very large corporate
teams. Having options like Elm or Clojurescript are good for small teams or
individuals who are looking for some advantage over their larger competitors,
such as a higher chance of building a correct system on the first try, or
being able to build faster than me to a smaller, more expressive codebase. It
was this line of reasoning that led me away from JQuery back when everyone
seemed to think JS = JQ. When I made the jump to Clojure/script, I scored an
auto generated Swagger interface for the back end, which saved a ton of effort
on documentation and Q&A, and the test suite has stayed very simple and small
- I ended up not needing anything like Sinon's mocks and spies.

The infographic suggests that because Angular tries to take on larger role in
an MVC framework, the complexity that resulted from that decision makes it
better suited for advanced developers. React, with it's tight focus on the
View, is better suited for amateurs, who will then have to make a bunch of
architectural decisions (Redux, Immutable, React Router?). I would say that
the opposite is true; an all-in-one framework is best suited for younger
developers who have the humility to know that they do not want to make these
types of decisions themselves. If you are going to build a large application,
then the ability to integrate a selection of third party solutions for various
architectural concerns can save you a huge amount of risk, in the greater
scheme of things, but evaluating those options and designing solutions for the
issues that come with multi-way integrations is a task for experienced
developers (although there is plenty of low hanging fruit in banging out UI
components and wiring up CRUD APIs for junior devs).

------
nzonbi
I have used react and angular2. Plus some other frameworks like polymer and
vuejs. And have studied a few others. The one that makes me more productive is
riotjs. Simple, minimalist design, yet it has the best implementation of
components of them all. Components are custom tags written in html, with
scoped javascript and css styles, in a single file. This is easier than React
because your html is actual html, not trapped inside of render jsx functions.
It is easier than angular, because it is simpler, faster to write and read.

It has one way data binding, like React, that is simpler to reason than 2-way
in Angular. Riotjs is the framework that I recommend.

~~~
kabes
In angular 2 Components are also custom tags written in html, with scoped
javascript and css (you can choose the scoping) in a single file (also
optional). So how is it different?

~~~
nzonbi
The base structure may be somewhat similar. However Angular 2 makes things
more complicated with more stuff: dependency injection, class decorators,
services, etc. Riotjs takes a simpler approach, inspired by React, but
improved with better design. In Angular 2 inline html templates that are not
syntax-highlighted by code editors. Full html templates require spliting the
component in separated files.

In Angular 2 there are multiple data bindings syntaxs: There is one way up,
one way down, or 2 ways. In Riotjs, there is only one, and you can use it with
the Flux architecture or similar for a simpler, easier to reason about, and
proven architecture. In my opinion Angular 2 is over enginered, with a lot of
stuff that you can easily do without it. See React. And by not having over
enginered stuff, you benefit of a simpler architecture that is easier to
learn, and simpler to use. I have found that simplicity makes many people more
productive. And React and Riotjs both are simpler than angular 2.

------
maxencecornet
[http://imgur.com/4ppfbjK](http://imgur.com/4ppfbjK)

The social share widget makes the text very annoying to read ! It's ON the
text

------
maz-dev
> Experienced developers and coders should use AngularJS. Casual developers
> and designers should use React.

Well.. I wish I could approach every tech choices with this simple mindset.

------
drinchev
I've never used AngularJS, so I would stick my comment to ReactJS.

I would like to point that with ReactJS you have a suggested way of
implementing the data-part of your application by using Flux-like architecture
( Redux, Fluxible, AltJS, etc. ). This combined with the views itself also
brings more complexity to the application.

Still I believe that 5-6 years ago ( when Backbone was the way to go, most
cases ), the current state of front-end is far more complicated ( in terms of
build tools, css / html defined in JS files, hot-reloading, isomorphic code
libraries, etc. ).

I'm still missing a front-end workflow, supported by a big company, which
reduces the complexity and increases stability.

------
gant
>should be used together

That's a wonderful idea /s

------
nmbr213
That picture at the start is really outdated.

------
DoubleGlazing
Angular and React are two different things. How could anyone make a meaningful
comparison between them?

~~~
meira
Cars and motorbikes are two different things but they can be compared as means
to get from one place to another. It isn't very hard to use the same analogy
with angular x React concerning the development of web interfaces.

------
framp
Didn't now Top Gear started reviewing JS frameworks.

------
clishem
Hardly a comparison.

------
ahacker15
None, VueJS

