
React Makes You Sad? - danabramov
https://github.com/gaearon/react-makes-you-sad
======
marcusr
As a C and then a Ruby on Rails programmer, I never thought I would see the
day that my main programming language was Javascript. But I find React such an
enabling technology that I made the effort to learn Javascript properly, and
am glad that I did.

React itself is allowing me to write web applications faster and with less
bugs, primarily because of the unidirectional information flow, but also
because of the way it guides you into making everything components, which
keeps the borders up between objects and makes testing easy.

Even better, I can now create both iOS apps and Android apps at the same time
(I knew Objective C but not Java for Android), and at a much faster speed than
before - the flex layout model alone has saved me days and weeks of debugging
the iOS layouts in storyboards, and now I'm able to shift code between the app
codebase and the web codebase with ease.

It is indeed overwhelming when first trying to learn React, especially when
trying to learn Javascript at the same time, and this flowchart is so spot-on
with the tendency to start using packagers, boilerplate, redux before
understanding why they are useful.

Follow the flowchart, and you will find happiness!

~~~
doughj3
> Even better, I can now create both iOS apps and Android apps at the same
> time

Are you referring to native apps, or do you mean by making a Web app with
React you don't need to make native apps?

~~~
squeaky-clean
React Native [0]. Your view-specific code still has to be done per-platform,
but your core logic can be shared, and all of it is written with Javascript
using React as the framework. The JS creates and controls native elements,
with the native parts mostly abstracted away.

[0] [https://facebook.github.io/react-
native/](https://facebook.github.io/react-native/)

~~~
marcusr
Exactly this, made even simpler by the naming scheme that lets you have iOS
and Android versions of the same component.

------
vietnameselady1
Although I like this a lot, and I think it addresses most individual nuggets
of React Sadness in a pretty reasonable way, I am still sad.

I am sad because every process rectangle in this chart should also point to a
decision diamond that says:

"Does it seem that the entire industry has migrated to this stack, whether or
not it really makes sense for everyone to? That a feedback loop now influences
shops to choose these tools/technologies not because they are called for, but
simply because they are trendy? That present excitement outweighs the question
of 'whether you need this or not' in the eyes of most of your peers and
colleagues? That the incentive to not get left behind is stronger than the
incentive to stop and consider?"

And then, that diamond should point to a final rectangle that says:

"If you wish to remain employable, learn React + Redux + ES2017 + Webpack now,
or join a different sector of the industry. As for the sadness, deal with it."

This isn't only true of React, of course. The underlying sadness comes from
watching one's valid hesitations drowned out by the mob.

~~~
qudat
Did anyone claim the same about jQuery a few years ago? First people claim
about js library fatigue, now we are complaining about there only being "one
employable js library."

~~~
nostrademons
Vanilla JS was so horrible when JQuery came out that pretty much everyone
loved it, except for a few folks who had been early adopters of
Prototype/Mootools/YUI/Ext and were decrying how JQuery didn't have their
favorite pet utility function.

I think the JS fatigue we're seeing is because web development is now largely
a mature industry. React is roughly the 4th generation of Javascript
technologies (1st = DHTML/Layers, 2nd =
JQuery/Prototype/Mootools/YUI/Ext/Dojo, 3rd = Angular/Ember/Backbone, 4th =
React/Polymer). At this point, there are millions of JS developers, they have
seen multiple generations go by, and they just want some stability. The folks
who always want to be on the bleeding edge are off doing IoT and VR startups.

IMHO, React is a nice piece of software, but it's a nice piece of software
entering a market where existing solutions are already pretty good and much of
the action is moving elsewhere. They _have to_ hype it up, because people
won't give up their JQuery/Angular/VanillaJS otherwise. It's a very different
situation than when JQuery was introduced and web development was recovering
from the .com bust and years of stagnation in browser innovation.

~~~
techdragon
Web development has reached "maturity"... How funny a thought us that.

Sorry to be brutal but. Fuck no it's not. An hours studying of the JavaScript
ecosystem should be more than enough for most to see that not only is web
development not mature its mutating and beginning to try to consume other
programming disciplines like some form of cancer. Just look at how NodeJS has
been creeping its way from server to desktop to mobile.

------
ryannevius
React made me sad, so I switched to Mithril[1]. Not only is it significantly
smaller in size, but it's way faster and includes a router and AJAX methods
out of the box. I wish more people would give it a shot.

That said, I do still love React Native, and use React on a daily basis to
take advantage of the "write once, run anywhere" paradigm.

[1] [https://lhorie.github.io/mithril/](https://lhorie.github.io/mithril/)

~~~
bikamonki
Project seems abandoned, no?

~~~
lhorie
I'm working on a rewrite (for improving performance, modularity and for
general house cleaning) and the github branch doesn't reflect that right now.

~~~
brlewis
Are any breaking changes coming?

~~~
lhorie
I'm planning to keep the basic, most used APIs the same, but yes, there will
be some breaking changes. Promises will follow ES6 API and advanced redraw
control APIs will likely be changed to improve ergonomics and leverage good
ideas from other vdom libraries.

~~~
brlewis
Will there be changes to the vdom structure that might break MSX?

~~~
lhorie
I don't think so. Even if there ends up being one, I'd send a PR to insin.
Planning to keep it @pragma jsx friendly, though.

------
et1337
This reminds me of that Netflix talk on React [1].

In it, the guy first praises React to the heavens, then spends the rest of the
session explaining all the ways they had to disable and work around React to
get what they wanted with decent performance.

It seemed to me like their use case could have been done with jQuery in a few
hundred lines. Maybe I missed something.

[1]
[https://www.youtube.com/watch?v=g01dGsKbXOk](https://www.youtube.com/watch?v=g01dGsKbXOk)

~~~
SonicSoul
just curious how you arrived at jQuery comparison. isn't that just a library
for DOM utilities while react is a view engine optimized for minimum dom
manipulation using observable pattern?

~~~
et1337
I made the comparison because at the beginning of the video, he talks about
how they split into two teams; one used jQuery and the other React. Apparently
the jQuery team moved significantly slower. I found that hard to believe given
all the hacks they had to with React later on.

~~~
tiglionabbit
The React team was probably quicker at responding to the designers' ideas. The
stuff that took a longer time was getting all the transition animations to
work, which can be difficult in any higher-level framework.

------
acjohnson55
As someone who was almost immediately made happy by React, ES6, Redux, and
boilerplates, I'm not the target audience. But I feel like this would make me
un-sad if I felt overwhelmed by all the choices.

I think the Redux guide itself ([http://redux.js.org/](http://redux.js.org/))
also does a fantastic job of a very gradual release into complexity. I
recommend that anyone who feels they may want a Flux-like store read through
the whole guide. It took me a day or two, but I found it to be extremely clear
and enlightening.

~~~
davej
Also, the free "Getting Started with Redux" video course:
[https://egghead.io/series/getting-started-with-
redux](https://egghead.io/series/getting-started-with-redux)

The approach taken in the videos is great because it starts off with
implementing your own simplified version of Redux and builds on that. There
are no "magic" steps, this makes it much easier to develop an understanding of
how it works.

~~~
Klathmon
Just to throw another one in there, this github tutorial really helped it
click for me: [https://github.com/happypoulp/redux-
tutorial/blob/master/00_...](https://github.com/happypoulp/redux-
tutorial/blob/master/00_introduction.js)

The rest of the tutorials left me feeling frustrated not really knowing why.
This one i just breezed through.

~~~
merpnderp
Following the official redux tutorials left me and my boss independently
frustrated and turned off by the app.js description. We had both given up on
redux until I followed this tutorial and it explained how simple and elegant
the way components received properties from the redux state in th connect
call.

Without this tutorial we wouldn't be experiencing the ease and joy redux can
bring to large react apps (We're currently porting a large messy Angular app
to react piece by piece by replacing just leafs of the app at a time)

~~~
Klathmon
I was actually surprised when i started, because it starts with describing
flux and how it works (and compares it to a more traditional MVC arch). Then
it just slowly removes pieces until you get to a redux system.

------
gorkemyurt
Please keep writing dan abramov! May I suggest turning some of your
stackoverflow answers to longer essays/blog posts in an organized fashion like
[https://www.objc.io/issues/](https://www.objc.io/issues/)

------
falcolas
Where's the branch for "sad because I know react, and have to change half a
dozen files with dozens of lines of boilerplate each for each change request"?

I know a few of those - folks who aren't beginners and who loved react to
begin with, but are getting slowly disillusioned by the sheer volume of
changes required to modify a data source or add a new widget.

Dropping flux or changing bundlers won't change the core of react... nor will
writing any number of "helpful criticism" blog posts.

~~~
danabramov
Would you mind expanding on this with some specific examples?

------
djfm
I think React, in particular in combination with a flux pattern such as redux,
has only _shifted_ complexity.

Complexity shifted from a mess of jQuery event handlers shuffling the DOM
around to an intimidating mathematical abstraction in the form of functional
programming.

The benefit is that you _can_ reason about pure functions, whereas you cannot
reason about a mess of intertwined event handlers.

Between to equally complex problems, react forces you to converge on a problem
that you can actually solve.

Programming is hard. I think what's happening now is that we're starting to
discover issues that were previously hidden by problems that are now solved.

------
plexicle
I have tried to get in to React all week. The technology is easy, but it's
Webpack that I'm having trouble enjoying.

All I want is are two simple configs. A dev one with a server/hot loader, and
a prod one that concats/minifies. ES2015. That's it. That just doesn't exist
out there. It's either no decent production bundler, or it's like 15 files and
900 lines of configuration that seem completely overkill.

I don't know. I don't have time to learn how the tooling works, but I also
don't want a bunch of magic. Angular 2 is looking really good right now even
with the (still very incomplete) angular-cli tool.

Dang. I just want my simple gulpfile back.

~~~
danabramov
Check out [https://github.com/ryanflorence/react-
project](https://github.com/ryanflorence/react-project), it’s very new but
seems similar to what you are aiming for.

~~~
octref
Isn't that exactly what he's not aiming for, namely "15 files and 900 lines of
configuration that seem completely overkill"?

This seems to remove complexity but it just hides the complexity in the
dependency. When something doesn't work out or he wants to change the behavior
he still has to delve into these "15 files and 900 lines of configuration".

~~~
danabramov
It has focus on great production features without diving into config until you
are ready.

For something more approachable but less powerful check out
[https://github.com/insin/nwb](https://github.com/insin/nwb).

------
todd3834
We wanted to make it as easy as possible for new developers to jump into the
React ecosystem without having to worry about how to set up WebPack, hook up
redux, worry about styles etc… That's why we created
[https://github.com/TrueCar/gluestick](https://github.com/TrueCar/gluestick)
which is a command line interface to help you get started. As Rails developers
we missed commands like `rails new` or `rails generate` so we tried to make
something similar for our front-end environment.

I highly recommend this blog post for anyone who is struggling with setting up
React/Redux [https://www.drivenbycode.com/getting-started-with-
gluestick/](https://www.drivenbycode.com/getting-started-with-gluestick/)

------
joelcollinsdc
There is an abundance of poorly written react apps popping up everywhere. Go
to netflix and search for movies... the experience is terrible. The search box
lags typing by a long shot. So much so its almost impossible to type in the
full text of a movie name. I'm sure there is the correct way to do this (not
making the field a controlled component?) but the problem being there on such
a major site is a sign that its hard to do react correctly.

~~~
jaegerpicker
I just went to netflix and it's not at all how you describe. It's incredibly
fast and live filters as I type. There may be an abundance of poorly written
react apps out there but netflix does not appear to be one.

~~~
joelcollinsdc
maybe i'm just typing too fast. I tried "the best marigold" (for the best
marigold hotel). I watched the i in marigold disappear from the search box.
Deleting the string (by holding down the delete key, the X works just fine)
takes forever as well. I'm using chrome if it matters.

~~~
janpieterz
Just tested it and didn't find it super bad, but I am honestly (negatively)
surprised. It does indeed lag quite a bit and feels very unnatural. Chrome
here as well. I use React quite a bit myself and haven't experienced this in
my own apps. Odd!

There's also a slightly annoying flicker when you type the last bit and it
keeps returning the same movies.

~~~
sushid
The slow text input problem is probably because they're updating their redux
or flux store on every keypress.

~~~
janpieterz
Something like that certainly plays it's role. I'm doing that as well for
certain inputs and experience no lag at all, so it depends more on their
implementation of the store. I think their search store is probably doing a
lot more than mine (although, entering text, querying an API, processing
response async). It seems like they could introduce some optimizations there.

------
raziel2p
Some of these are a bit dubious. "Are you using a bundler?" If yes: "try not
using a bundler." If no: "try using a bundler." Same for flux/redux.

~~~
tptacek
I think you've missed the point. The thesis of the flowchart isn't that
there's just one way to build React programs, but rather that it's the
opposite: one reason people get sad with React is that they cargo-cult things
from other projects that aren't relevant to their own project, and another
reason is that people are missing things from other projects that might help.

~~~
debacle
Using React without having a clear understanding of why is cargo-culting.

~~~
tptacek
I don't think that's true, or if it is, the first time you use any new tool
you're probably cargo-culting.

------
happytrails
All these libraries make me sad.

------
c0ffe
Sometime ago, i tried react and found a property named like
"do_not_modify_or_you_will_be_fired" (i dont remember in which object).

I understand encapsulation is necessary, but i wonder how feels working with
someone who writes code with a shotgun next to him / her.

~~~
danabramov
Not sure what your point is about th shotgun. The point of that export is to
keep supporting old API with a deprecation warning while it is being moved
into another package. It is temporary.

------
kruhft
I've just started playing with React and my general opinion is that it's a
very 'Facebook' project. Lots of restrictions on what you can do and when
keeping all of the coders in line with what you're supposed to be doing and
following the 'Facebook' way of programming. I'm sure it's great for writing
traditional crud apps, but anything outside of the box that it wasn't intended
is a major pain requiring major hacks just to get around it's ideas of data
protection and timing.

I'm sure there are plenty that like this rigidity, but for me, I'll pass.

~~~
tptacek
This is the weirdest argument I've ever heard against React, and, as someone
who does a fair bit of React work, I try to pay attention to all those
arguments.

~~~
dsp1234
It's certainly a weird phrasing of an argument. However, it seems reasonable
that some programmers will not like the specific style of structure that react
espouses. Specifically the top-down push of data through parent-child
component relationships. Specifically, if you are working with a lot of third
party components that are not react based, it can be hard (or a lot of
boilerplate) to contain them within react applications.

~~~
ergothus
But you certainly can NOT do that. You can write "smart" components that each
talk to the necessary store(s) and make decisions.

As your project grows, you'll come to see WHY small, dumb components are
helpful, and how the top-down view manages the scope of rerendering.

You can come around to the espoused best practices organically.

~~~
apalmer
You can but fundamentally, if you dont buy into the fundamental guiding
principles that a framework is based on, you probably shouldn't use the
framework.

Its like saying lets use angular but not limit DOM manipulation in directives,
build fat controllers that include direct requests to the server and business
logic because all the service boiler plate is annoying and makes the
application harder to reason about, and add objects directly to the global
object because angulars dependency injection based on string values is error
prone, not DRY, and kinda fool hardy, not use data binding because of the
performance issues...

yeah those may be valid points, but if you buy into that you should just drop
angular and use backbone or something else...

------
amadeusw
I wish I saw this a couple weeks earlier, before I gave up on React-Redux. Its
documentation and Dan's talks work well for isolated samples, but I had no
luck building a larger system that binds all the pieces together.

There is no definitive documentation source (like msdn or angular docs) and
every tutorial and guide came with its own massive set of boilerplates and
libraries. These libraries did not have good documentation, either.

React-redux brings a fantastic way of thinking about the application, and I'm
looking forward to seeing appropriate documentation.

~~~
danabramov
Mind expanding on specific challenges? We’re happy to hear your input at
[https://productpains.com/product/redux/](https://productpains.com/product/redux/).

------
fludlight
React makes me sad because the PATENTS file means I can't sell my creation to
anyone suing Facebook for patent infringement. Personally, I don't think that
software should be patentable, but it is and deep pocketed companies are
always suing each other over this and other IP. Even if they aren't today,
there is no guarantee that they won't tomorrow. So why bother with a
technology that pisses in the proverbial pool, especially one full of lawyers
(aka deal killers)?

------
sergiotapia
Give React a try with Meteor and your head will explode.

Suddenly everything works out of the box, you get nice ES6 syntax out of the
box, files structure is flexible out of the box - notice a trend?

Meteor and React is hands down the best way to use React in my honest opinion.
Meteor 1.3 will come out very soon and will have full NPM and module support,
after that I think Meteor will take the web by storm and become the defacto
way to build modern webapps. None of this webpack silliness.

~~~
beefsack
Does Meteor scale to hundreds of concurrent users yet? I've used it multiple
times in the past and have always hit performance barriers even at tens of
users, and have found it make scaling your infrastructure nigh on impossible.

~~~
sergiotapia
Yes it does, easily. And scaling is even easier when you use React because you
'subscribe' to data when the component is 'mounted' and when the component is
destroyed you remove that subscription.

And this all happens for you automatically. No lie, React makes Meteor scale
by virtue of how it forces you to architect your data usage.

------
shruubi
Am I the only one that finds it weird that this entire chart is about morphing
how you use React into something that works for you rather than helping you
evaluate your needs and identify what might be a non-react solution.

Why are we as an industry suddenly so married to the idea that rather than
evaluating other solutions we should just hammer away at React until it works
for what we need?

~~~
danabramov
Because this is exactly what people do before writing sad posts about how you
“have to” use Flux, ES6, Webpack to use React. People get that impression
because they search for “React boilerplates” and extrapolate. It’s great that
you avoided this trap!

------
ajsharp
Ah, of course, a flowchart! The CLASSIC path to understanding a library.

------
ryanswapp
I think Meteor 1.3 + React is a really promising stack. If you are overwhelmed
by all that comes with the default React stack (Webpack, Redux, React Router,
etc...) then give Meteor 1.3 + React a try. It eliminates the need to write
your own build system, makes writing a full stack JS app stupid simple, and
overall makes you a lot happier.

~~~
tyh
As a js newbie I have to say Meteor + React is very easy to get started in.
Add in webstorm ide and I feel like I am back in .net world.

I am still using 1.2.1, but I am excited about the more streamlined npm
integration in 1.3.

------
mrharrison
I want to start using React but I think I'm going to stick with Angular for
now. I have all of the gotchas of Angular figured out and I think I want to
wait another year for the dust to settle on React. By looking at the flowchart
it looks like the React ecosystem is still quite Alpha and learning to grow
up.

~~~
ENGNR
As someone who came from angular, if your app is going to get large react is
far better than angular.

For small pages / forms angular is in the sweet spot, so it depends on how
your application is setup (not to say you can't do large apps.. but
performance is harder in angular)

~~~
mrharrison
Looking to use react because of code cleanliness. Never had a performance
problem with angular and have done two apps large apps thus far. I feel like
people who have performance problems are just putting too much html on the
page, and should rethink their design and rendering philosophy.

------
hahamrfunnyguy
It makes me sad looking at apps made with React. I am currently using
Knockout.js and Router.js which is working out very well. I like that your
code is concerned with maintaining the state of the VM, not rendering the
view.

What is gained by building an app in React, and are there certain scenarios
where it really shines?

~~~
badthingfactory
Having built a rather large SPA with Knockout, these are advantages I've found
with React:

1) I don't have to worry about whether a property should be observable or not.
2) When changing a property from non-observable to observable, adding parens
to most (or all) references is a burden 3) Screens with a large amount of
state become difficult to manage and reason about with knockout. Should I use
.subscribe, .computed, .pureComputed etc. With React, call .setState, and
write plain javascript for everything else. 4) Mapping large objects to
observable view models manually isn't fun and the knockout mapping plugin
isn't good. React deals with plain objects. 5) Knockout components perform
poorly compared to react components with large amounts of data. 6) Knockout is
not intelligent in the way it renders. If you replace the value of an
observableArray, Knockout will completely re-render any piece of UI bound to
that array. This is especially bad when paired with #5. React does a virtual
DOM diff and only renders the bits that have changed. 7) With knockout, I have
to concern myself with how to go about importing html templates into my
components. React is javascript-only. Just use React.createElement, or JSX if
you're OK with transpiling. 8) React tooling is infinitely better. I waste a
lot of time trying to figure out why some binding is throwing errors in
knockout. I've never experienced this issue in react, especially when using
PropTypes. 9) Custom knockout bindings to implement 3rd party libraries can be
an absolute disaster - especially when attempting to support 2-way binding. It
felt like every custom binding I wrote in knockout was full of hacks and
terrible code. I haven't felt this way at all with React, and I only have to
worry about binding in one direction.

------
rmetzler
I really like React, but I have to admit, that I don't write big apps with it
(yet).

There is one thing though which I find results in subtil bugs (entirely my
fault): When one input is changing and depending on that input another output
value has to change than the input shouldn't change state yet and the output
should be computed from input (+ state where necessary). Only then you should
set the state.

Do not set the state before computing the output and don't compute the output
from the previous state only. This will result in subtle and sometimes hard-
to-find bugs.

~~~
danabramov
If you’re saying that `this.state` doesn’t update immediately after
`this.setState` so you can‘t use the previous value, one way to get around
this is to use `this.setState` overload that takes a function:

    
    
        this.setState(prevState => ({ prevState.count + 1 }))
    

This way all the changes will be stacked on top of each other correctly.

------
programminggeek
Perhaps the answer is to not use React.

~~~
dsp1234
FTA:

Q: "Are you still sad?"

A: "... Consider another stack that better suites[sic] your needs (eg. Ember)"

The author has anticipated that react is not always the solution that is
appropriate, and provided guidance in the case that react isn't actually a
good fit for the project at hand.

------
novaleaf
nice flowchart, i know the point of redux but man the boilerplate needed to
create a component sucks:

    
    
      class _MyActualComponent extends React.Component<reduxScafolding.Action & { myReduxState: reduxScafolding.ReduxState; pushPath: ReduxSimpleRouter.pushPath; } & { myActualProp: string; }, {}>{
      //my component's implementation goes here.
      }
    
      /** type for casting (so consumers know the props they are required to pass */
      class IMyComponentVisibleType extends React.Component<{ myActualProp: string; }, {}> { };
    
      /** instrument my component with redux */
      export var MyComponent = ReactRedux.connect(
      (reduxStoreState) => { //subscripbe to reduxStore updates (Called every change). 
          return { myReduxState: reduxStoreState.myReduxState }; //map myReduxState to props
      }
      , _.merge({}, {}, { pushPath: ReduxSimpleRouter.pushPath }, reduxScafolding.action) as any  //redux-binds, then includes the pushPath() method for use in our _App Component
      )(_MyActualComponent) as any as typeof IMyComponentVisibleType;
    

ps: yes, about 3 lines of that is because I use Typescript.

~~~
olalonde
What language is this? I'm using es6 and most of my components just look like
this:

    
    
      export default ({ name }) => (
        <div>hello {name}</div>
      )
    

With Redux connect:

    
    
      const SomeComponent = ({ name }) => (
        <div>hello {name}</div>
      )
    
      export default connect(s => ({
        name: s.user.name
      }))(SomeComponent)

~~~
novaleaf
The code I wrote is Typescript (ES6 with typings), I am using the ES6 class
style React Components.

you are using the lambda style components which is fine for simple stuff but
for heavier stuff the class-style components are needed. also you are not
passing the reducer actions, etc.

Still, what you are showing in your simple example looks pretty similar to the
amount of boilerplate I'm seeing with Redux, so it looks like there's not
really an easier way.

------
LAMike
React did make me sad, I was confused and frustrated configuring my app
instead of building it. I switched to Vue.js and now I'm happy again.

------
christopher_
It's an interesting topic since React and the React ecosystem is great but
it's so fragmented that it's difficult to get started with. What's the trade
off between modularity in tools and productivity?

------
aidenn0
This flowchart assumes you are writing in javascript. Perhaps this is
understandable as it's a javascript library, but there are several frameworks
for other languages (most notably Om/Clojurescript).

~~~
erichmond
Why in the world is this downvoted? Om/CLJS has some of the nicest bindings
for React. It's _extremely_ valid that if you are frustrated with React that
you could experiment with the clojurescript ecosystem to see if that would
"make you happy".

------
marknutter
I had a hard time determining whether or not this flowchart was satire or not.

~~~
grumblestumble
Agreed. I was kind of shocked to open up the comments and see people taking
this at face value. I know this isn't reddit, but "upvoted because React"
seems to be just as much in play over here.

~~~
uptownJimmy
I lol'd the minute I saw the flow chart. It's absurd. Helpful and well-
intentioned, but absurd.

~~~
danabramov
Thank you for the criticism! Would you like to help me understand its flaws
better so I can improve in the future?

~~~
grumblestumble
3 things:

1\. Much of it reads as"are you taking this approach? yes? don't take this
approach. no? take this approach."

2\. There are also a couple of flowchart errors ("are you working on a
production app" appears twice for no reason).

3\. The main reason React makes me sad is the need for excruciating flowcharts
like this.

As a result, the entire thing comes across as self-parody. For context, I'm a
developer who works on a large enterprise app with a full build toolchain
(npm, babel, webpack, sass, etc ad infinitum).

~~~
danneu
If you work with such a large build chain, how did you not realize that the
flowchart is really about tooling complexity in the javascript ecosystem, in
general?

Also, the "are you working on a production app?" has two nodes so that it can
model the fork into {yes bundle, no bundle}, common in flowcharts.

------
blainesch
This feels like it builds off of the philosophy of not being a victim.. if you
find a problem, just fix it. In these use cases, that is simple to do.

------
glossyscr
tl;dr + my suggestion:

Use React together with Redux, Webpack and Immutable (my suggestion).

[http://teropa.info/blog/2015/09/10/full-stack-redux-
tutorial...](http://teropa.info/blog/2015/09/10/full-stack-redux-
tutorial.html)

------
rickhanlonii
TL;DR: If React makes you sad: try it without boilerplates, *flux, or ES6.

------
qntmfred
what's the point of presenting this as a flowchart?

------
gavi
I am glad to be able to copy the links off the flowchart

------
Scarbutt
can JSX be translated in the browser? that will make it even easier to avoid
tooling and just use script tags for dev.

~~~
th0ma5
Yes, there is additional js loaded to do that. In the developer console you
get a warning. It may be a tad slower.

~~~
zodiac
Are you referring to JSXTransformer? I thought that was deprecated?

~~~
andreynering
Yes, but now there's a version of Babel that runs in the browser and
transpiles from JSX.

------
amelius
Short version:

1\. Does react make you sad?

2\. Refactor all your code.

3\. React makes you happy.

------
tylermauthe
This is flipping brilliant!

------
draw_down
This comment thread feels so barren, without a bunch of seasoned software
professionals encountering JS build tools and immediately taking leave of
their senses and declaring defeat.

------
vdnkh
Everyone complaining about how React is just a trend is missing the point of
React. It's not some revolutionary flash-in-the-pan technology based on a
mystical black box, it's an aggregation of best practices that everyone
(including yourself) has been clamoring to have implemented for years. Web
components? Check. Object.Observer? Check. Virtual DOM? Check.

~~~
kawera
Why not Web components directly? (genuinely interested, soon I'll have to
chose one way or another for a new project)

~~~
spankalee
I work on a web components library, so I'm very biased here, but web
components will very soon have broad compatible support across all the major
browser engines. It's the only interoperable solution going forward, because
every framework out there right now is a silo unto itself.

~~~
kawera
Thanks, that's my understanding too. I've used Polymer in the past but before
1.0, will look at it again. No doubt web components are the future though, I
only wonder if widespread browser support will be a reality in a 12-18 months
timeframe.

------
auggierose
Lol. I found React interesting, too, but I don't like to read Javascript code,
so I rolled my own React-like framework in Scala. Life is so much easier if
you don't have to depend on other peoples mess.

~~~
verisimilidude
...where "other peoples mess" is based on battle-hardened production code from
Facebook...

~~~
goldbrick
"battle-hardened", yet churns drastically every release?

You and I have different ideas of what battle hardened means.

~~~
aidenn0
I have a react app that is almost 2 years old now and the only change I had to
make was when they moved a function from the React to the ReactDOM namespace.

~~~
goldbrick
It wouldn't happen to be open source then would it? Perhaps I'm just React-ing
wrong.

~~~
aidenn0
It is, but it's not written in javascript[1]. Flux came out when I was in the
middle of developing it, and I spent hours reading about it, looking at it and
playing with it, and it just didn't solve any problems that I had.

Note that the community's ideas of best-practices, and all of the ecosystem
around react is changing at an absurd pace, but core react is fairly stable.

1: [https://github.com/jasom/cl-fccs](https://github.com/jasom/cl-fccs)

