

ReactJS for Stupid People (2014) - s3nnyy
http://blog.andrewray.me/reactjs-for-stupid-people/

======
k__
Flux slowed me down at the start, but React was rather easy. Easier than Ember
for example. The API surface is tiny, everything is done with components and
the composition of them.

Flux on the other hand was hard to grasp, since all of the different
implementations and the naming problems. Actions in MVC are just methods of
the controller classes, but in Flux they are objects, which kinda threw me off
track right in the beginning.

Also, I came from ExtJS and Ember and was accustomed to two-way data binding
and the whole Flux thing felt backwards, because interacting with the Models
in Ember-Data didn't take any effort. After they were bound I just needed to
type my data and they get updated automatically. I just had to look about
gathering them at the end and send their updates to the server.

~~~
madeofpalk
FWIW, Redux is an amazing 'evolution'/implementation of Flux
[https://github.com/rackt/redux](https://github.com/rackt/redux)

I was always confused with 'Flux' and was never able to understand it. Redux
is very nice.

~~~
k__
I started with Redux.

But I didn't choose it. Another dev at the current project did.

It took me a few weeks to fully understand what Redux is about. I didn't know
about "one store for all", the difference between actions and action creators
and how immutability was mandatory.

I just jumped in and started my first component with a (rather bad) tutorial I
found with google and copied a Redux store and actions from a co-worker.

The Redux docs weren't good till 1.0

After I asked Dan something I realized I got it all wrong. But now I think
it's a really nice way to do front-ends.

------
sago

        $.post('/login', credentials, function(user) {
            $('header.name').text(user.name);
        });
    

> I can tell you from experience that this code will ruin your life

The alternative isn't React. It's

    
    
        $.post('/login', credentials, function( user ) {
            setUserName(user.name);
        });
    
        // Somewhere else...
        function setUserName(name) {
            $('header.name').text(name);
        }
    

React doesn't tell you 'who changed the header' either. Other than having a
central point through which changes are routed: like a function.

React gives you incremental HTML rendering via a virtual DOM. Which saves you
having to do that manually (though in many cases you don't need to do it at
all). A lot of this article reads like framework-fetishism.

On Flux, I like his comments there. I'm thinking of reinventing the command
pattern in Javascript and calling it SuperFlux...

~~~
lowboy
That solution just punts the ball down the field a bit. You still have to
figure out who called setUserName to mutate the DOM.

~~~
sago
Right, and you have to figure out who changed the model in React too. You
don't get magic traceability. If you want to know what caused a change,
neither helps. If you want to know what changed the DOM, both allow you to do
that. Only React makes it implicit (it may choose not to make any change, for
example), this approach is explicit.

This approach punts the ball into part of the field you can see, understand
and control. React punts the ball into someone else's stadium.

Framework-fetishism is being enamoured by things a framework does that you
could do yourself in a couple of lines of code. Unfortunately Javascript
programmers seem to be very vulnerable to it. There are good reasons to use
React, but they aren't what the article wants to praise.

~~~
stevebmark
You get plenty of magic traceability :) Check out redux. You get it in vanilla
Flux if you use immutable data. I would also suggest using React for a toy
project to learn more about it. The "pure"ity of the render function means you
can trace the state of the DOM directly to a Javascript object (declarative),
which was the point of the article's example. Your "down the road" code is
imperative, as in someone changes the DOM independent of the state of your
data.

~~~
sago
I've used React in anger, thanks.

So how do I tell from React where my model was changed, in what bit of my
code, that I couldn't tell just as easily in my own function?

React is only declarative in as much as it provides an imperative function to
convert between data structures. You can do this yourself, and should.

~~~
lowboy
You're not converting between data structures in your example, you're mutating
a stateful system. Moreover, I'd rather leverage a library so that I don't
have to manually do everything myself.

~~~
sago
I couldn't work out what point you're making in this response, sorry.

I was referring to the claim that _React_ is declarative. Not my code.

Things aren't declarative magically. A declarative system is one where you
declare a data structure, and you feed it to a separate bit of imperative code
that operates on that declaration. In react's code, the 'declaration' is a set
of HTML templates and the 'operation' is to create a corresponding DOM.

> you're mutating a stateful system

Both approaches do. React mutates state too.

> Moreover, I'd rather leverage a library

Good for you.

For some things React is a big time saving. But for many things it is a waste
of bandwidth, a waste of development time and a waste of programmer education.
Just like any library that isn't required. Using libraries is not free.

If you want the kinds of benefits the post highlights, you can get them much
cheaper with a few lines of code. If you want to import a full library to save
a few lines of code, that's your prerogative, of course.

React shines when you need a templating system and you can benefit from the
performance of a virtual DOM. If you want a basic virtual DOM, then you can do
it very easily yourself (a few lines of code in the simplest case), but as
things get more complex, it becomes a better tradeoff in favour of React. If
you want a comprehensive system, React becomes a very useful tool, one I rely
on myself. But it is important to understand what you need and why. If you
don't need a virtual DOM, then using React seems pretty foolish, to me.

Javascript is full of frameworks, and full of programmers who use them without
knowing what they're for.

~~~
lowboy
React encourages declarative usage. You declare some data and how it will be
rendered in JSX templates, and React does its thing. As a consumer of a
library I shouldn't have to care about what goes on under the hood, as long as
I know the API and its proper usage.

> Both approaches do. React mutates state too.

Right, but I don't have to concern myself with the stateful system (the DOM).
I can delegate that responsibility to React.

As to your other points, I agree that people should put more thought into
their selection of tools.

------
staltz
> React is ONLY THE VIEW LAYER.

> React gives you a template language and some function hooks to essentially
> render HTML.

This is actually wrong, despite the official page saying the same. It's the
biggest misconception in the React community. render() function outputs a data
structure which describes HTML and ALSO user event handlers on that HTML. Any
UI program does both: handle input user events and generate graphics output. A
View is only the latter part, hence React cannot be only the View.

Refer to original MVC paper
[http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf](http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf)

> A view is a (visual) representation of its model.

> … a view should never know about user input, such as mouse operations and
> keystrokes.

~~~
clay_to_n
Isn't it referring to the V in MVC? If that's the origin of "React is ONLY the
view layer", then I think it fits.

------
bryanlarsen
Note about the wide variety of flux implementations that scares people:

1: it's not that big a deal if you choose the "wrong" one. Flux
implementations are small and based on many similar concepts. Even if you
choose one that ends up being unmaintained, your flux choice will still stay a
solid choice. We are using 3 different flux implementations in our apps, and
have no plans to migrate any of them.

2: It's starting to look like redux has "won". Flummox, which was previously a
leading contender for the title, now recommends redux. Redux has a very simple
core, is an excellent merger of the best concepts of flux, elm and others, has
great documentation, and an extensive ecosystem of plugins.

~~~
danmaz74
We are also switching to Redux after trying Alt: Redux solves a couple of
fundamental problems with the original Flux architecture (in fact, Redux isn't
actually Flux).

I just wished Redux was a bit more opinionated. But it not being so will
certainly please many other people.

------
rbcoffee
It would be interesting to see a side by side comparison of people coding for
the exact same output, and the time difference between them. If React is
supposed to make coding faster, then why is the code a black box? Why do I
have to debug the React source code to find out what's going on. Too much div
soup, too much abstraction. I genuinely would love to see a code-off between
developers where they make a simple TODO app, with one in vanilla JS and the
other in React. Presuming the React developer has mastered React and won't run
into some form of roadblock (which is rare).

~~~
mtschopp
You cannot really compare a React project with a non-React project if it is
done by different people.

We use React since four months, and we develop faster compared to before, when
we used only jQuery.

~~~
sago
Was that because you now structure you code in a better way, or was it because
of React's functionality? And what aspect of the functionality was the most
productive? The templating system? Did you used to hand-code your HTML in
jQuery, or did you use templates in the HTML document?

(Genuine questions, not making a point).

~~~
mtschopp
A bit of both. With React we now have a much nicer code structure, because it
forces us to think in components. We have a JS file and an SCSS file for each
component. Before we rendered the view on the server side with Python/Jinja2.

I think there are many reasons for the productivity boost. Thinking in
components, more readable code, great debugging possibilities, understandable
data flow, to name a few.

And, last but not least, it is lots of fun :-).

------
addandsubtract
>Client-only rendering is why Soundcloud feels so slow and why Stack Overflow
(purely server side rendering) feels so fast.

Soundcloud might be "slower" than StackOverflow because it continuously
streams music while you're navigating the page. A car is also slower than a
drag racer, because it fits multiple people, luggage, and conforms to several
safety standards. But maybe we should all be driving drag racers instead.

~~~
bluejellybean
Isn't this the benefit of an isomorphic architecture? Get the initial speed of
server-side rendering but then let the feature-filled ajaxy goodness take
over.

------
alexro
Why didn't he say that ReactJs is in the early stages and is "only" for the
enthusiasts, thus, not for stupid!

~~~
myko
Maybe you're thinking of React Native?

~~~
alexro
The article was in 2014

------
serve_yay
ReactJS for stupid people: "oh great another JavaScript framework, so tired of
all the hype, can't wait for the next one to come out 17 seconds from now",
etc etc

~~~
dominotw
why the hate?

~~~
rsy96
He's not hating React; he's hating javascript.

~~~
blueside
he's hating the community, not the language

