Don't React (Presentation - Use arrows to navigate)

by jackhoy • 12 years ago

86 99 12 years ago

poseid• 12 years ago

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.

Infinitesimus2• 12 years ago

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• 12 years ago

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

Annoying :)

Infinitesimus2• 12 years ago

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)

kyberias• 12 years ago

It's the first slide of the slidedeck you're looking at. Press right arrow or find the link at the bottom-right of the page.

clinth• 12 years ago

It's a slideshow, probably intended to accompany a presentation. I used my right and left arrow keys to navigate.

davidy1232• 12 years ago

Always view source. (=

coldtea3• 12 years ago

It has an increased barrier to entry to sort out those capable of reading it -- namely, being familiar with web slideshows and knowing to press the right arrow...

F_Catalan• 12 years ago

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.

jcromartie2• 12 years ago

This is precisely my experience. It might have a slightly odd API, but React is an extremely sharp tool to have in your toolbox.

marrs2• 12 years ago

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.

yogthos2• 12 years ago

If you feel adventurous give Reagent http://reagent-project.github.io/ a shot. :)

conqrr• 12 years ago

I agree to the React bit. I have been trying to get past building Todo apps with Angular and Ember but didnt succeed. React somehow seemed more natural and easier to grasp the whole concept rather than the complex stuff and steep learning curve of Angular.

snarfy• 12 years ago

Don't break the web with your presentation framework.

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

delinka• 12 years ago

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• 12 years ago

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

jcromartie2• 12 years ago

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.

skrebbel• 12 years ago

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.

Kiro3• 12 years ago

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• 12 years ago

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.

jackhoy• 12 years ago

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

danr42• 12 years ago

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.

Kiro3• 12 years ago

He makes a weak case by focusing on the terminology. Quibble if you ask me.

kuni-toko-tachi8• 12 years ago

Its not hairsplitting, maybe you read the FRP papers by Conal Eliot.

kuni-toko-tachi8• 12 years ago

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.

davidy1232• 12 years ago

When do the academic implementations become successful? Rarely. The practical ones do, that use the important ideas and make them palatable. Usually the academic versions require one giant step off what people ever want to do. In the presentation, code goes off the direct path with intermediary objects. React's component approach is straightforward. The presentation fails to make a straightforward case of why its concepts are important. It just sounds petulant.

SeoxyS• 12 years ago

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

danr42• 12 years ago

I've been following the "virtual-dom movement" since I started using React, which is a few months by now, including Mercury, Mithril and it's not the first time I run into Cycle. I agree they are taking these ideas further and actually am excited about the progress they are making, but the approach of "Don't Use This" and "Actually you are wrong", and "Those days are over" does not serve their cause.

Kiro3• 12 years ago

Don't Cycle.

kuni-toko-tachi8• 12 years ago

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.

aikah3• 12 years ago

He's not bashing React

I quote him

React sucks

How do you call it? a constructive criticism ?

kuni-toko-tachi8• 12 years ago

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.

robteix• 12 years ago

People are really missing the point here. Follow staltz on twitter, he really knows his stuff.

Whether he's brilliant on twitter or not is irrelevant. People are judging the presentation. Even if he's the most brilliant mind in the 21st century, that doesn't shield his work from scrutiny.

marrs2• 12 years ago

Not bashing React? Are we reading different presentations?

btown• 12 years ago

The interesting thing about React is that it's not at all incompatible with compositional event processing and true FRP. All it requires is that there be some concept of a "store" whose changes can be subscribed to, and the view and its children update automatically. That "store" can be a huge imperatively-driven series of Backbone.Collections, or it can simply be the end of a chain of compositional events using whatever structure or programming model you want. In many ways, it's a way for an application to decouple its view logic from its choice of event processing model. So you can start with a very simple view structure, and then with minimal refactoring you can swap out your event processing model for FRP as you need it. And it doesn't require your programmers to start thinking about type systems and immutability at the very beginning.

Do I have some gripes with React's API? Sure. But it's a good start.

aikah3• 12 years ago

React sucks

If it sucked nobody would be using it.

rjberry2• 12 years ago

PHP is pretty popular ...

aikah3• 12 years ago

PHP isn't a javascript framework.

coldtea3• 12 years ago

If it sucked nobody would be using it.

Really? History is filled with stuff that sucks and people still use it.

As an example, J2EE circa 2002-2006 is a good example, with everybody, including its own designers agreeing now that it sucks hard. And yet it was widely used in the enterprise.

Your comeback to the other commenter is even more illogical. He points to PHP (as an example of something arguably sucky that people do use) and you respond that "PHP is not a Javascript framework".

So? Did you really meant your original statement ("If it sucked nobody would be using it") as something that only holds for JS frameworks (and not also for things like programming languages or libraries)?

ryanackley• 12 years ago

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?

arcosdev2• 12 years ago

Maybe they use Gulp. I don't even know anymore...

hackerboos3• 12 years ago

Broccoli, Gulp, Mimosa.

rralian• 12 years ago

We use make.

ep103• 12 years ago

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• 12 years ago

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.

dsissitka• 12 years ago

NPM downloads in the last month:

  Grunt: 812,465
  Gulp:  448,694

malkia• 12 years ago

I use sudo, at least it helps in the morning with breakfast.

tomconroy• 12 years ago

Make.

zghst3• 12 years ago

Can you post a link to a skeleton of a JS project using make? I'd like to look into this

zghst3• 12 years ago

We use webpack at my company and so does Instagram

staltz5• 12 years ago

npm scripts

arcosdev2• 12 years ago

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

kuni-toko-tachi8• 12 years ago

Instead of the down voting nonsense, read this:

http://computationallyendowed.com/blog/2014/07/20/reactive-m...

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

Or just down vote and learn nothing.

colinramsay3• 12 years ago

"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-tachi8• 12 years ago

Christ almighty, this is pathetic. Did you read the link?

dsego• 12 years ago

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?

coding4all3• 12 years ago

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

hackerboos3• 12 years ago

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

coding4all3• 12 years ago

https://gist.github.com/runexec/6efb322f29fc790a98a1

jeremiep2• 12 years ago

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.

Gonzih2• 12 years ago

I would suggest Reagent as a good example of simple API on to p of React

coding4all3• 12 years ago

Easier to learn doesn't quite mean "simple". I prefer Om not just because I took the time to learn it, but because it makes more sense once you do.

dyadic• 12 years ago

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.

tel4• 12 years ago

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.

kuni-toko-tachi8• 12 years ago

Excellent and well said.

seanmcdirmid3• 12 years ago

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

tel4• 12 years ago

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.

grandalf• 12 years ago

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

staltz5• 12 years ago

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.

lhorie3• 12 years ago

Do you have a link to the video?

staltz5• 12 years ago

Conference organizers will put it up and hopefully post it here: https://twitter.com/trewebdev

jarkko• 12 years ago

Hot off the oven: https://www.youtube.com/watch?v=9QObt0SGriI&feature=youtu.be

yogthos2• 12 years ago

I find that Reagent http://reagent-project.github.io/ addresses many of the issues. For example, all components can be described as simple data structures. Components communicate via atoms that notify components that their state changes. This means that two components retain control over their state and can decide how they wish to react to the change in the atom.

joelhooks• 12 years ago

The slides read great, and the concepts are important. It's something I'm personally intrigued by[1]. Very interested in Cycle and your experiments. Thanks!

[1] https://github.com/joelhooks/react-rxjs-angular-di-todomvc

ogig• 12 years ago

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

lhorie3• 12 years ago

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... ). 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• 12 years ago

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.

lhorie3• 12 years ago

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.

staltz5• 12 years ago

How does one go about doing non-string parameterized intents?

From yesterday, it's now possible to have stateful custom elements, as if they were Web Components: https://github.com/staltz/cycle/blob/fbae9c6610043ef6e46941a... This brings Cycle a bit closer to React, in that a "component" can handle its own events. The overall approach is still different than React, because in React you are encouraged to use components for anything, while custom elements exist in Cycle only when a pure component (i.e. a function returning a virtual DOM element, in React terms, props-only component) is not enough. Hence TodoMVC could be rewritten to use <todo> custom elements.

Using DOM attributes to register IDs is just one technique. Things are evolving fast, and I haven't myself tried to publish/share Cycle just yet, because it's not ready.

PS: I have a lot of respect for Mithril. Unfortunately not reactive as I would appreciate, but Mithril is very fast and very simple to understand.

zghst3• 12 years ago

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.

mjohn• 12 years ago

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

Looking forward to seeing the presentation video

Don't React (Presentation - Use arrows to navigate)

Related Stories