Don't React

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

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/

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

Agreed. Although I do think that React is "borrowing" concepts from FRP, definitely. Funny how he points the VirtualDOM as if that's THE reason why React is good. It is not. I wrote about why I think you should use React here: http://waltfy.net/2015/04/01/one-reason-to-use-react.html

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.

Can you explain what you mean by "these types of frameworks" - do you mean the lighter approach that React takes with purely dominating the view and leaving the rest to the developer?

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

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