
Don't React - muraiki
http://staltz.com/dont-react/
======
ryanackley
This is a repost from a few months ago. Relevant because the author commented
on the original HN post
[https://news.ycombinator.com/item?id=8819115](https://news.ycombinator.com/item?id=8819115)

------
dwg
I recently finished building a small-ish web app for a major federal
Government customer in react.js. They are very happy with responsiveness and
quality of the product. I'm very happy with how easy and cost-effective it was
to build.

To get an idea of the size of the app, it has about 20 components. However,
some of the components could (and probably should) be broken down. My hunch is
that with refactoring the final number would probably be around 30 to 40.

Other frameworks that I have used professionally include Backbone.js,
Knockout.js, and Angular.js. My subjective (i.e. non-scientifically-measured)
experience with React.js was that it took less time to build a comparatively
sized application, and there were fewer bugs. All frameworks have a learning
curve, but I felt React.js was pretty easy to get into. There are not a lot of
"things" you have to learn about. In this project I didn't have to train
anyone else to use React.js, but I believe it would have been relatively
easier to do than training for other frameworks, which I have also done in the
past.

The bottom line is that my experience was very positive and I will definitely
use React.js again on future projects, should a suitable one come my way. I'm
sure react.js could be better, but the authors recommendation not to use it
based on not being pure enough is total bs.

~~~
balls187
As is covered ad naseum else where, ReactJS is just a way to do Views.

What did you use to manage state, data flow, communication to servers, etc?

~~~
woah
You can actually do a lot of that stuff with JavaScript, it turns out.

~~~
balls187
So you end up with an unmaintainable pile of javascript?

Or are advocating reinventing the wheel and writing a bunch of boiler plate
javascript to marshal data, update state, etc?

\----

One major reason to use a JS framework is to enforce good design and coding
practices to allow for more maintainable code.

You can certainly implement these patterns yourself in Javascript, but you are
reinventing the wheel, which is an antipattern in pretty much all but the
edgiest cases.

~~~
woah
React abstracts away the stuff that usually makes JS complicated, like DOM
manipulation, or dealing with observables. What you're left with is view
components that you can just stick a regular JSON tree into. For instance,
updating state is something that you don't really need to do in React. Just
update your JSON tree, and your interface will match. And JS is really good at
monkeying around with JSON.

There is some stuff like routers etc. that you might not want to write
yourself. Luckily there is a universe of components you can choose from,
instead of one that some guy at google thought was good.

------
danesparza
Wow. This dude got really hung-up on the name 'React' (assuming that had to do
with reactive programming). His summary of 'React sucks at reactive
programming' is ... true? It also kind of misses the point.

The React team clearly states their design goals here:
[https://facebook.github.io/react/](https://facebook.github.io/react/) ... and
they have nothing to do with reactive programming.

~~~
muraiki
Apparently my submission of this was a repost -- the author commented on the
original post saying:

"Presentation author here. I should have taken this down before it popped up
on HN or elsewhere. The video of this presentation is worth watching, because
it's tongue-in-cheek through-out. But the slides are not worth reading,
otherwise people take it seriously like it's happening here now. Cycle isn't
the solution to everything, it's just one guy's ongoing experiment."

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

Anyways, I found the ideas interesting because I think that its use of
Reactive Extensions solves a variety of frontend problems elegantly (and Rx
works on backend problems too, making it even more compelling). I made a
jsfiddle that explains a bit about Rx to hopefully provide enough context for
"why would you use this?"
[http://jsfiddle.net/nmd88wum/](http://jsfiddle.net/nmd88wum/)

Anyways, sorry for the respost, and sorry to the author for dragging up
something he apparently didn't want being dragged up again. :(

------
impostervt
For anyone else who, like me, didn't realize it - there's a little triangle on
the bottom right to let you go through the presentation.

~~~
ryannevius
What an awful UI decision. I wouldn't have even noticed it.

EDIT: This apparently wasn't intended to be navigated by the general public,
as explained by a comment below.

~~~
S4M
Yeah, I had to read the source code of the page to understand it was actually
a presentation.

------
jlongster
I actually look forward to the day when React is not engulfed in hype, so
people will stop complaining that it's just going to go away when the hype
dies.

Programmers love to make things. When you make something, you want to bash the
thing that you are "better" at. This comes will all kinds of blindfolds though
(you may be on the right track, but you need to be aware of these blindfolds).
There are so many examples as to why his criticisms don't hold. If you don't
like something about React, it's easy to make your own base component and add
your own Observable semantics. Check out Om, a ClojureScript framework on top
of React, which changes all sorts of stuff
([https://github.com/omcljs/om](https://github.com/omcljs/om)). React is a
platform
([https://www.youtube.com/watch?v=5hGHdETNteE](https://www.youtube.com/watch?v=5hGHdETNteE)).

Why is it so important to reuse React? When you author a new framework,
another blindfold is lack of community. You don't understand how important it
is that authors of React can download tens to hundreds of incredibly advanced
components ready to use (like [https://github.com/gaearon/react-
dnd](https://github.com/gaearon/react-dnd)).

EDIT: Apparently, this presentation was tongue-in-cheek
([https://news.ycombinator.com/item?id=9316187](https://news.ycombinator.com/item?id=9316187)),
which totally changes everything. I hate just seeing the slides!

~~~
i_s
Some of the criticisms the author points out still hold. For example,
criticism that React doesn't give a place to plug in to do post-processing on
nodes is valid, and is even a point that David Nolen makes in the video you
linked to.

The author is probably wrong to dismiss React because of all the other
benefits, and the community/platform aspects you brought up, but him
complaining about these issues (the subset of his issues that are valid, that
is) still provides a lot of value to the community.

~~~
jlongster
That's definitely true, it's great to see parts where React doesn't allow
people to play with something. It would be a lot more constructive though to
build on top of React so we could more easily see the point. Additionally a
lot of these problems are well known so before building your own framework,
it's worth engaging the React community to see what we are thinking about
them.

------
Termina1
I think that author is completely right about the part, that React has the
only one reactive part — its render function. But I don't see why it makes
React bad. I think it is great, fast and easy to use.

By the way, virtual-dom is a little bit early to use for production
application. For example, if you have some elements in your vdom, that are
changing after you render it (i.e. like buttons, embeded posts, etc.),
virtual-dom will be totally confused and unpredictable. For example, it can
duplicate some elements on the page.

I believe it happens because vdom depends on its internal index to traverse
real dom nodes. It is still a remarkably good piece of software.

~~~
dominotw
>For example, if you have some elements in your vdom, that are changing after
you render it (i.e. like buttons, embeded posts, etc.), virtual-dom will be
totally confused and unpredictable.

I can't think of a reason that someone would use react and still bypass it do
their own dom modifications.

~~~
lhorie
This usually happens when you want to use 3rd party libraries (e.g. jQuery
draggables, Bootstrap tooltips, or anything that polyfills an unsupported DOM
element)

------
ryannevius
TL;DR: React sucks. React isn't "reactive". Oh, and check out this reactive
framework he has been working on:
[https://github.com/staltz/cycle](https://github.com/staltz/cycle)

~~~
ctdonath
Context, please? just a little? Figuring the top comment on HN might be
relevant, I checked the comments (learned to do that before following main
link), then started the presentation, it did nothing, came back, found a
comment mentioning the near-hidden navigation, went back, read a dozen pages
and still don't know what he's talking about.

~~~
andrewmutz
The presentation from OP is difficult to use. Press the triangle in the lower
right of the page, or the right arrow key.

------
nwienert
React really doesn't give you any way to handle communication between
components besides going downwards, which is fine because that solves a lot of
problems.

You can very easily implement his 'subscribe' scenario in React. In fact, in
0.14 they are planning on having observe[0] to help you do just this.

Now, for my little plug. I've been working on Reapp since launch building a
couple real-world apps and I agree that React needs an observe/subscribe
model. In fact, I fell onto it while exploring a number of different patterns,
and it's stuck the best.

We launched reapp-kit[1] (in beta) a few days ago. It unifies a router,
immutable data, and a simple action system that lets you implement flux as
well as sideways data loading almost no time. And it's all run through React's
awesome contexts[2].

Here's a video of me writing a sideways actions in React, in seconds, using
reapp-kit: [https://www.youtube.com/watch?v=FALQU-
pVKJo](https://www.youtube.com/watch?v=FALQU-pVKJo)

[0]
[https://github.com/facebook/react/issues/3398](https://github.com/facebook/react/issues/3398)
[1] [https://github.com/reapp/reapp-kit](https://github.com/reapp/reapp-kit)
[2] [https://www.tildedave.com/2014/11/15/introduction-to-
context...](https://www.tildedave.com/2014/11/15/introduction-to-contexts-in-
react-js.html)

~~~
woah
Reapp looked awesome, the issue is that the 'back-swipe' on my iPhone 5c was
noticeably less smooth than the real thing... are you guys going to have to
resort to some more exotic techniques to fix that?

~~~
nwienert
At launch that hadn't been optimized, which it has been quite a bit since
then.

We do need to optimize it further. It's actually React that is getting in the
way here, but we don't want to cheat and break out of React because that would
mean so pretty major disadvantages. We're thinking about building out either a
separate animate() pipeline that works differently from render and just lets
you use refs to animate things. Or, just optimizing further as there is some
stuff we can do.

------
jasode
Regarding the page's "poor UI usability" without obvious navigation buttons:
I'm guessing the page is intended for the author's use in live presentations
(like MS PowerPoint) and is not meant to be a general purpose landing page.

The author used it that way here:
[https://www.youtube.com/watch?v=9QObt0SGriI](https://www.youtube.com/watch?v=9QObt0SGriI)

(I haven't seen the whole presentation so I can't comment if it's worthwhile
to watch.)

~~~
tinganho
The button was maybe created that way so people won't react.

------
ebbv
First, the UI for that presentation is terrible. The arrow in the lower right
is hard to notice, and on some slides it becomes invisible.

Second, the Cycle.js code on slide 18 is some of the nastiest, kludgey looking
JS I've ever seen.

I get the ideas behind Reactive Programming the author is presenting, and they
are interesting, but if that's the code his implementation is meant to
produce, no thank you.

~~~
bshimmin
It looks a little like a combination of React and Angular. Which probably
really isn't a good thing.

TodoMVC in Cycle is... intense: [https://github.com/staltz/todomvc-
cycle](https://github.com/staltz/todomvc-cycle)

------
grandalf
A few reasons to use React

\- it isn't a framework

\- thinking in terms of components can improve your code

\- very easy to prototype

\- react native

It's quite possible that React 1.0 or 2.0 will address all of the issues
staltz points out. No harm in pointing out flaws but React does have a lot of
good things going for it.

------
DigitalSea
To me it doesn't matter what React likes to think it is, to me as a front-end
developer all that matters is the tool that I choose can do the job. React is
just another tool, in a way it is like jQuery: it doesn't do everything and it
shouldn't be used for things that need something else more full figured or
suited for the task at hand.

I think Facebook do a great job explaining what React is and as far as I am
aware, they don't go claiming that React.js is a 100% reactive library. There
are no unclear intentions, Facebook saw a need to improve DOM performance and
they achieved it in a great library that I think is a pleasure to use.

I have built two projects solely using React and the Flux architecture. I
don't have exact figures, but it saved me a lot of time compared to using
something like AngularJS which has too many conventions and opinionated ways
of doing things. I was able to get a nice performant CRUD application running
in the space of a few days, most of the time was spent creating the API and
getting it to return the appropriate data.

How can you write off a library like React.js when it goes beyond just another
open source project, and unlike Google with AngularJS, Facebook aren't
dogfooding their own product and they are actually using it for parts of
Facebook, the Instagram website and a few other places. React.js is a battle-
tested library. Those who have used React.js on a proper project know that it
is very easy to use and its performance is better than any other SPA framework
by far. Unlike other frameworks and libraries, React.js can back up its claims
and has proven benchmark after benchmark it can render UI components extremely
fast and efficiently (with a concentrated effort to make it even faster).

Sure, React might do things differently and it might not be a pure form of
reactive programming, but it works and it works very well. Coupled with Flux,
you actually do get a nice and reactive development environment where events
are emitted and things are updated throughout your application from your
stores. I don't really see Flux being mentioned in the slideshow which is a
shame because Flux is the missing piece of the reactive puzzle.

It's easy to say something sucks without really giving an adequate reason why
it sucks. Seems like the author had a bad experience with React or perhaps
just wanted to ruffle some feathers. I also got the impression the author was
trying to pedal their own library Cycle.js which will no doubt be abandoned in
12 months time when it doesn't get as popular as he would have hoped. Nice
try, but not a very well thought out argument in my opinion.

~~~
toddmatthews
typo: Facebook ARE dogfooding

~~~
deweller
I prefer Facebook IS dogfooding. See [http://www.economist.com/style-
guide/singular-or-plural](http://www.economist.com/style-guide/singular-or-
plural)

------
ww520
It seems the author's notion of Reactive programming is listening for event.
While event handling is useful, it has been in Javascript for the longest time
and it's nothing new. Event based updates can have very poor performance, MxN
problem.

Also Reactive programming is more of having a declarative way to structure
data flow so that changes can happen automatically, like a spreadsheet.

------
ndreckshage
Blanket statement: anyone that makes blanket statements like 'React sucks' or
'Ember sucks' should not be taken seriously.

~~~
hackerboos
OP backs up his statement with examples. 'React sucks' (because there are
better ways to do this) was the conclusion of the presentation.

------
jaked89
It's worth mentioning Elm, a (truly) functional-reactive language, based on
virtual-DOM.

[http://elm-lang.org/](http://elm-lang.org/)

~~~
kodablah
While mentioning other tech, I have found Scala.js with Scala.Rx [1],
ScalaTags [2], and some glue [3] a great way to actually do reactive DOM
updates based on state change. I find this way cleaner than building and
diffing entire DOM trees (even if they are just AST's in JS). Mixed with
ScalaCSS [4] you have a nice type safe solution.

1 - [https://github.com/lihaoyi/scala.rx](https://github.com/lihaoyi/scala.rx)
2 -
[https://github.com/lihaoyi/scalatags](https://github.com/lihaoyi/scalatags) 3
- [https://github.com/rtimush/scalatags-
rx](https://github.com/rtimush/scalatags-rx) 4 -
[https://github.com/japgolly/scalacss/](https://github.com/japgolly/scalacss/)

------
neovive
Coming from a jQuery background, I'm intrigued by ReactJS (especially JSX and
components). However, I've also been reading up on Meteor and find it very
impressive (if you're willing to consider an end-to-end framework). I didn't
notice any mention of Meteor as an example of a true reactive framework in his
presentation.

~~~
posnet
Funny you should say that, there have been a lot of presentation/articles in
the meteor community about using react with meteor instead of its native
rendering engine. As it basically solves all of the authors problems with
react.

------
bluetidepro
With all the hype going around for React, I wouldn't mean getting the opinion
of some other fellow front-end peers to see what their 2 cents are with this.
I will say I honestly haven't looked into React enough to make a good call if
this slideshow holds up or not. React does seem to be riding the hype train
pretty fast, though.

~~~
wesleytodd
My experience with React has been great. And my opinion of the slides is that,
yes, someone can use react in an "interactive" style. But the one example is
just that, an example. I have found that it is really simple to adopt a
strictly reactive method.

To give some background, I started with virtual-dom when we were transitioning
away from angular. I built a bunch of "proof of concepts" with it, and tried
to build out a micro-framework around it for our company. Then we had a quick
meeting where we presented quickly on react, mithril and my homebrew. The guy
who did the react example had done it in like 20 minutes, and it was WAY more
elegant.

So my point here is that, yes, virtual-dom is a great project, but it just
doesn't have the "full package" like react. So we chose react and haven't
looked back.

------
gcz92
Also, lets not forget React Native. NO other framework can prove that
compatibility with mobile. A React programmer can now cover both web and
mobile development with relative ease. I'm not saying that React Native or
React is perfect, but I would argue it is the best option for any company with
limited developer resources.

~~~
empthought
Appcelerator Titanium says "Hi. Must be nice to just coast on hype without any
product support investment or proven track record."

~~~
untog
To be fair, Appcelerator used to be _awful_. My experiences with it a few
years ago mean I haven't tried it again since though, so I'll admit my opinion
is probably out of date.

------
staltz
Presentation author here. I didn't publish this to HN myself, it was just
discovered by someone among my repos.

Some important things I want to make clear:

1\. React is revolutionary. I really like the core idea inside it, which is
basically just this [https://joshaber.github.io/2015/01/30/why-react-native-
matte...](https://joshaber.github.io/2015/01/30/why-react-native-matters/)

2\. Apart from the core ideas, the surfacing API has its problems: synchronous
render (a problem for server-side rendering
[https://github.com/andreypopp/react-
async](https://github.com/andreypopp/react-async)), mutable API (setState)
etc, and most of my presentation. I've spoken to others in the industry (would
not like to mention names, but top experts anyway), and they both love React
and agree it is contaminated with a bit of bad API.

3\. React probably doesn't have the perfect API for the "UIs as pure function
of state" approach. It can be improved
[https://github.com/facebook/react/issues/3398](https://github.com/facebook/react/issues/3398)
and
[https://twitter.com/sebmarkbage/status/543660526908088320](https://twitter.com/sebmarkbage/status/543660526908088320)

4\. This presentation was given at a small meetup and I made it provocative on
purpose just to have some fun with friends. The type of stuff you talk about
in a small circle, not meant to publish on HN for the whole world
[https://www.youtube.com/watch?v=9QObt0SGriI](https://www.youtube.com/watch?v=9QObt0SGriI)

5\. Cycle.js is not _better_ than React, it is my personal ongoing exploration
in how to make React (or React's ideas) better. It is work in progress, and
I'm breaking it apart whenever I find a better way of doing stuff. E.g.
[https://github.com/staltz/cycle/issues/99](https://github.com/staltz/cycle/issues/99)

6\. Cycle.js is not an antagonist to React. I am currently experimenting with
Cycle.js + React Native.
[https://github.com/staltz/cycle/issues/91](https://github.com/staltz/cycle/issues/91)
If React's API would be a bit less restrictive, I would use it for the web
too. But virtual-dom by MattEsch is lighter and less restrictive, so I use
that.

7\. Don't be so harsh on HN as if I would be intentionally shouting to the
whole world that React sucks.

~~~
EugeneOZ
Well, not sure about first point. We already have FlightJS
([https://flightjs.github.io/](https://flightjs.github.io/)) couple of years,
which is event-driven also (even templates looks similar to React UI).

~~~
danabramov
Flight is not like React at all. I see DOM manipulation all over the place in
Flight examples.

~~~
EugeneOZ
Maybe that's the reason why it didn't take off the ground :) But their main
idea is event-driven design, so I still think it's common idea for React and
for Flight.

------
dabernathy89
Do people really consider Grunt dead?

~~~
ohitsdom
I'm also curious. I don't use grunt because my daily workflow is almost
entirely in Visual Studio, but I though grunt was the go-to for automation
tasks.

~~~
gcz92
Maybe the author meant that there is a lean towards gulp over grunt? Not sure.
but my company still uses grunt in production

------
jacques_chester
I'd be more worried about the unusual license.

React is under BSD, but includes additional terms in a PATENTS file. Very
generous terms. And yet ...

I'm not a lawyer, I couldn't even play one on TV. But it is _profoundly bloody
annoying_ that they didn't pick a well-understood, well-known license instead
of baking up their own Frankenlicense.

I'm sure their lawyers have a reason for not just using the Apache 2 license.
I'd love to know what it is.

In the meantime, every single company with fastidious lawyers is going to be
dealing with Legal yanking the emergency brake when they see React, because it
does not neatly fit into a known license.

------
muraiki
After submitting this, I'm not sure that the author's slides alone really
provide enough context about "reactive" in order to understand the criticisms
he's making.

To understand his criticism requires some familiarity with the cross-platform
Reactive Extensions library and its approach. I made a jsfiddle a while back
that illustrates how this works in a way that I hope is very straightforward:
[http://jsfiddle.net/nmd88wum/](http://jsfiddle.net/nmd88wum/)

------
nogridbag
I've used Flux now on a few toy microprojects and I found that while Flux's
unidirectional data flow is initially appealing (and I naturally tend to write
unidirectional code for very complex UIs in past apps),it makes the simple
cases much more tedious and error prone.

For example, given the simplest case of a Flux store handling events from a
single ajax call, I find I have to write code like this:

    
    
      onLoad() {
        this.loading = true;
        this.errorMsg = null;
        this.data = null;
        this.condition1 = null;
        this.condition2 = null;
        this.something = null;
      }
    
      onSuccess(data) {
        this.loading = false;
        this.errorMsg = null;
        this.data = data;
        this.condition1 = data.blah === 'Hello';
        this.condition2 = data.blah2 === 'World';
        this.something = data.something;
      }
    
      onFailure(errorMsg) {
        this.loading = false;
        this.errorMsg = errorMsg;
        this.data = null;
        this.condition1 = null;
        this.condition2 = null;
        this.something = null;
      }
    

If for some reason I was feeling crazy and I wanted the store to handle a
second Ajax call, the store code becomes much more cumbersome so I avoid this.

Even with some of the slicker Flux implementations, I still have tons more
boilerplate than a traditional MVC app which for the simple UIs makes the code
more difficult to reason about. For example, I find that in my store, I
frequently forget to "reset" some property thus making the state "invalid".
I've come up with this type of pattern, but it just feels... odd:

    
    
      resetInitialState() {
        this.loading = false;
        this.errorMsg = null;
        this.data = null;
        this.condition1 = null;
        this.condition2 = null;
        this.something = null;
      }
    
      onFailure(errorMsg) {
        this.resetInitialState();
        this.errorMsg = errorMsg;
      }

~~~
balls187
> I still have tons more boilerplate than a traditional MVC app which for the
> simple UIs makes the code more difficult to reason about.

I think this is just the relative immaturity of the ReactJS/Flux stack, and
having to do this boilerplate is just part of the cost of being bleeding edge
(much like struggling with understanding Transclusion/Directives/et-al when
Angular was first released with crappy documentation).

------
reactor
"There are only two kinds of languages: the ones people complain about and the
ones nobody uses" \- Stroustrup

Its kinda make sense in this context.

------
acdlite
The presentation has some really great points; it's a shame that it's wrapped
up in so much FUD.

But from what I can tell, it _does_ seem like React is moving in a more
reactive direction.

One example:
[https://github.com/facebook/react/issues/3398](https://github.com/facebook/react/issues/3398)
Another (not sure if this counts, but I think it does):
[https://github.com/reactjs/react-
future/blob/master/09%20-%2...](https://github.com/reactjs/react-
future/blob/master/09%20-%20Reduce%20State/01%20-%20Declarative%20Component%20Module.js)

------
robmclarty
I agree with others that the author seems to be missing the point of React.
Whether or not it is "reactive" or doing things the way you're _supposed_ to
do them is irrelevant. It's a tool, and it either helps you fix your problem,
or it doesn't. IMHO React helps a lot.

I've built a few non-trivial apps with React this year (e.g.,
[https://github.com/robmclarty/barss](https://github.com/robmclarty/barss)),
and after years spent building and maintaining apps made with backbone,
angular, jquery, and other libraries (considering the domain of React => the
view) I can easily say that React has saved oodles of time, allowed me to
greatly understand my apps as a whole much more clearly, and enabled me to
think less about propping up a structure for my app and focus on actually
designing my app.

The point is, it's not about what's passive or reactive or [insert enlightened
path to programming here]. It's about what works; what keeps the ball rolling;
what gets your app online and in front of users.

When it's snowing outside and I'm making a decision about what I should cover
my feet with, I'm concerned about "what will keep my feet dry?". When I'm
moving across town into a new apartment, I'm concerned with "what will have
enough volume to transport all my junk?". When I'm making an app, I'm
concerned with "what will make this design in my head work in a browser?".
Whether I wear boots or shoes, whether I use a diesel truck or a gasoline van,
or whether I use React or Whatever; that's not what's important.

I _like_ that React doesn't drag me into event-listener hell where stuff is
firing from somewhere that I don't know where. I _like_ that React
compartmentalizes templates with the behaviours that manipulate them. I _like_
that React passively alters itself based on state changes.

When it comes down to it, an app is, simply, an interface for mutating and
presenting data. It can be in one of many possible states at any given time.
React just presents a view of the app that is based on its current state of
data. With React, all I have to worry about, conceptually, is "what's the
data?" and my app reconfigures its presentation accordingly.

TL;DR At the end of the day it doesn't matter what's right or wrong, it
matters what realizes your intentions as a programmer (and as a human). The
way React works makes my job easier, more productive, and faster. It doesn't
suck at all.

------
tehcodez
Does anyone else have real world examples of how you would actually build an
application based on reactive programming? I've seen people from netflix give
the same talk over and over, but they never really seem to go past handling
drag or mouseover events. These account for maybe 1% of any of the
applications I've ever built.

------
EugeneOZ
I never understand people who claims "Don't use X" (about software). If you
don't like X - don't use X and calm down, don't be a bigot crying "you all are
doing it wrong" \- let people make mistakes. Maybe some of them will find
right solution on the next step, just don't stay on their way.

------
jt2190
Andre's twitter feed has a link to a article on the same topic. (edit: I find
it easier to read an article instead of slides.)

[http://futurice.com/blog/reactive-mvc-and-the-virtual-
dom](http://futurice.com/blog/reactive-mvc-and-the-virtual-dom)

~~~
jt2190
And the viedo of the presentation:
[https://youtu.be/9QObt0SGriI](https://youtu.be/9QObt0SGriI)

------
mrspeaker
Can we change the link to the video instead of the slide deck?
[https://www.youtube.com/watch?v=9QObt0SGriI&feature=youtu.be](https://www.youtube.com/watch?v=9QObt0SGriI&feature=youtu.be)

Slide decks are (mostly) meaningless without context.

------
TheCoelacanth
I feel like this presentation kind of misses the point. React itself isn't
reactive. It is a UI rendering library that is easy to use in a way that is
reactive. When used in the way that React's authors recommend, your
application will end up being written in a reactive style.

------
beefsack
It's becoming rather frustrating how often people are misinterpreting
"reactive programming", the author included.

[https://en.wikipedia.org/wiki/Reactive_programming](https://en.wikipedia.org/wiki/Reactive_programming)

------
augustl
I just want to say that this is the definition of "reactive" is amazing! Now I
finally understand what "reactive" actually means.

------
kyled
No delayed rendering? Isn't the programmer responsible for telling react when
to render?

