
Don't React (Presentation - Use arrows to navigate) - jackhoy
http://staltz.com/dont-react/#/
======
staltz
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.

~~~
lhorie
Do you have a link to the video?

~~~
staltz
Conference organizers will put it up and hopefully post it here:
[https://twitter.com/trewebdev](https://twitter.com/trewebdev)

------
danr4
Okay, so React is not fully reactive. But to say people shouldn't use it
because it's not reactive? because it abstracts virtual-dom? because it should
be more reactive-friendly?!

Seems like the author was offended they said they are reactive, and made a
non-informative presentation, that comes off as a rant because of the rising
popularity.

Edit: looking at his Cycle framework's "Why?" on github, besides the part of
'Rendering separated from View' (arguably, you could say that React's render
returns React elements which are virtual-DOM elements equiv), you can use the
same approach with React.

My current project's component almost never update themselves, except minor UI
changes, which is understandable. apart from that, all the data flow comes
from above, and my components change according to it. oh and it's immutable
(immutable-js another great fb lib).

That's the thing about React, there's quite a diversity in approaches for
handling data, events, user actions, etc.

~~~
kuni-toko-tachi
Actually you are wrong. Follow him and others on twitter and you will see that
they are some of the most forward thinking people on these types of frontend
technologies.

om and elm.are the future, which is functional and immutable. React is the
gateway to those technologies, which have a long and strong academic
foundation.

The days of hacking together things on the frontend are over, more sound
approaches are needed, and those developers who embrace them will have their
pick of jobs and a fistful of cash.

~~~
SeoxyS
Om is built on top of React. I'm not sure how you reconcile "React sucks" with
"Om is the future" given that.

~~~
coldtea
> _I 'm not sure how you reconcile "React sucks" with "Om is the future" given
> that._

Maybe it fixes all the sucky parts?

~~~
nkohari
Not really. It's basically just a means of using ClojureScript with React.
That comes with some great stuff (immutability, for one), but AFAIK it doesn't
change anything too dramatically.

~~~
jeremiep
Have you used Om?

It completely changes the way you think about modelling applications and their
events. It's closer to Flux on steroids rather than a thin wrapper on top of
React.

------
F_Catalan
I have been programming for 30 years, 19 on the Web. I tried to learn Angular
and Ember and failed, more than once. Earlier this year I had to prototype a
fairly complex single page app and was severely time constrained. I tried
React and succeeded beyond both my expectations and those of the client. I am
in fact itching for a chance to use it again.

~~~
marrs
Yeah, same here, (not the 30 years part, the React FTW part) and for me the
virtual DOM is the least cool thing about it. Separation of props and state is
what I lust over.

Anyway, where I live React isn't getting noticed; it's Angular that's all the
rage, so maybe the author is fighting the wrong enemy.

------
lhorie
Disclaimer: I wrote Mithril (one of the vdom frameworks mentioned in the
presentation)

I like the idea of reactive programming, but it tends to add a lot of
indirection. This is theoretically desirable, but not necessarily pragmatic in
reality. A lot of frontend code in the wild is of the throw-away-in-a-few-
years nature and it's hard to get mindshare among developers if they're
required to learn stuff that feels academic when all they really care about is
getting stuff shipped the next day. Being able (forced?) to tightly couple a
controller and a view in Angular is one reason a lot of people like it.

I was giving a workshop on FP recently, and you'd be surprised at the number
of people who still don't grok `filter`. FRP is still way over a lot of
people's heads. Hopefully the industry will warm up more to the concept as
React, Mithril, Meteor, etc get more popular.

@staltz WRT Cycle.js itself:

I took a look at the TodoMVC example and was surprised to see intents reading
data from DOM element data attributes (e.g.
[https://github.com/staltz/todomvc-
cycle/blob/master/js/inten...](https://github.com/staltz/todomvc-
cycle/blob/master/js/intents/todos.js#L7-21) ). How does one go about doing
non-string parameterized intents? For example, I often need to reference an
entity from an event handler and searching for it in a collection by ID seems
wasteful. In Mithril, for example, handlers can receive parameters as inputs
either via closures from the view or via partial application (i.e.
Function::bind). This is especially useful for event handlers that deal with
relationships between two or more different entities. Is there a similar
mechanism in Cycle.js?

~~~
discreteevent
If they don't grok filter then they cannot even interact with a relational
database at the simplest level (a select, where). I think there is a certain
level below which you are not obliged to dumb it down further.

~~~
lhorie
Sure there are those who get by w/ Google/StackOverflow/copy+paste (and hey,
everyone has to start somewhere), but also remember that not everyone is a
full stack dev. Lots of people make a living programming exclusively on the
frontend.

There are also those that understand the concept of filtering at a basic level
when reading tutorials about it, but still write for/if loops when it comes to
producing actual code and it doesn't occur to them that it's possible to take
the anonymous function out of the filter() call and give it a name to start
building up a compositional foundation in their codebases.

My point though is that the benefits of FRP are somewhat out of line with the
types of problems that people face in the real world.

~~~
staltz
I use a simple example of how Rx (not FRP, that's something completely
different) benefits in programming: the traditional use case of analytics
events is to spread Analytics.sendEvent() calls in many places of your
codebase. Using Rx to solve this problem, things get inverted: you have all
analytics events defined in one module, they are listening to events happening
throughout the codebase. Sometimes the platform (mobile or whatnot, think
beyond JS) provides convenient lifecycle events for this. In conclusion: the
only place you see analytics events in your codebase is in the Analytics
module.

To me, it's about separation of concerns most of the times, and about handy
event operators sometimes (e.g. [https://github.com/Reactive-
Extensions/RxJS/blob/master/doc/...](https://github.com/Reactive-
Extensions/RxJS/blob/master/doc/api/core/operators/debounce.md)).

------
skrebbel
Wow, what an aggressive way to promote your own little open source app.

I fully agree: of course React gets a lot wrong, being a pioneer and all. The
way JS often goes, I bet one of the many alternatives that pop up actually
will turn out like something. But attacking it like that isn't going to get
you many friends.

~~~
Kiro
> Wow, what an aggressive way to promote your own little open source app.

Yeah, makes me not want to try it. This guy should let someone else handle the
marketing.

~~~
toolz
Maybe his marketing strategy was to only draw in people who use technology
based on the merits of said technology and purposefully alienate the people
who need an emotional connection to be convinced?

I can certainly see the merits of trying to gain pragmatic mind share first
before the buzzword technology crowd joins in and makes things more
complicated.

~~~
mcintyre1994
> Reactive Programming is an Enlightened Path to Programming Utopia Yet to be
> Grokked By Mere Humans

Is this slide a joke I don't get? The whole presentation seems to focus on
terminology and buzzwords more than discussing merits as far as I can tell.

EDIT: The authors commented and I'm going to assume this is an example of
missing context.

------
zghst
> Testing worse, through DOM

If you're writing proper tests for React, you don't test directly through the
DOM. Using Jest you can mock the DOM to test parts of your component. In my
view, a component should not contain everything, only the most essential parts
to get a working example of how it functions. Reusable/general functionality
is pulled in from mixins or other js modules, which should be testable,
without the structure of React, on its own.

> Cannot have post processing steps

This is incorrect, you can create a post processing step in React with a
parent component. I used this for a pointer events polyfill in React where it
replaces `onPointerEvent` with the appropriate mouse or touch event on a child
component.

> Cannot delay rendering after state/props change

You can delay a render by returning false from shouldComponentUpdate, and when
you get to the point where you want to render you can use this.forceUpdate().

That being said, React is somewhat misleading as far as Reactive programming
goes.

------
dyadic
I see a lot of misappropriation of terminology (in this case, "reactive") in
libraries and documentation. But unfortunately this is something that has been
going on for a long time and it's an impossible task to stop and, check and
verify everything that is released.

However, if this is the case, then the criticism here against React shouldn't
be that they're not reactive, but that they've used "reactive" wrong in their
documentation.

Like other commentors, I also don't like the message in the slides and do not
think that criticizing a competitor is a good form of marketing. But, I do
think we should remember that it's hard to get the full context from slides
and to not judge too quickly.

------
ryanackley
He implies that Grunt is dead on the first slide. Well don't I feel stupid
since I still use it. I guess it's not cool anymore? I missed the memo. Wait,
maybe I'm not cool? What do the cool kids use now instead of Grunt?

~~~
ep103
Seriously, is no one using Grunt? I know there was a backlash at all the Grunt
like tools that came out at the time, but I assumed it was still useful and
regularly in use / updated.

~~~
91bananas
We/I still use Grunt every day, works quite nicely to build two separate apps,
provides us with a very solid dev environment with livereload.

------
tel
React always feels to me to big a huge compromise between a nice statefree
dataflow solution for UIs and "getting Javascripters en masse to actually use
the damn thing". The entire existence of the state API is a highly visible
example of this.

It reminds me a lot of Gabriel's divide between the New Jersey approach versus
the MIT approach---React is far more viral in its current form, but better
technology certain lives further down the path.

I went to the Boston React meetup a few nights ago to hear Pete Hunt speak
about React. He was a wonderful speaker and described nicely how React learned
some of the same lessons that REST did making it superior to basic message
passing and bloated/leaky distributed object mechanisms (blech). He also
projected a very pragmatic POV from the React dev team---they want things to
be right, but they also want things to be functional in the perspective of the
way most applications are built today.

I was eager and jumped on some of the problems he suggested the React time was
facing trying to integrate something like animation into React. At this point
we jump from a sequence of instantaneous updates to a more game-like
continuous redraw effort. Pete mentioned that the current effort here was to
try to use technology like RxJS observers to get more reactivity and this
seems aligned with the OP here.

Personally, I think animation lives most nicely in the domain of continuous
time, "true" FRP which is mostly ignored by the current wave of Javascript FRP
libraries. Perhaps for good reason since most modern implementations ideas of
(again, "true") FRP are challenging to implement efficiently and the semantic
model is probably far too large (Zeno processes, difficulty with infinitesimal
delay).

But the advantage of FRP is that you can specify things like animation
independently of the icky details like event passing and sampling rate and let
those be determined at a later time when your FRP eDSL gets compiled into a
more refined event-passing network. In other words, FRP languages hide a vast
number of irrelevant and muddying details in a way that has a consistent
denotation and can (perhaps!) be compiled efficiently into a push/pull message
passing network.

~~~
seanmcdirmid
If you only care about animation, why not just use a constraint solver like a
physics engine? Time step is set st run-time, constraints are quite natural
(springs to pull something in). Constraint programming provides the
declarative data binding feel of FRP behaviors (someone on my committee
pointed that out). What you don't get with constraint systems are event
streams, but that isn't so useful for UI programming anyways.

We had this discussion a while back:

[http://lambda-the-ultimate.org/node/2913](http://lambda-the-
ultimate.org/node/2913)

~~~
tel
I think that's a really great idea, too. The worrisome bit around constraint
solvers is that they're really easy to get into strange "spooky action at a
distance" states of constraint interaction which are incredibly tough to
escape from. Building good constraints thus feels like something of a black
art.

~~~
seanmcdirmid
Sticking to Newtonian rather than using quantum physics can avoid the spooky
action at a distance problem (I know this isn't what you meant, but I couldn't
resist).

Actually, constraints are quite explicit compared to imperative assignments.

~~~
tel
Ha, and I had to speak of it that way for the same reason.

I believe that constraints are explicit, but their cumulative effect is
difficult to predict. A constraint which wipes out some part of the feasible
space with lots of vertices can have sudden and dramatic (non-local) impact on
the solution. If your solver is approximate or your solution non-linear it
might be incredibly difficult to figure out where the solver will ultimately
land.

~~~
seanmcdirmid
I have found Verlet integration with an implicit velocity to be really good in
this regard. It doesn't conserve energy very well, but it is very easy to work
with (predictable) when doing animations since constraints are expressed by
updating particle positions directly. I wrote a half baked paper on this once:

[http://research.microsoft.com/pubs/191705/uiphysics09.pdf](http://research.microsoft.com/pubs/191705/uiphysics09.pdf)

~~~
tel
I'll take a look; thanks!

------
snarfy
Don't break the web with your presentation framework.

Since you do, I cannot take anything you say about web development seriously.

~~~
delinka
I had to read your comment to understand that there was more content than the
title. Indeed I wish people would stop breaking the web is all the myriad ways
that they do.

~~~
totallymike
The whole web? It's all broken now? Better get a broom...

------
jackhoy
I've had very good experiences with React over the last year but was curious
to find out what the community thought of the criticism here and if anyone has
experience with the alternative promoted [https://github.com/Matt-
Esch/virtual-dom](https://github.com/Matt-Esch/virtual-dom)

------
Infinitesimus
All this links to is a page that does nothing (tested on FF and Chrome). Is
there a point this is trying to make? The link itself is meaningless. If I am
missing something, kindly let me know...

~~~
keeran
It's built in some presentation framework that requires you to press spacebar
to progress.

Annoying :)

~~~
Infinitesimus
Thank you! It would be very useful to have a simple "use arrow keys to
navigate" text somewhere on the page. Just noticed that there's a "next" arrow
visual indicator at the bottom right (not very visible due to color choices)

------
ogig
Meteor should be metioned here. It embraces both virtual dom and reactivity
[1]. When FRP, Angular, Ember or React are talked about I always feel Meteor
is unfairly treated and underrepresented. Meteor imperative style and the
patterns it provides are a joy to work with. If you are interested into FRP
from a web development perspective Meteor is a good framework to experiment
with.

[1]
[http://docs.meteor.com/#/full/reactivity](http://docs.meteor.com/#/full/reactivity)

------
coding4all
Clearly the author has never heard of ClojureScript's Om.

~~~
hackerboos
How does Om not suffer from the same problems? It's just an Clojurescript
interface to React.

~~~
jeremiep
Om is not an interface to React but rather React is the backend to Om.

I wouldn't use React out of the box, for pretty much the very same reasons
outlined in the slides.

~~~
hackerboos
Quoting the github README:

 _Om: A ClojureScript interface to Facebook 's React._

------
mjohn
Interesting, I've been playing with React/Flux a bit lately. I enjoy them more
than other JS frameworks, but agree it doesn't feel like it's quite right yet.

This blog post from the same author gives a bit more detail than the
presentation slides: [http://futurice.com/blog/reactive-mvc-and-the-virtual-
dom](http://futurice.com/blog/reactive-mvc-and-the-virtual-dom)

Looking forward to seeing the presentation video

------
jcromartie
A note in the title would help people know that this is a reveal.js
presentation, and you need to hit space/arrow/pagedown to continue.

------
grandalf
Hey everyone, don't get carried away by the tone of the slides. There is some
good stuff in there.

------
aikah
> React sucks

If it sucked nobody would be using it.

~~~
rjberry
PHP is pretty popular ...

~~~
aikah
PHP isn't a javascript framework.

~~~
rjberry
Not sure how that's relevant.

Anyway it's a logical fallacy "appeal to popularity".

------
dsego
I was about to start a small hobby project with kefir.js and react. Looks like
I need to take a look a this too. Anybody have any experience with FRP libs?
How do RxJS, lazy.js, bacon.js, kefir.js and others compare?

------
Kiro
Don't Cycle.

------
poseid
it often depends on the size of your team or projects, if a certain technology
makes sense. would be interesting to hear more about projects that "failed"
with React. So far, I have not heard many people who failed.

------
arcosdev
So...is he basically saying it should be more like Angular?

------
kuni-toko-tachi
People are really missing the point here. Follow staltz on twitter, he really
knows his stuff. React is very good, however it missing a few key things that
would make it awesome and more consistent - namely compositional event
processing. Where React falls short from perfect is by using imperative code
for its lifecycle functions.

He's not bashing React, he's educating you about an even better way. If you
care about frontend development it would be wise to pay attention.

~~~
aikah
> He's not bashing React

I quote him

> React sucks

How do you call it? a constructive criticism ?

~~~
kuni-toko-tachi
If you look at the source code of React vs Mercury you might agree with him.
Sucks is a strong word, however.

He's passionate about this stuff because there is a very simple mathematics to
frontend development (both declarative UI and immutable state as a function of
mutational events) that has been hiding in academic papers and haskell minds
that is now coming to the forefront.

There is a better way, and it can reasoned about much better than other
approaches.

~~~
crossre
You mean jQuery I suppose?

~~~
kuni-toko-tachi
Not even the same things. I love React, use it everyday, however from a
denotional semantic standpoint it is impure.

view m0 = r0

view (m1 = handler e0 m0) = r1

view (m2 = handler e1 m1) = r2

This is the essence of MVC. Mathematically pure and beautiful.

React and Flux are so close to this conceptually, but fall far short of it in
actuality.

View is a function of state. State is an argument to view, and should not be
mated to view in any other way except as a function call argument to the view
- point free preferably.

If you look at the source code of React, there is an important object called
Transaction. Transaction is basically AOP. AOP is not needed in JavaScript!
Transaction reinvents functional composition. That is why things like Mercury,
Mithrill, and Cycle are better,smaller, easier to read and reason about.

I love React, but it is a gateway to an even brighter future. Rejoice that the
days of blind monkeys (myself included) writing UI code is coming to an end.

~~~
crossre
Yes exactly, just keep the state in css classes and html forms and tool
yourself for reuse.

------
kuni-toko-tachi
Instead of the down voting nonsense, read this:

[http://computationallyendowed.com/blog/2014/07/20/reactive-m...](http://computationallyendowed.com/blog/2014/07/20/reactive-
mvc.html)

Basically: view m0 = r0 view (m1 = handler e0 m0) = r1 view (m2 = handler e1
m1) = r2

Or just down vote and learn nothing.

~~~
colinramsay
"Basically"? I'm finding it difficult to answer your post with anything other
than incredulity. Either way this post doesn't negate the fact that the
attitude presented in the OP pretty much stinks.

~~~
kuni-toko-tachi
Christ almighty, this is pathetic. Did you read the link?

~~~
colinramsay
Yes. Does it negate the bad attitude of the OP's presentation (no)? An
attitude that you seem to share?

