
Stop using React for everything - zackargyle
https://medium.com/p/c8297ac1a644
======
jypepin
"I love how cleanly it integrates with ES6 and its component style
architecture that the future of the web lies upon. That said, I rarely choose
it for projects."

I can't find one reason why ES6 and component-like architecture wouldn't be
chosen "often" for projects? React is the first javascript (frontend)
framework I use that allows to easily break down architecture and keep a
complex (or simple) application clean and well structured. It feels like
writing server-side code.

"For static sites, Jade is a fantastic templating engine." Cool. But why
compare how to use a javascript, dynamic framework for static sites? That's
just a bad argument.

"For data-bound REST apps, I choose Angular. " Good for you but... why Angular
over React? Those are 2 frameworks that are supposed to do the same thing
(build dynamic front end applications) with 2 different sets of mind. But... I
build REST apps with React. I even build Forms with React. And they are not
even dynamic. What's wrong with it? It makes my code, form validation, form
submit way cleaner, easier and reusable! What should I do instead? Use vanilla
js? jQuery? Why? Because it's enough? It's enough, but trust me, I've recently
(no later than last week!) refactored some of our forms with React, and it-is-
so-much better.

I totally agree with the author's point of "do not use X for the hype and
everything, but use X for the good reasons" but the argument given is plain
bad and examples are wrong.

~~~
0xCMP
Well there are people doing some of these things in React and fighting React
just so they "did it in react." For instance there is some blog out there
which is "the more complicated blog ever" and it's an isomorphic react
application. Then there are the people who use React and the
'renderToStaticString'(or something) to make static sites using React.

~~~
straws
I'm not sure I'd agree that those are examples of people fighting React though
— using it on the client and server allows you to never duplicate markup you
might have in a component with markup in a template, for example. The case for
writing your entire UI in React is pretty strong actually, as it's just a
matter of where you create the data to pass down to your tree of components:
once, on the server for a complete page load, or incrementally and dynamically
on the client.

There are some cases though where the component model feels strained —
consider components that act as a pass-through for debouncing data, components
that implement routing as a tree of routes and handlers, or components that
perform data-fetching. Perhaps it's that the community hasn't found the right
APIs for these higher-order components, but it's hard to argue against using
React for a stateless tree of UI components.

------
msvan
How about learning one thing well, so that you can use it for a wide range of
projects? Choosing React and using it for everything sounds like a great idea
to me, since you can transfer your knowledge from larger projects to smaller
ones, and vice versa, instead of spending time learning new things.

Also, I don't mean to be snarky, but I suggest the writer uses fewer ALL CAPS,
fewer exclamation marks and tones down the provocations to be more convincing.

~~~
angersock
This hammer is a little hard to screw things in with, but _man_ I'm good with
hammers!

~~~
crimsonalucard
React is neither a hammer or a screwdriver. React is the toolbox. The problem
here is that the article writer and you think that React is some kind of
hammer.

~~~
angersock
The person I replied to said exactly that React should be used for everything.

There are certain categories of web applications and pages which do not
benefit at all from React (or other semi-related technologies like Angular),
and it's folly to pretend that they do.

If you want to go the "it's a toolbox" route...showing up to a carpentry job
with a plumbing toolbox isn't useful.

~~~
crimsonalucard
React is the garage in which your toolboxes are stored.

------
onewaystreet
> Find out why companies like Google, MSN, and Vevo use Angular.

Because they were part of its creation and are invested in it.

> Or why companies like Sony, Reddit, and Pinterest use Backbone.

Pinterest just switched to React.

> Or why companies like Netflix, Yahoo, and LinkedIn use Ember.

Netflix just switched to React.

> There are smart people out there not choosing React. Ask yourself, why not?

Not for long.

~~~
vogre
Well, does Google really use Angular for something big?

~~~
aikah
DoubleClick admin interface is built entirely with AngularJS. other products
(gdrive and co) , it's not clear, what is used. Closure library maybe.

~~~
bpicolo
Closure compiler is used for a lot of their main products from what I know
(gmail...)

------
doki_pen
For most generalists who doesn't live in the frontend, learning every
framework and applying the right one is not tenable. None of the js client-
side MVCs I've seen are easy to just pick up. Even 6 months after I haven't
used one I have trouble remembering how it works. You'll be much much more
productive on something you are familiar with, even if it's not an exact fit.

If you are a frontend javascript consultant, than by all means, learn them
all.

------
djur
I agreed with the headline but was disappointed that the upshot was "use
Angular, Ember, or Backbone instead" rather than "not all websites need to be
JavaScript-dependent single page apps".

------
api
Why?

React brings sanity to the web UI world. It brings _reusable components!_ It
brings composition. It brings modularity.

... and it's written by adults who know CS. Your UI is a pure function of your
state. Who knew?

Why would I use anything else? Really? Do I _want_ state-management spaghetti
and over-engineering?

The only way I'd give up React for dynamic sites/pages is if the web standards
groups made Web Components into something that was actually as good as React
and baked this into the stack. But somehow I doubt that's going to happen. Web
Components might turn into something good to compose UI but you'll probably
still need React to add dynamic behavior to it.

------
bengillies
> It is not the one-size-fits-all solution you are using it as. If your site
> has a dynamic form, you don’t need a freaking virtual DOM.

The main benefit of virtual DOM afaict is that it makes rendering on the
server trivial without needing to jump through all the hoops that, e.g.
Angular has to. Contrary to the post, this makes it ideal for such sites.

------
kenOfYugen
The battle of front-end frameworks is powered by companies trying to lure new
and inexperienced developers, as well as experienced employees already working
with teams of developers, into a more unified thought pattern. For that
purpose they are great. On the other hand, the underlying "magic" isn't
optimal for all use cases. The author states:

"If you have a highly dynamic application that needs to rerender frequently,
and you want to avoid the heavy weight of template diffing, [...] ReactJS’s
virtual DOM will be super effective. However, if you’re site doesn’t have
those needs, CHOOSE SOMETHING ELSE!"

Well choose a DOM representation implementation in this case. That's not what
React is all about. And may I add that, "Virtual DOM" or however you want to
call it, will never be as fast as manual DOM manipulation done right. It's
just a well documented convenience magic abstraction.

We no longer have vast incompatibilities among browsers, so we no longer use
JQuery. At the same time, threads pop up everywhere titled "how do I do [this]
in [Angular, React, etc.], just like it has happened with JQuery in the past.
And I won't even mention framework specific "plugins" ..

The underlying problem is, the majority of people involved with JavaScript for
the web platform, are afraid and/or lazy learning it. And no framework can
cure this, but at the same time frameworks help us hide the pile of ignorance
we have under the framework carpet.

I'm not bashing anyone, frameworks can inspire and help organize vast amount
of work. But at the same time they are hard dependencies, hailed by well known
developers. Sooner or later there will be new ones [that got it right this
time] and the cycle of hype-wow-sucks will continue. Well they are all built
with JS, so how about you take your time to learn the language and
philosophize a bit on programming, state management, application structure and
the capabilities (as well as the bottlenecks) of the web platform? Then you
may choose any framework you like at any time and you won't be shooting
yourself in the foot because you'll be using it as a tool, and not the panacea
for all your troubles.

------
vippy
No. I <3 React for single-page applications. Add in browserify, and you no
longer have to deal with the dependency soup that is jquery / requirejs /
backbone / angularjs, and you write software with far fewer side effects.
It's. Freaking. Great.

------
prezjordan
> If you have a highly dynamic application that needs to rerender frequently,
> and you want to avoid the heavy weight of template diffing, you’re looking
> at a grass-type opponent and ReactJS’s virtual DOM will be super effective.
> However, if you’re site doesn’t have those needs, CHOOSE SOMETHING ELSE!

What if I _really_ like the programming model behind React? My UIs are so easy
to reason about now, and that's why I like it so much.

------
therealmarv
This is actually the good thing on React: You can use it for certain parts of
your websites and you are not forced to use it for everything on your website.

------
igvadaimon
I am using React and all the trendy tooling for my personal projects, even if
it's just a simple website. Why? Because that's an opportunity for me to learn
new stuff.

I can't use React at work, but I don't want to stagnate either. That's why
I'll always be using the most ridiculous trendy technologies for side
projects.

I do think that's how most of frontend developers live nowadays.

------
fridek
The same could have been (and was) said for Angular. Weapon choice is part of
a duel.

At the same time, I worked in a couple places that used better, but less fancy
languages/frameworks. I won't name them to not attract a horde of "but
Erlang/Racket/Ember is the best thing". There was a repeating pattern of
having a hard time with both recruitment and with actual development. People
didn't know our tech, or they did but not as well as they claimed they did.
Then there was all the trouble with finding libraries, examples and general
help of any kind with less popular tech. I suppose the cost of using a wrong
but popular tool (be it React or anything else) may actually not overweight
the cost of using the right tool which in general is harder to utilize.

------
daemonk
"However, if you’re site doesn’t have those needs, CHOOSE SOMETHING ELSE!"

"your" not "you're". Sorry I had to do it.

------
BinaryIdiot
I'd have to agree; React is pretty cool in some use cases but it's not always
the best tool for the job. I mean take a look at the Atom editor; they
initially used it which helped speed up their development but after a certain
point they benchmarked it and found simply manipulating the DOM itself was far
faster. Now that doesn't mean to never use React; all that means is simply use
the right tool for the right job.

If you need something done and done fast with decent code separation, feel
free to pick up React. If you need to optimize for performance (because many
of us need to at some point) or you have a good understanding / way to
architect your code to keep up a good separation of DOM and business logic
then use almost anything else.

Hell, you don't even need to use a framework for the web. My last project I
didn't use any and it was perfectly fine. Frameworks are great to get you
going faster and doing the hard parts for you but you don't always need that.

In my opinion anyway.

------
danmaz74
Very good clickbait, very little useful content.

------
akilism
The thing is do you want to build something or do you want to learn every JS
framework and try to decide which is going to be the very best for what you
are doing then build something.

" React, Angular, Ember, Backbone, Vue, Knockout, Mithril, Jade, Django,
Rails, etc. "

Oh yeah I never built _____ cause I was busy learning a, b, c, x, y, and z
frameworks and by the time you have those down there are three new ones. When
most likely what you are doing any of the big ones will be fine so just pick
the one you want to learn, or know already or whatever works best for you.

------
vilmosi
Who exactly is using React for everything?

~~~
vippy
My team is moving in that direction. Client-side React for our admin
interface, server rendered React components for our customer-facing stuff.

------
wvenable
I'm at the point where I'm looking to pick the next web technology stack for
projects moving forward. I am leaning towards React as the main framework for
everything.

The reason for a one-size-fits-all choice is that I really don't want to have
to learn the ins and outs of 3-4 different frameworks and libraries. Even if
React doesn't exactly fit the model of a certain application, it makes sense
to shoe-horn it in to avoid a fragmented technology stack. I only have so much
space in my brain.

------
creullin
I think these points could be for 'hip' frameworks in general. As a developer,
it's tiring keeping up with the latest and greatest AT ALL TIMES. Anyone have
a good comparison of React and Angular that cuts through the hype?

~~~
mordocai
React and angular.js don't really solve the same problems (though angular 2 is
incorporating some react-like techniques). React is only the V (arguably a bit
of C) from MVC, where as angular.js provides all three but does a rather
crappy job on V IMHO. ng-react supposedly let's you use them together but I
haven't tried it yet (I plan on it).

~~~
gedy
> React is only the V (arguably a bit of C)

Yes, but beef I have with the cool kids I've worked with are they throw out
the entire app: MVC, Server, etc. so they can use this magical V - then
completely rewrite and wing the rest of the app "Oh it's, um, 'Flux
Architecture'"

~~~
mordocai
Yep. You certainly won't hear me advocate that, but I believe that people are
doing it.

------
dylanrw
I'm enjoying [http://riotjs.com/](http://riotjs.com/) right now. It fits well
in those situations where you need something light but want a bit of clarity
as well.

------
tomelders
This is the angry way of saying - think about the needs of your website/web
app before you decide what libraries and frameworks to use, and use them
sparingly.

------
crimsonalucard
That's like saying stop using HTML and javascript for everything. There are
more appropriate tools out there!

------
crimsonalucard
React is a toolbox. Toolboxes are used for most almost EVERYTHING.

------
symbiosis
React is eating the world. Reactify all the things!

------
andyl
React is the new Jquery.

~~~
aikah
> React is the new Jquery.

"You might not need React"TM , or "Occupy React"TM soon next to your dev shop
/s

------
kra34
I don't even have to read the article to know this is going to get down-voted
into obscurity. It's like mom always said if you don't have something nice to
say about this week's popular javascript framework, don't say anything at all
(or else...)

PS This week's framework is actually Falcor

~~~
sirtaj
I'm sympathetic to the basic idea, but surely this is not the article you're
hoping for. There's a lot of ranting, with only a couple of sentences of
actually useful information, eg. situations in which React is not a good fit.
He mentions Angular for "data-bound REST apps" \-- why? What makes React worse
than Angular in that situation? What would be the tipping point in that
situation that might make him use React instead? No data provided.

~~~
kra34
Yeah not exactly a well reasoned article about the strengths and weaknesses
(these really do exist) of using React or X Other Framework. I went back and
actually read it.

The CEO of the Meteor Dev group gave the following presentation recently:

[https://www.youtube.com/watch?v=8G2SMVIUNNk](https://www.youtube.com/watch?v=8G2SMVIUNNk)

He indirectly touches on some of those probably 25 minutes into the talk.

~~~
the_rosentotter
When JavaScript frameworks have CEOs, you know something has gone horribly
wrong.

