Don't React(staltz.com)
staltz.com
Don't React
http://staltz.com/dont-react/
130 comments
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
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.
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.
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?
What did you use to manage state, data flow, communication to servers, etc?
Used refluxjs for data flow. Inside the stores, superagent is used for request handling. React-router was used for routing.
Once I finally grok'd the implementations of Flux, I found the it to be a decent layer ontop of ReactJS.
Of the implementations of Flux, Reflux is pretty good, with less hassle of a centralized dispatcher, and extra boilerplate.
What I don't get is that the `trigger` is essentially a store created action, which goes against the unidirectional data flow model.
Of the implementations of Flux, Reflux is pretty good, with less hassle of a centralized dispatcher, and extra boilerplate.
What I don't get is that the `trigger` is essentially a store created action, which goes against the unidirectional data flow model.
I definitely found Reflux to be more understandable and easier to put into practice than Flux in general. They trade-off some purity and flexibility for simplicity.
That said the stores and trigger method are definitely one of the rougher areas in the app. Thinking back, the stores were probably the largest source of bugs, but they also contain more logic so it's reasonable to assume they would have higher bug density.
Reflux was a great stepping stone, but this is the area I would most like to refactor and/or spend more time on in future projects. Fortunately there's a lot of interesting work going on in this area right now.
That said the stores and trigger method are definitely one of the rougher areas in the app. Thinking back, the stores were probably the largest source of bugs, but they also contain more logic so it's reasonable to assume they would have higher bug density.
Reflux was a great stepping stone, but this is the area I would most like to refactor and/or spend more time on in future projects. Fortunately there's a lot of interesting work going on in this area right now.
You can actually do a lot of that stuff with JavaScript, it turns out.
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.
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.
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.
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.
yeah, let's be cool guys to the end and use VanillaJS only.
It's worth mentioning that this was not an issue the author even brought up, I assume since React doesn't claim to handle any of these other concerns in an application. Saying React doesn't handle these functions is like complaining about a screwdriver not being able to hammer a nail very well.
It's also worth noting that this sub-thread is in response to another commenter, not the original article.
"Other frameworks", but React is not a framework, just UI lib :) Sorry to be pedantic, but framework gives much more often.
Quite alright—I'm usually very precise on these matters as well.
Nonetheless I disagree with the point. My opinion after actually having used React.js is that it is more than a UI library. I've used other UI libraries and React.js is more "comprehensive." I do grant, however, that React.js alone will not suit most needs. You will generally want to add a few other pieces. In my case I also used refluxjs and react-router. I also used store.js as an abstraction for browser storage.
Nonetheless I disagree with the point. My opinion after actually having used React.js is that it is more than a UI library. I've used other UI libraries and React.js is more "comprehensive." I do grant, however, that React.js alone will not suit most needs. You will generally want to add a few other pieces. In my case I also used refluxjs and react-router. I also used store.js as an abstraction for browser storage.
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/ ... and they have nothing to do with reactive programming.
The React team clearly states their design goals here: https://facebook.github.io/react/ ... and they have nothing to do with reactive programming.
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. :(
"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. :(
React doesn't try to do 'Reactive' programming structures; it does a view layer that's composable.
How that data gets into the components is your responsibility; you can easily use something like Baconjs/RxJS to do this.
How that data gets into the components is your responsibility; you can easily use something like Baconjs/RxJS to do this.
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
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.
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.
EDIT: This apparently wasn't intended to be navigated by the general public, as explained by a comment below.
Yeah, I had to read the source code of the page to understand it was actually a presentation.
This is a standard reveal.js presentation: https://github.com/hakimel/reveal.js
The background and/or color palettes made for a bad combination here.
Space seems to work as well.
I love it when a page telling you not to use something fails at UX.
I love it when a page telling you not to use something fails at UX.
It doesn't fail at UX - it's intended to be a presentation manually controlled by the presenter. Just because someone posted a link to Hacker News doesn't mean the author intended for it to be here.
They did put it on the web.
Yes, and for all we know there is a page linking to it that says "Here's a link to my reveal.js presentation, just use the arrows to navigate"
Even if I had seen a message beforehand telling me "just use the arrows to navigate", I still wouldn't have found those arrows. Light gray on light green doesn't exactly stand out.
I put all my presentations on the web because Linux + projectors = sadness, and I often end up having to borrow someone else's laptop to give the talk.
And there was me thinking the page was not reacting.
Left and Right arrow key works as well.
I had to come here to see what's going on. Thanks.
Arrow keys work for navigation.
Thank you ... I thought this was an example of minimalist design (without flatness)!
After entering the presentation, arrow keys work too.
After entering the presentation, arrow keys work too.
After I refreshed it several times, I had to go back to this post and read comments. Luckily found this. Thank you!
[deleted]
Thanks, Title could be Don't react, don't design, don't UX.
I would assume this wasn't necessarily intended by the author for a broader web audience.
You can also easily navigate it with your cursor keys though.
You can also easily navigate it with your cursor keys though.
Didn't see that, but ended up eventually tapping the right arrow just to see if it would do anything and it went to the next slide.
Same here. At first I almost concluded it was some, uhm, "manifesto", which wouldn't need any arguments and all the folks except me know what it is about already.
I don't see any triangle!
wow, what horrible color choices. Totally missed it.
dhu... thanks
Scrolling didn't work, hitting right arrow did.
[deleted]
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). React is a platform (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).
EDIT: Apparently, this presentation was tongue-in-cheek (https://news.ycombinator.com/item?id=9316187), which totally changes everything. I hate just seeing the slides!
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). React is a platform (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).
EDIT: Apparently, this presentation was tongue-in-cheek (https://news.ycombinator.com/item?id=9316187), which totally changes everything. I hate just seeing the slides!
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.
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.
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.
There are other choices than just React. Many of your same points applies to [insert library/framework].
I think it is important to weigh criticisms just as much as praise. This lets the best ideas get vetted by the community and developers can focus their mindshare solving other important problems.
I think it is important to weigh criticisms just as much as praise. This lets the best ideas get vetted by the community and developers can focus their mindshare solving other important problems.
Sure, except React easily has the largest community yet (with these types of frameworks) so the argument doesn't really stand for other ones. There has to be really good to reasons to switch to something else completely, and really good reasons not to build on top of React.
It's definitely important to look at criticisms, but honestly, these aren't very good ones. It would have been easy to build his library on top of React.
EDIT: stronger criticisms in my opinions focus on how hard it can be to get started with an advanced app w/React compared to Ember, which takes a "bundle everything in" approach (the classic lib vs framework debate). Ember is a strong contender especially because it has a great community as well.
It's definitely important to look at criticisms, but honestly, these aren't very good ones. It would have been easy to build his library on top of React.
EDIT: stronger criticisms in my opinions focus on how hard it can be to get started with an advanced app w/React compared to Ember, which takes a "bundle everything in" approach (the classic lib vs framework debate). Ember is a strong contender especially because it has a great community as well.
[deleted]
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.
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.
>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.
On the one hand, yes, and on the other hand, I have never in practice had this happen when it was not my fault. I've also never had it be my fault unless I fell back on some old jQuery plugin or Google Maps or something that directly manipulates the DOM because I'm trying not to reinvent the wheel.
However, you can deal with these things gracefully by diligently recognizing these instances in which you, for one reason or another, need to directly manipulate the DOM. React's lifecycle methods like `componentDidMount`, `componentWillUpdate`, and `componentWillUnmount` are the place to deal with those kinds of issues.
It definitely takes you out of the React philosophy and forces you to manage your own state carefully. But that's generally confined to a single component, so if you get the component innards right, everything that calls it can be ignorant of the ugly stuff inside.
Unless you're talking about something else entirely that I've just been lucky to never encounter.
On the one hand, yes, and on the other hand, I have never in practice had this happen when it was not my fault. I've also never had it be my fault unless I fell back on some old jQuery plugin or Google Maps or something that directly manipulates the DOM because I'm trying not to reinvent the wheel.
However, you can deal with these things gracefully by diligently recognizing these instances in which you, for one reason or another, need to directly manipulate the DOM. React's lifecycle methods like `componentDidMount`, `componentWillUpdate`, and `componentWillUnmount` are the place to deal with those kinds of issues.
It definitely takes you out of the React philosophy and forces you to manage your own state carefully. But that's generally confined to a single component, so if you get the component innards right, everything that calls it can be ignorant of the ugly stuff inside.
Unless you're talking about something else entirely that I've just been lucky to never encounter.
For example, embedded FB post. In React you can deal with it using componentShouldUpdate and others. I don't know how to deal with it in virtual-dom (package), without going deep into patching algorithm.
Ah, my mistake. I didn't realize the distinction there. Makes more sense now.
Also, React goes with Flux, and Flux is a reactive architecture. So, if you treat React a separate module, the whole flux architecture is pretty reactive.
Yeah, I agree. It doesn't necessarily make React bad. And, after years of Backbone and Marionette, having an hierarchical structure in which parents "pass down" methods and data makes more sense than events, which can be hard to manage, test and visualise. And I really, really, really want to be able to visualise the structure and interactions between components when developing.
>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.
I can't think of a reason that someone would use react and still bypass it do their own dom modifications.
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)
I agree that maintaining external plugins is pain in React..but still there are ways you can manage them in React..
Sometimes you have no choice, in case of embeddable objects
> 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.
And you forgot fun.
And you forgot fun.
2x (it's --> its)
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
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.
The presentation from OP is difficult to use. Press the triangle in the lower right of the page, or the right arrow key.
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...
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...
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?
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.
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.
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
(I haven't seen the whole presentation so I can't comment if it's worthwhile to watch.)
The author used it that way here: 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.)
The button was maybe created that way so people won't react.
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.
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.
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
TodoMVC in Cycle is... intense: https://github.com/staltz/todomvc-cycle
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.
- 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.
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.
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.
I find it unreasonable that the author is getting flack for promoting his cycle.js. If he had just criticized react.js and offered no solution, everyone would be saying, "well, what am I supposed to do if I'm not supposed to use react?"
typo: Facebook ARE dogfooding
I prefer Facebook IS dogfooding. See http://www.economist.com/style-guide/singular-or-plural
I've noticed that here in the US we say "is" when referring to a company or group, and in other English-speaking countries they say "are", like in the UK.
I like to joke that it's because here in America, corporations are people too, you know.
I like to joke that it's because here in America, corporations are people too, you know.
[deleted]
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.
Also Reactive programming is more of having a declarative way to structure data flow so that changes can happen automatically, like a spreadsheet.
Blanket statement: anyone that makes blanket statements like 'React sucks' or 'Ember sucks' should not be taken seriously.
OP backs up his statement with examples. 'React sucks' (because there are better ways to do this) was the conclusion of the presentation.
It's worth mentioning Elm, a (truly) functional-reactive language, based on virtual-DOM.
http://elm-lang.org/
http://elm-lang.org/
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 2 - https://github.com/lihaoyi/scalatags 3 - https://github.com/rtimush/scalatags-rx 4 - https://github.com/japgolly/scalacss/
1 - https://github.com/lihaoyi/scala.rx 2 - https://github.com/lihaoyi/scalatags 3 - https://github.com/rtimush/scalatags-rx 4 - https://github.com/japgolly/scalacss/
I love elm, though even the author has stated that for the moment it is more of an experiment than anything else, until they can work out an elegant way to do data modelling (i.e. server communication).
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.
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.
You should learn Javascript
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.
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.
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.
I haven't formulated exactly why, but I think all this talk about "hype" is somewhat toxic, and if not toxic, then excruciatingly boring. Who cares? What do we gain by talking in such terms? As soon as a new thing arrives that people seem to enjoy using, is it a "hype train"? No—it's just people making decisions! That whole popularity contest discourse makes me enjoy Hacker News less, because I feel like my opinions will be interpreted in terms of imaginary hype.
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.
Appcelerator Titanium says "Hi. Must be nice to just coast on hype without any product support investment or proven track record."
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.
Xamarin says 'sup?'.
Depending on what you mean by "that compatibility," Ionic (mobile app framework built on Angular), might count.
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...
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), 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 and 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
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
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 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.
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...
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), 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 and 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
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
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 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.
Co-author of ReactRouter here.
With regards to #2, I used to think that a fully sync render function was a limitation of React, but have come to appreciate the fact that React tries to restrict its concerns to a very small, but significant piece. We've been working on solving the async data fetching use case in the router over the past few months, working with the Relay team as well, and we're starting to converge on some ideas and patterns that we think will help. But it's my personal opinion that sync render isn't a problem.
With regards to #2, I used to think that a fully sync render function was a limitation of React, but have come to appreciate the fact that React tries to restrict its concerns to a very small, but significant piece. We've been working on solving the async data fetching use case in the router over the past few months, working with the Relay team as well, and we're starting to converge on some ideas and patterns that we think will help. But it's my personal opinion that sync render isn't a problem.
I feel bad for my comment now. I got lured in the typical HN response. Sorry! I hate just seeing slides from a presentation.
Well, not sure about first point. We already have FlightJS (https://flightjs.github.io/) couple of years, which is event-driven also (even templates looks similar to React UI).
Flight is not like React at all. I see DOM manipulation all over the place in Flight examples.
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.
Do people really consider Grunt dead?
Yeah I don't get this. Just because there are popular alternatives doesn't mean there aren't tons of people for whom Grunt still works perfectly well.
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.
Maybe the author meant that there is a lean towards gulp over grunt? Not sure. but my company still uses grunt in production
There are few JS builders these days - Broccoli, Gulp, Brunch, Cake, Gobble...
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.
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.
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/
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/
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:
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:
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;
}
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;
}> 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).
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).
"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.
Its kinda make sense in this context.
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 Another (not sure if this counts, but I think it does): https://github.com/reactjs/react-future/blob/master/09%20-%2...
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 Another (not sure if this counts, but I think it does): https://github.com/reactjs/react-future/blob/master/09%20-%2...
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), 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.
I've built a few non-trivial apps with React this year (e.g., 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.
[deleted]
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.
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.
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
And the viedo of the presentation:
https://youtu.be/9QObt0SGriI
Can we change the link to the video instead of the slide deck? https://www.youtube.com/watch?v=9QObt0SGriI&feature=youtu.be
Slide decks are (mostly) meaningless without context.
Slide decks are (mostly) meaningless without context.
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.
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
[deleted]
I just want to say that this is the definition of "reactive" is amazing! Now I finally understand what "reactive" actually means.
No delayed rendering? Isn't the programmer responsible for telling react when to render?
[deleted]
[deleted]