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.
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?!<p>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.<p>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.<p>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).<p>That's the thing about React, there's quite a diversity in approaches for handling data, events, user actions, etc.
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.
Disclaimer: I wrote Mithril (one of the vdom frameworks mentioned in the presentation)<p>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.<p>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.<p>@staltz WRT Cycle.js itself:<p>I took a look at the TodoMVC example and was surprised to see intents reading data from DOM element data attributes (e.g. <a href="https://github.com/staltz/todomvc-cycle/blob/master/js/intents/todos.js#L7-21" rel="nofollow">https://github.com/staltz/todomvc-cycle/blob/master/js/inten...</a> ). 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?
Wow, what an aggressive way to promote your own little open source app.<p>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.
> Testing worse, through DOM<p>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.<p>> Cannot have post processing steps<p>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.<p>> Cannot delay rendering after state/props change<p>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().<p>That being said, React is somewhat misleading as far as Reactive programming goes.
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.<p>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.<p>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.
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?
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.<p>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.<p>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.<p>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.<p>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).<p>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.
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 <a href="https://github.com/Matt-Esch/virtual-dom" rel="nofollow">https://github.com/Matt-Esch/virtual-dom</a>
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...
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.<p>[1] <a href="http://docs.meteor.com/#/full/reactivity" rel="nofollow">http://docs.meteor.com/#/full/reactivity</a>
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.<p>This blog post from the same author gives a bit more detail than the presentation slides: <a href="http://futurice.com/blog/reactive-mvc-and-the-virtual-dom" rel="nofollow">http://futurice.com/blog/reactive-mvc-and-the-virtual-dom</a><p>Looking forward to seeing the presentation video
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?
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.
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.<p>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.