
React is mostly hype - TruthyOne
http://en.arguman.org/react-is-mostly-hype
======
methyl
The arguments are pretty vague, for example

> React becomes counterproductive when developing apps that aren't mere demos.

I have developed big apps in Backbone, moving very the same apps to React and
the productivity went up madly. Facebook does develop apps which certainly
cannot be considered "mere demos" and you can see them in action, for example
Ad Manager for Facebook on iOS (written in React Native). Facebook invests a
lot in React development and there is a reason for that - they use it
internally intensively.

> It's marketed to developers by billion dollar Facebook, a company
> historically intent on squashing startups.

This is not an argument at all. I would be really surprised that's the reason
for React to exist. Also React is more a way of thinking, the library itself
can be replaced if Facebook should enforce it on a successful startup.

> The utility gained by using React's ecosystem is significantly outweighed by
> its overhead.

This is certainly not my experience. React has very little overhead and from
my experience it's pretty easy to grasp the concept for new developers.

I have no idea where does hate for React come from, it's >> just << an open
source library and I wonder how people are willing to start flamewars about a
few lines of code. If you don't like React, don't use it. There are a few
alternatives like Ember, Angular or even Backbone (although I would say
Backbone deserves much more hate than React).

~~~
cageface
React itself is pretty simple and very nice to work with. The whole
react/redux/react-redux/react-router/react-router-redux/webpack/babel/flow
agglomeration on the other hand is a lot more complex and subject to a lot of
api churn. But you can actually get pretty far just using React by itself.
Don't adopt other parts of this stack until you actually really _need_ them
and you can go pretty far with just a few concepts.

And yes, React is as much a technique for building UI as it is a particular
implementation. Learning and using React has also improved the iOS code I
write.

~~~
chatmasta
Why not take your comment a step further? That is, you can get pretty far
using plain js `createElement` and similar functions. In fact I've created a
fairly complex SPA without using _any_ external libraries. Don't use react
until you absolutely need it!

Back in the day, jQuery was amazing because it made selecting and manipulating
DOM elements easy. But now, plain JS has mostly caught up to that
functionality, to the point that it rarely makes sense to use jQuery over
plain JS. I wonder if in a few years the same will be true of much of the
functionality in react.

~~~
pests
This was one of the _problems_ React solves.

Before with libraries like jQuery every potential action had to perform it's
own UI modifications.

As the projects grows you have the same UI element being controlled from many
different sections of code. States and state transitions not clearly defined.

With React you set the state and the UI will always match, no matter how the
current state was achieved.

The purpose was to get rid of ad-hoc DOM manipulations.

The Flux architecture just takes this a bit further by formally defining who
holds onto the state/how it's accessed (stores) and the availible possible
state changes (actions).

~~~
davelnewton
Willy-nilly DOM and state modification wasn't a _requirement_ with jQuery, it
was just how a lot of people chose to (not) structure their applications.

~~~
pests
It wasn't a requirement but it was encouraged.

jQuery was all about selecting a node or node list and then applying
manipulations to it.

~~~
davelnewton
To "encourage" means to openly advocate.

Never ever have I seen active _encouragement_ of poor programming discipline.
You are correct in that's what jQuery was about, but it had no opinion on how
to go _about_ that task.

~~~
pests
It might not have a explicit opinion stated anywhere but in any library or
framework, the API provided influences how those APIs are used.

By having the central unit of work start with a query selector is one such
influence which I feel implicitly encouraged DOM manipulations.

Taking a look at the original jQuery website on web.archive, this is the
introduction to the $() function:

"The functionality of jQuery centers around one central function: $().
Everything in jQuery is based upon this, or uses this in some way. The most
basic use of this function is to pass in an expression (usually consisting of
CSS or XPath), which then finds all matching elements and remembers them for
later use. For example:"

And then goes to show a DOM selection followed by a chained mutation.

~~~
davelnewton
> [...] I feel implicitly encouraged DOM manipulations.

That's jQuery's primary job. It isn't DOM manipulation that causes
code/architectural issues.

"All" (I'm simplifying) jQuery does is provide mechanisms to select and
manipulate DOM. How to organize its usage is an exercise left to the reader,
and most readers did it poorly.

It's not jQuery's fault that people wrote shitty code with it. And, in
fairness, when Prototype/jQuery/etc. came out, sites were simpler. When people
started doing more, if they didn't take control of how they were using
jQ/etc., it blew up and made them hate their lives.

At the same time people were doing that, other people were using various
organizing principles to tame their jQ/etc. soup, writing tests, and keeping a
handle on the sprawl.

You can write shitty code in React, too. It imposes a certain set of
conventions that make it harder to want to. Layer on Redux/etc. and it's even
harder to want to. Layer on other various conventions and frameworks and you
want to even _less_. But it doesn't stop you--just like jQ didn't stop you
from using self-discipline before people smarter than me evolved client-side
frameworks to where we are now.

While I wrote my share of jQ soup, I also worked on projects that were
flexible, extensible, testable, and clean. The choice is always ours to make.

~~~
pests
Take an average developer (or two) and sit them down in front of React and
jQuery for the first time. My bet is anything based on React will be better
built than that of jQuery.

Of course you can architect those flexible, extensible, testable and clean
projects. But straight out of the box you do not get that with jQuery. It
requires planning and architecture engineering.

Whereas every React project starts off with those principals.

In other words, the ways people can use jQuery wrong is worse than the ways
people can use React wrong.

~~~
davelnewton
I both agree and disagree. If you code yourself into a corner with React it
can be harder to understand and untangle: it's much easier to understand
jQuery under the covers than React, especially if you're using other parts of
the React ecosystem.

None of this is related to what I said originally, which is that jQuery
doesn't _encourage_ shitty code. jQ's original purpose wasn't to organize
developer activity, it was to simplify one tiny portion of it.

> [Good code in jQ] requires planning and architecture engineering.

Precisely what I said.

(That said, if you don't do that with React, you'll _still_ end up with a
mess.)

~~~
pests
I agree and disagree as well.

My point about planning and architecture was to contrast it against what I
believe React is better at.

Personally I think React is easier to understand. Honestly the vDom is an
implementation detail people get stuck on. Pure functions, well defined state
owneeship and transition, and so on are the real benefits.

The other main criticism is JSX which is totally optional and mixing
implementing with presentation; the "correct" which I believe to be a outdated
but still accepted belief that went out of style around Web 2.0. This
separation is not required either, you can rewrite render() to pull from any
templating engine or whatever. Or use HOF/HOC via the presentation/containener
design pattern.

I realize I went off topic but I've been wanting to compiler my thoughts on
this.

~~~
davelnewton
React _is_ better at enabling planning and architecture; that's part of its
job. That was explicitly _not_ part of jQuery's job. jQuery was a tool to be
used as part of a larger strategy. Lots of people chose to ignore that part of
their code, and paid the price.

I like JSX quite a bit as well; IMO creating an artificial separation between
presentation and behavior is not a useful way to think about web apps.

Separating _data_ from presentation and behavior is fine, and is a long-
standing GUI tradition.

~~~
pests
I think we're really in agreement about everything. The tools have intended
jobs; some people use them incorrectly or without regard to best-practices.
Both have different strengths and failure modes.

I would say JSX and the separation of presentation / behavior is orthogonal.

JSX is just a Javascript powered embedded SGML-like document.

The combining of presentation and behavior is caused by render() being defined
inline with implementation.

You can not use JSX by using ReactDOM directly or a templating library while
still keeping render() inlined.

Or you can move render() to another class (or subclassed, or HOC, whatever)
and separate the presentation and behavior with or without JSX.

------
hoodoof
I really don't give a shit what anyone says, for me personally ReactJS makes
front end great fun to program and an absolute blast and empowers me like
never before to build powerful, interactive front end apps with a code base
that is well structured, understandable and makes sense.

Until React I dreaded front end development, painful, weird, quirky, hard to
organise and generally problemtic. With React I feel like a front end guru.

AngularJS felt like some sort of weird computer science project developed by
Phd's who had spent their university days studying Java - it hurt to learn it.

Call me a hipster fanboy if you want but I choose technology to work with
because it is easy and make sense. I don't have much time so I have to commit
my limited resource to the optimum set of technologies. At the front end that
is React.

~~~
qwertyuiop924
Angular was a bad idea. In sooo many ways...

-Two-way binding in all cases is slow

-Directives are unecessarily hard to write

-Angular's default DI model breaks on alpha conversion, the basis of every JS minifier ever. All the fixes are cumbersome.

-The system is poorly documented, making it hard for a dev to get started.

-The system is overly complex, slow, and hard to debug ($digest already in progress, anyone?).

-But most importantly, it implements stuff that has _no buisiness_ being in an SPA web framework. It re-implements scoping, modules, part of JQuery, DI, and a programming language, complete with parser.

React, however, did the responsible thing, and stuck to a specific domain.
Even if nothing else React did was good (and I have some arguments there),
this is a major win over Angular.

~~~
saskurambo
Two way data bind is fast because a graph of binds and dependency is created.
So you can have atomic updates while in virtual dom you must rerun all the
tree. See vue.js and ractive But is also true that 2way double binding take
more memory that virtual dom.

~~~
qwertyuiop924
Two-way binding CAN be fast, however, due to various issues, Angular's only
option was Dirty Checking, which is sloooow.

And no, a depgraph doesn't make it fast. What can make it fast is firing less
events, using better triggers, and basically handling it exactly the way that
Angular didn't.

VDOM can help, but really not much. However you want to put it, two-way
binding is costly, and it should be avoided whenever possible, or minimized by
catching multiple bind events at a higher up element on the tree (see
[http://lhorie.github.io/mithril-blog/asymmetrical-data-
bindi...](http://lhorie.github.io/mithril-blog/asymmetrical-data-
bindings.html))

Just spraying it everywhere, the way Angular encourages, with no optimization
(like the aforementioned asymetrical bindings), should be considered an
antipattern.

~~~
saskurambo
Data binding is also about computates function where you know the dependencies
of this and know when recalculate it

~~~
qwertyuiop924
Are you talking about Computed Values? Because Data Binding has nothing to do
with that. Not really.

In any case, Computed values make 2 way binding more expensive, because you
have to run a depgraph on all the vars that are part of the binding network,
every time an event fires. This is O(n). This is only one reason why Computed
Values, as implemented in JS, are a Bad Idea. If you have to update a var on
event fire, okay, but leaving the things everywhere is slow and ungainly. If
you instead change the var to a function call, you can optimize far better,
because you only have to update when the value is read.

In conclusion, if you want to polymorphism between functions and variables,
treat everything as a function, not as a variable.

At least, I think that's a response to your question. Your English is pretty
broken, so it's hard to tell. Sorry.

------
rootlocus
What is this nonsense?

> It's marketed to developers by billion dollar Facebook, a company
> historically intent on squashing startups.

This is a poisoning the well fallacy.

> The benefits of using a virtual DOM over the actual DOM are theoretical at
> best. The problems that React supposedly solves are theoretical at best.

This "argument" contains zero information.

> That's why there's Redux!

Redux and react don't solve the same problem.

> It solves problems you'll never encounter because you don't have Facebook
> scale.

The client doesn't scale like the backend. Not to mention it's in
contradiction with this other "argument":

> React becomes counterproductive when developing apps that aren't mere demos.

Do people actually take this serious?

~~~
mercurial
This being the Internet, I'm tempted to say it's a parody.

------
statictype
I see some point-missing arguments being made here.

React isn't for scale. And it isn't to side step learning about html and css.
It's main reason for existence is to make complex UIs easy to manage.

Pretty much the only argument I can think of against React is that it's a
boil-the-ocean system.

Once you start doing your UI with it, you pretty much need to make the entire
thing use react to really benefit from its model. Having different interlinked
components mixed between react and query and what-not is asking for trouble.

But. Building your UI as a description of your current state is so incredibly
useful to reason about and prevent bugs, that it's usually worth it to go
completely into the system.

The only other major gripe I have is getting time-based elements like
animations to play well within the system.

~~~
jukkakoskinen
"Once you start doing your UI with it, you pretty much need to make the entire
thing use react to really benefit from its model."

In my experience React is quite ideal for cases where some parts of a site or
an app need dynamic behavior. I'm currently working on an e-commerce
platform's admin panel, and for us a complete rewrite would have been nearly
impossible. With React we can keep the old HTML + jQuery codebase, and
implement/refactor stuff as small or as big as we need (e.g. a live-search
component or a whole new dashboard view). We're doing something very similar
to this: [https://github.com/reactjs/react-rails#rendering--
mounting](https://github.com/reactjs/react-rails#rendering--mounting)

~~~
mercurial
That's the same thing we're doing at my company (with the aim of eventually
replacing the old platform entirely), and it's working out very well.

------
onewaystreet
> React automatically manages UI updates, but this is only true if your UI is
> extremely basic.

The exact opposite is true. The whole point of React is in building complex
UIs.

> React becomes counterproductive when developing apps that aren't mere demos.

A few sites using React that are not mere demos:

[https://facebook.com](https://facebook.com)

[https://instagram.com](https://instagram.com)

[https://netflix.com](https://netflix.com)

[https://airbnb.com](https://airbnb.com)

[https://discordapp.com](https://discordapp.com)

> It's marketed to developers by billion dollar Facebook, a company
> historically intent on squashing startups.

Except when they are buying them for billions (WhatsApp, Instagram, Oculus).
All things being equal, Facebook is probably more likely to buy your startup
if you use React.

------
mack73
I don't believe React to be mostly hype. It's so frequently being used by
skilled and informed teams that I would consider anyone who make this claim to
be ill-informed.

But the claim and current consensus around web development is that "you should
absolutely use a framework built by someone smarter than you or you'll end up
shooting yourself in the foot" I find equally ill-informed.

Consider these popular libs and then consider how poorly they integrate with
each other: jquery, bootstrap, require and knockout. If you are off by a
version or two in jquery, then bootstrap will not work. Up the version of
jquery and parts of your app will break down. Try to fit libs that aren't
modularized or that use hard-coded deps with require. You'll end up rewriting
those libs (to get rid of deps you don't need).

I feel javascript should be mature enough to use without frameworks. Remember
the cutting-and-pasting of the javascript.com era? We're back to that, I feel.
I mean, surely there are lots of smart snippets of code or even libs that you
want to use in react but can't because the code-snippets or libs aren't
following the react architecture. What do you do then? Cut-and-paste those
parts that you need and that will fit into react, perhaps?

------
scotty79
Ignore the react bit, the site is interesting in itself.

[http://en.arguman.org/](http://en.arguman.org/)

The post is bait-and-switch, react is a bite, time for a switch. :-)

~~~
rootlocus
No thank you. None of the other "discussions" are worth wasting time over.
Just people bringing feelings, sophisms and misinformation to an argument
fight. It's no better than a reddit thread.

~~~
Noseshine
You got heavily downvoted, but the linked argument-story is an example for
this. Less emotions would be nice.

Some day we may have a forum (in the broadest sense) that uses a sensor, like
a webcam, and "emotion recognition" AI. You are not allowed to vote if you are
too worked up about a comment, and if you post it will be held for a few hours
and you have to acknowledge that you still mean it after that "timeout" period
before it gets published. This should/could take care of some hot-headed
responses. I think digital discussion needs more ideas, just "post your
comment here" and "votes" don't really cut it. It's better than nothing (pre-
Internet), but we've seen the disadvantages by now, why not try something new?

Internet discussion and collaboration software could be (should be?) _the_
most exciting thing, instead everybody just copied and barely modifies the
core concept in use since the very first web forum software was first
published.

------
auganov
React is a pretty simple concept (with, perhaps, a complex implementation)
reified in a library. It's basically componentized state machines for UI
rendering. Comparing it to general "web frameworks" is completely missing the
point. Granted, some people do [often needlessly] install a lot of react-
whatevers for everything from routing to mysql fetching (yep).

I can see it being replaced by another library with a similar underlying
philosophy that just does it better, but I don't really see how the general
idea would vanish soon.

And btw Facebook uses it a lot on the web too (not just the often mentioned Ad
Manager), messaging (and messenger.com) is basically all React and other
components are a mix. Download the React Devtool to check it out, they don't
obfuscate the React tree at all. Pretty fun to browse.

------
kaio
Whoa. I have been working on larger web apps at pre- react\ angular\vdom time
and i'm really glad i don't have to read tons of tutorials about what might
cause my Browser to repaint or even reflow the entire doc to get some Good
enough performance. And react really shines for bigger projects since you only
care of locale components.

------
yawgmoth
I'm still undecided as to whether React is up to snuff for large-scale
development projects. I work in a medium sized company developing enterprise-
targeted web software. We have been using ASP.NET + jQuery + whatever JS
design pattern to artificially namespace our JS for about five years. This
summer we moved to React + Redux for a new product and it has been pretty
amazing. Productivity did not go up (immediately), in fact, learning the React
way and constant adjustments to what we were storing in Redux slowed us down
considerably. However, we are across that hump and it FEELS like we have some
really good, reusable components that will save us lots of time going forward.
At this point, extension and composition should be really trivial and the next
few months will really form my opinion on React as a tool (and of course,
myself as a user of that tool ;) ).

However, the ecosystem, not just React but the npm ecosystem in general, has
been a bit disappointing. Things move very quickly in some places but not
others. React itself has broken or generated warnings numerous third party
packages that, hopefully, will catch up. It's disappointing because it
basically forces us to not update our main dependencies until everything has
moved with it. Perhaps that's my fault for placing the npm/js world on a
pedestal, but then again, I think I've only done that because, while .NET is
generally favorable today, the inertia of past criticisms had led me to
believe that the .NET ecosystem was somehow inherently deficient or broken
when compared to the JS ecosystem. At this point, they seem fairly similar in
terms of quality and choice.

One big plus with moving to any npm-centric development is that, coupled to a
move to Windows 10 and using bash, a lot of the dev workflow has moved out of,
say, Visual Studio and into a command line. This is great because as we move
build and deployment configurations between machines and tools (say to
Jenkins), there aren't lots of details hidden in our project and solution
files. It offers a clarity I didn't know I wanted.

------
TheAceOfHearts
I find all the recent negativity around React-related posts to be very
frustrating.

I'm a frontend engineer, and I greatly enjoy working with React. But I think
that's because I've invested the time needed to learn and navigate the
ecosystem.

It's true that React doesn't solve all the problems you deal with when
building a web app. But I don't think it has ever marketed itself as a
"batteries included" solution. It gives you a strong ecosystem and a great
abstraction for building UI's.

------
JasonSage
Quite a few claims with absolutely nothing to back them up.

TruthyOne, if you really believe all this and are submitting it to Hacker
News, surely you wouldn't mind sharing how you've come to these conclusions?

------
Brajeshwar
Our team of seasoned AngularJS developers recently tried out React for its
small enough footprint and the huge community support. We loved it, our client
loved it. I don't really see such bad things about React at this time.

Shameless plug, but we did wrote an article outlining our experiences at
[https://blog.alarisprime.com/e-commerce-case-study-
building-...](https://blog.alarisprime.com/e-commerce-case-study-building-
faster-listing-pages-on-abof-com-part-1-cb99231a1e8a#.ee37xw6ru)

------
rcarmo
I would think [http://en.arguman.org/web-programming-is-getting-
unnecessari...](http://en.arguman.org/web-programming-is-getting-
unnecessarily-complicated) is much more interesting, really.

React is _just one framework_. Popular, sure, and occasionally annoying (for
very small things, the overhead of building a gigantic workspace vs just using
Zepto and ending up with three JS files is... well... pointless), but we
should be looking at the broader picture.

------
kayoone
I did one medium sized SPA in react (using alt.js) last year and wasn't really
convinced, maybe i did something wrong but i did not feel the amazing
productivity boost that so many people mention. Managing a lot of dependencies
of the modules i used for various things like forms, file uploads etc has been
painful and in general the module quality felt very alpha in many cases so i
ended up reinventing what has already done pretty well in angular in terms of
functionality. Code organization and best practices also wasn't easy to come
by because of the many ways of doing things and in the end some solutions felt
more like hacks than a solid implementation. Angular1 is certainly not perfect
but i found the whole thing to be much more consistent and Angular2 using
Typescript is what i prefer most right now.

------
mrweasel
I don't really see the difference between most modern JavaScript "frameworks".
It's mostly in the details, and any of them would work just fine. At this
point it's like arguing which of X number of programming languages are the
best.

Part of seems to be: "How dare people not like the tool I prefer", or simply
that people don't want to be bothered to learn yet another JavaScript library
(which I can understand, but I'm not being prevented from using the tools I
like, just because React exists).

One "mistake" I see React make, others do too, is mixing JavaScript and HTML.
I'm still firmly in the camp that believes in progressive enhancement as the
correct way of developing for the web. React, Angular and most other modern
libraries doesn't seem to share that view.

~~~
mack73
First time I read a blog post about react and saw it's artifacts so to speak I
threw up in my mouth. Js AND HTML, mixed! Wtf? I spoke about this to lots of
front-enders who laughed and called me old. I agree with your point. If markup
and UI code can be separated, why wouldn't you strive for such a solution?

~~~
meira
Because HTML is not a programming language thus you have very limited options
to work with.

------
Philipp__
I am not fan of React. It is great to have something like React for people
that aren't primarily into software development, because of html and css and
js (many designers and hobbyists got into programming with those) but I do not
appreciate it. The fact that I do not have (nor want) any single Electron app
installed on my computer tells something. It is okay to be there as a choice
for app development but I want to see less of it. It doesn't come close to
native apps. And Qt is getting really better and better each day, and right
now is pretty portable, so you don't have to write 3 different versions of
apps for different operating systems. Just not my cup of tea, and I hate that
it is hyped, because it is reflecting bad on some developing habits and
community.

~~~
DasIch
So, you don't like React because Electron which has nothing to do with React?

~~~
creshal
And apparently Qt is so much better, which is in the process of integrating a
full browser engine for Qt Quick, which is… somehow better than using a full
browser engine directly? Okay.

------
jgalt212
Neither React or Angular are mostly hype. I posit that SPA's, whose
implementation is made less painful by React, are mostly hype.

I liken it the Lisp macro analogy. Never write an SPA unless absolutely
necessary--stick with a web page with some dynamic js-driven features as
needed.

~~~
TimJYoung
SPAs can be a good thing when used internally in a business (ease of
distribution, sandboxing, etc.), but I agree that any public-facing web _site_
is probably best served by static HTML with minimal JS where it is absolutely
necessary.

------
aidos
Erm. What is this? I'm probably missing something but there's no useful
content here at all.

~~~
devuo
[http://en.arguman.org/about](http://en.arguman.org/about)

~~~
realharo
Pretty annoying that you can't select text to copy/paste and quote it.

~~~
chippy
I'm sure they would appreciate an issue
[https://github.com/arguman/arguman.org/issues](https://github.com/arguman/arguman.org/issues)

------
praetorian84
I've been using React for a side project for a while. Generally it's been
pretty easy to understand the concepts behind it and get productive. A couple
of things that have confused/irked me a little:

\- Having to figure out babel, browserify and/or webpack before you can write
hello world isn't a great first experience. I'm glad to see much of this has
been moved to a separate page outside of the getting started guide now.

\- The main React page emphasises that JSX is optional. Even looking at the
trivial examples, nesting createElement statements looks horrific. Does anyone
use this approach in a large-scale project? If your components are fine-
grained enough, perhaps it's passable, but it looks far from ideal. Having
used other frameworks, even building up a template in JSX in a return
statement feels dirty. I see there are some suggestions around on splitting
out JSX, but it would be great if this was the default.

\- I wasn't really sure what to do with CSS. There's a brief comment on
inline-styles at [https://facebook.github.io/react/tips/inline-
styles.html](https://facebook.github.io/react/tips/inline-styles.html). For a
library for building user interfaces, it seems like this deserves more
attention. I would've expected the CSS (styling), javascript (logic and state
management) and JSX (layout) to be a little less interwoven.

~~~
Klathmon
IMO the whole CSS issue isn't "solved" yet.

There are like 3 or 4 different ways of doing it, each with their own pretty
big drawbacks.

Personally we ended up using CSS Modules with SASS in our "main" react
project, but it feels clunky.

The biggest issue we have is determining which element "owns" the styling.
Should a widget style itself, or should it let it's container style it, or
should it provide some simple defaults and let the container overwrite them
(which gets ugly because with CSS Modules overwriting means using !important
or doubling classes (like `.button.button` to overwrite `.button`).

All that being said, it's actually working out really well for us despite
feeling wrong. And it might not ever become an issue because our largest
stylesheet is like 100 lines long since everything is so compartmentalized.

------
anupshinde
I've used React in four projects (after many projects in Angular[1])

1\. In terms of best practices, React for serious development is a disaster
just by itself. Read on.. This is what happened in my first project (when I
didn't use Redux). By itself it is only good(and great) for POCs. And React-
ecosystem is complex to start with. React-Redux, Router, Axios, Webpack make
React complete for use in any serious project.

2\. React makes web-componenting pretty easy. However it is counter-intuitive
when you start thinking about the all important Smart Vs Dumb components
separation. I don't know about others, but I like to see components as
behaviour-complete stuff and not just view-complete. React with its ecosystem
does things in a view-complete way. Yes, it does result in much much lesser
bugs.

3\. React is hyped because of its simple examples. As I said earlier, it makes
it easier to create behaviour-complete web components. But then the ecosystem
says "NO. NO.. Think in REACT way". That is not wrong but its complex. The
first project in React was a disaster because of the complex state management
I did without using redux or flux.

4\. After working with React - when I tried Angular2, I moved back to React
again. And I did React+TypeScript which makes coding even easier. The only
thing I still like in Angular2 is now-not-default two-way data binding.

Do I love React? May be not so much - but its the best I have seen. But I love
the way my apps remain bug free without a lot of front-end testing code. And
once you add TypeScript, development is just a bit more easier and bugs get
thrown up at compile/transpile time

------
nkohari
This is the same stuff people have been saying about React since its
inception. Putting opinions into Arguman doesn't make them factual statements.

~~~
mbrock
No kidding. These aren't arguments, they're claims. Making an argument
involves using reasoning to support claims... you can't just draw boxes around
five claims and say it's an argument.

------
zzzaim
If the point of this post is the site arguman.org, not react, then one small
issue (I'm on chrome mobile):

\- No quick submit + signup/in button

Which is why I guess people rather argue here than on the site (says something
if the whole point of the site is to make arguing easier)

~~~
nness
I think this submission is more to promote the Arguman service than anything
else. Because most of the submissions come from just two people, who both
joined the service less than 24 hours ago.

------
zaidf
If true, then what is a competing JS DOM renderer with same or nearly same DOM
rendering speed?

Closest I've found is Vue but it was still 20-30% slower than React, according
to the DOM speed test on a benchmarking site.

~~~
dodyg
[https://github.com/ractivejs/ractive](https://github.com/ractivejs/ractive)

edit: developed and backed by the awesome guys at The Guardian newspaper.

------
saskurambo
React is good for complex app desktop but not if you need performant and fast
interface with 60 fps otherall in mobile. Last virtual dom like snabbdom
preact and inferno are really fast also on mobile. And inferno and preact are
compatible with react component. Vue.js 2.0 use an intelligent mixin of
reactive data graph dependency and virtual dom separating the static and
dynamics parts of template. Monkberry.js translate a template in pure
javascript function with createElements and update nodes. Function that can be
optimized from the jit

~~~
qwertyuiop924
Mithril is also apparently really good at fast. But I've merely seen the
benches.

~~~
saskurambo
Mithril for what i know is under a rewrite and with this rewrite should be
really fast

~~~
qwertyuiop924
I never heard that, but it seems pretty fast now. If Leo shows up, hopefully
he'll tell us.

~~~
saskurambo
I know about this
[https://github.com/lhorie/mithril.js/issues/1090](https://github.com/lhorie/mithril.js/issues/1090)

~~~
qwertyuiop924
That's only addressing perf on IE. It says nothing about perf overall.

~~~
saskurambo
Dom / component recycle and batch updates are about performance

~~~
qwertyuiop924
Well, okay. Then my favorite framework's getting speed optimizations. I'm not
complaining.

------
qwertyuiop924
I don't know about the React model and APIs themselves, but VDOM is the Right
Thing, from a performance perspective, as well as from the ease perspective.
And the advantages are far from academic.

------
harperlee
Offtopic, but HN usually talks about the value of ideas vs. their execution...
well I have had this website's idea, literally, in my notepad for a couple of
years as a possible side project, never getting down to implementing. And here
it is! Also clicking on the domain I see that it has been sent here
periodically during the last year...

I better get to work on my actual project so I'm not overtaken :/

------
jcoffland
Other technologies have gotten a lot more attention due to the support of big
name companies but vue.js is easily my favorite Web framework.

------
DHMO
Was not aware of this until reading:

"Your license to use React.js can be revoked if you compete with Facebook"

[http://react-etc.net/entry/your-license-to-use-react-js-
can-...](http://react-etc.net/entry/your-license-to-use-react-js-can-be-
revoked-if-you-compete-with-facebook)

This is the scariest part to me:

"The library is open sourced under BSD, but it comes with an added patent
clause that you should be aware of."

[https://github.com/facebook/react/blob/master/PATENTS](https://github.com/facebook/react/blob/master/PATENTS)

From reading more, it appears that Facebook can just terminate your right to
use their patents, but not React. However, it isn't clear to me what is
patented and what rights you lose.

Related past discussions here:

[https://news.ycombinator.com/item?id=9271331](https://news.ycombinator.com/item?id=9271331)

[https://news.ycombinator.com/item?id=11270213](https://news.ycombinator.com/item?id=11270213)

On the bright side, it's said that Apple and Google are ok with the latest
version:

[https://github.com/facebook/react/pull/3554#issuecomment-235...](https://github.com/facebook/react/pull/3554#issuecomment-235569515)

~~~
rtpg
It's not if you compete with Facebook, it's if you engage in patent litigation
with Facebook.

This is a Mutually Assured Destruction clause for patent fights, nothing more.

~~~
DHMO
I was quoting. Did you read everything that I wrote? I thought I did a pretty
good job telling the entire story.

~~~
rtpg
Right, if you look at the contents of the license in the discussion, they are
variants of "if you try to fight us with patents, we will deny you a
license/patents".

So you can compete with FB without losing a license. The first blog post you
quoted shows a misunderstanding of the license (the word "compete" doesn't
show up in the license).

So the correct representation is "If you claim patent infringement by FB, you
can lose the license.". This is what the linked comments say, but what your
summarised statement didn't properly capture (hence my comment).

~~~
meira
Or if Facebook claim patent infringement against you. So what he summarised is
right.

