8 ms·

Don't React

184 points by muraiki 12y ago

jaked89 12y ago
It's worth mentioning Elm, a (truly) functional-reactive language, based on virtual-DOM. http://elm-lang.org/ http://elm-lang.org/
- posnet 12y ago
  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).
- kodablah 12y ago
  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 https://github.com/lihaoyi/scala.rx 2 - https://github.com/lihaoyi/scalatags https://github.com/lihaoyi/scalatags 3 - https://github.com/rtimush/scalatags-rx https://github.com/rtimush/scalatags-rx 4 - https://github.com/japgolly/scalacss/ https://github.com/japgolly/scalacss/
bluetidepro 12y ago
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.
- wesleytodd 12y ago
  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.
- mbrock 12y ago
  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.
impostervt 12y ago
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.
- cseelus 12y ago
  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.
- ryannevius 12y ago
  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.
  - S4M 12y ago
    Yeah, I had to read the source code of the page to understand it was actually a presentation.
  - adamb_ 12y ago
    This is a standard reveal.js presentation: https://github.com/hakimel/reveal.js https://github.com/hakimel/reveal.js
  - Bahamut 12y ago
    The background and/or color palettes made for a bad combination here.
- mcmillion 12y ago
  Space seems to work as well. I love it when a page telling you not to use something fails at UX.
  - untog 12y ago
    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.
ryannevius 12y ago
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 https://github.com/staltz/cycle
- ctdonath 12y ago
  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.
  - andrewmutz 12y ago
    The presentation from OP is difficult to use. Press the triangle in the lower right of the page, or the right arrow key.
jasode 12y ago
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 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.)
- tinganho 12y ago
  The button was maybe created that way so people won't react.
ebbv 12y ago
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.
- bshimmin 12y ago
  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 https://github.com/staltz/todomvc-cycle
grandalf 12y ago
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.
danesparza 12y ago
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/ https://facebook.github.io/react/ ... and they have nothing to do with reactive programming.
- muraiki 12y ago
  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 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/ 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. :(
- waltfy 12y ago
  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 http://waltfy.net/2015/04/01/one-reason-to-use-react.html
- kaonashi 12y ago
  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.
jt2190 12y ago
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
- jt2190 12y ago
  And the viedo of the presentation: https://youtu.be/9QObt0SGriI https://youtu.be/9QObt0SGriI
muraiki 12y ago
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/ http://jsfiddle.net/nmd88wum/
DigitalSea 12y ago
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.
- toddmatthews 12y ago
  typo: Facebook ARE dogfooding
jacques_chester 12y ago
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.
Termina1 12y ago
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.
- Termina1 12y ago
  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.
- tonyhb 12y ago
  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.
- dominotw 12y ago
  >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.
  - itsbits 12y ago
    I agree that maintaining external plugins is pain in React..but still there are ways you can manage them in React..
  - Termina1 12y ago
ryanackley 12y ago
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 https://news.ycombinator.com/item?id=8819115
augustl 12y ago
I just want to say that this is the definition of "reactive" is amazing! Now I finally understand what "reactive" actually means.
ww520 12y ago
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.
dabernathy89 12y ago
Do people really consider Grunt dead?
- fro 12y ago
  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.
- ohitsdom 12y ago
  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.
  - gcz92 12y ago
    Maybe the author meant that there is a lean towards gulp over grunt? Not sure. but my company still uses grunt in production
  - hackerboos 12y ago
    There are few JS builders these days - Broccoli, Gulp, Brunch, Cake, Gobble...
gcz92 12y ago
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.
- empthought 12y ago
  Appcelerator Titanium says "Hi. Must be nice to just coast on hype without any product support investment or proven track record."
  - untog 12y ago
    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.
  - zak_mc_kracken 12y ago
    Xamarin says 'sup?'.
- joshuacc 12y ago
  Depending on what you mean by "that compatibility," Ionic (mobile app framework built on Angular), might count.
neovive 12y ago
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.
- posnet 12y ago
  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.
- thegreatpeter 12y ago
  You should learn Javascript
TheCoelacanth 12y ago
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.
jlongster 12y ago
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 https://github.com/omcljs/om). React is a platform (https://www.youtube.com/watch?v=5hGHdETNteE 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 https://github.com/gaearon/react-dnd). EDIT: Apparently, this presentation was tongue-in-cheek (https://news.ycombinator.com/item?id=9316187 https://news.ycombinator.com/item?id=9316187), which totally changes everything. I hate just seeing the slides!
- Bahamut 12y ago
  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.
  - jlongster 12y ago
    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.
kyled 12y ago
No delayed rendering? Isn't the programmer responsible for telling react when to render?
ndreckshage 12y ago
Blanket statement: anyone that makes blanket statements like 'React sucks' or 'Ember sucks' should not be taken seriously.
- hackerboos 12y ago
  OP backs up his statement with examples. 'React sucks' (because there are better ways to do this) was the conclusion of the presentation.
acdlite 12y ago
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 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-%20Reduce%20State/01%20-%20Declarative%20Component%20Module.js https://github.com/reactjs/react-future/blob/master/09%20-%2...
tehcodez 12y ago
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.
mrspeaker 12y ago
Can we change the link to the video instead of the slide deck? https://www.youtube.com/watch?v=9QObt0SGriI&feature=youtu.be https://www.youtube.com/watch?v=9QObt0SGriI&feature=youtu.be Slide decks are (mostly) meaningless without context.
beefsack 12y ago
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
robmclarty 12y ago
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 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.
staltz 12y ago
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-matters/ 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 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 https://github.com/facebook/react/issues/3398 and https://twitter.com/sebmarkbage/status/543660526908088320 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 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 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 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.
- EugeneOZ 12y ago
  Well, not sure about first point. We already have FlightJS (https://flightjs.github.io/ https://flightjs.github.io/) couple of years, which is event-driven also (even templates looks similar to React UI).
  - 12y ago
reactor 12y ago
"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.
deleted 12y ago
[deleted]
dwg 12y ago
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.
- balls187 12y ago
  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?
  - woah 12y ago
    You can actually do a lot of that stuff with JavaScript, it turns out.
    - EugeneOZ 12y ago
      yeah, let's be cool guys to the end and use VanillaJS only.
    - balls187 12y ago
      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.
deleted 12y ago
[deleted]
nwienert 12y ago
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 https://www.youtube.com/watch?v=FALQU-pVKJo [0] https://github.com/facebook/react/issues/3398 https://github.com/facebook/react/issues/3398 [1] https://github.com/reapp/reapp-kit https://github.com/reapp/reapp-kit [2] https://www.tildedave.com/2014/11/15/introduction-to-contexts-in-react-js.html https://www.tildedave.com/2014/11/15/introduction-to-context...
- woah 12y ago
  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?
  - nwienert 12y ago
    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.
deleted 12y ago
[deleted]
nogridbag 12y ago
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: 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; } If for some reason I was feeling crazy and I wanted the store to handle a second Ajax call, the store code becomes much more cumbersome so I avoid 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: 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; }
- balls187 12y ago
  > 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).
EugeneOZ 12y ago
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.
deleted 12y ago
[deleted]

184 points by muraiki 12y ago

It's worth mentioning Elm, a (truly) functional-reactive language, based on virtual-DOM. http://elm-lang.org/ http://elm-lang.org/

posnet 12y ago
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).
kodablah 12y ago
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 https://github.com/lihaoyi/scala.rx 2 - https://github.com/lihaoyi/scalatags https://github.com/lihaoyi/scalatags 3 - https://github.com/rtimush/scalatags-rx https://github.com/rtimush/scalatags-rx 4 - https://github.com/japgolly/scalacss/ https://github.com/japgolly/scalacss/

bluetidepro 12y ago

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.

wesleytodd 12y ago
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.
mbrock 12y ago
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.

impostervt 12y ago

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.

cseelus 12y ago
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.
ryannevius 12y ago
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.
- S4M 12y ago
  Yeah, I had to read the source code of the page to understand it was actually a presentation.
- adamb_ 12y ago
  This is a standard reveal.js presentation: https://github.com/hakimel/reveal.js https://github.com/hakimel/reveal.js
- Bahamut 12y ago
  The background and/or color palettes made for a bad combination here.
mcmillion 12y ago
Space seems to work as well. I love it when a page telling you not to use something fails at UX.
- untog 12y ago
  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.

ryannevius 12y ago

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 https://github.com/staltz/cycle

ctdonath 12y ago
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.
- andrewmutz 12y ago
  The presentation from OP is difficult to use. Press the triangle in the lower right of the page, or the right arrow key.

jasode 12y ago

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 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.)

tinganho 12y ago
The button was maybe created that way so people won't react.

ebbv 12y ago

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.

bshimmin 12y ago
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 https://github.com/staltz/todomvc-cycle

grandalf 12y ago

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.

danesparza 12y ago

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/ https://facebook.github.io/react/ ... and they have nothing to do with reactive programming.

muraiki 12y ago
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 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/ 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. :(
waltfy 12y ago
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 http://waltfy.net/2015/04/01/one-reason-to-use-react.html
kaonashi 12y ago
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.

jt2190 12y ago

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

jt2190 12y ago
And the viedo of the presentation: https://youtu.be/9QObt0SGriI https://youtu.be/9QObt0SGriI

muraiki 12y ago

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/ http://jsfiddle.net/nmd88wum/

DigitalSea 12y ago

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.

toddmatthews 12y ago
typo: Facebook ARE dogfooding

jacques_chester 12y ago

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.

Termina1 12y ago

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.

Termina1 12y ago
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.
tonyhb 12y ago
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.
dominotw 12y ago
>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.
- itsbits 12y ago
  I agree that maintaining external plugins is pain in React..but still there are ways you can manage them in React..
- Termina1 12y ago

ryanackley 12y ago

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 https://news.ycombinator.com/item?id=8819115

augustl 12y ago

I just want to say that this is the definition of "reactive" is amazing! Now I finally understand what "reactive" actually means.

ww520 12y ago

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.

dabernathy89 12y ago

Do people really consider Grunt dead?

fro 12y ago
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.
ohitsdom 12y ago
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.
- gcz92 12y ago
  Maybe the author meant that there is a lean towards gulp over grunt? Not sure. but my company still uses grunt in production
- hackerboos 12y ago
  There are few JS builders these days - Broccoli, Gulp, Brunch, Cake, Gobble...

gcz92 12y ago

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.

empthought 12y ago
Appcelerator Titanium says "Hi. Must be nice to just coast on hype without any product support investment or proven track record."
- untog 12y ago
  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.
- zak_mc_kracken 12y ago
  Xamarin says 'sup?'.
joshuacc 12y ago
Depending on what you mean by "that compatibility," Ionic (mobile app framework built on Angular), might count.

neovive 12y ago

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.

posnet 12y ago
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.
thegreatpeter 12y ago
You should learn Javascript

TheCoelacanth 12y ago

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.

jlongster 12y ago

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 https://github.com/omcljs/om). React is a platform (https://www.youtube.com/watch?v=5hGHdETNteE 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 https://github.com/gaearon/react-dnd). EDIT: Apparently, this presentation was tongue-in-cheek (https://news.ycombinator.com/item?id=9316187 https://news.ycombinator.com/item?id=9316187), which totally changes everything. I hate just seeing the slides!

Bahamut 12y ago
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.
- jlongster 12y ago
  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.

kyled 12y ago

No delayed rendering? Isn't the programmer responsible for telling react when to render?

ndreckshage 12y ago

Blanket statement: anyone that makes blanket statements like 'React sucks' or 'Ember sucks' should not be taken seriously.

hackerboos 12y ago
OP backs up his statement with examples. 'React sucks' (because there are better ways to do this) was the conclusion of the presentation.

acdlite 12y ago

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 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-%20Reduce%20State/01%20-%20Declarative%20Component%20Module.js https://github.com/reactjs/react-future/blob/master/09%20-%2...

tehcodez 12y ago

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.

mrspeaker 12y ago

Can we change the link to the video instead of the slide deck? https://www.youtube.com/watch?v=9QObt0SGriI&feature=youtu.be https://www.youtube.com/watch?v=9QObt0SGriI&feature=youtu.be Slide decks are (mostly) meaningless without context.

beefsack 12y ago

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

robmclarty 12y ago

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 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.

staltz 12y ago

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-matters/ 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 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 https://github.com/facebook/react/issues/3398 and https://twitter.com/sebmarkbage/status/543660526908088320 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 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 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 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.

EugeneOZ 12y ago
Well, not sure about first point. We already have FlightJS (https://flightjs.github.io/ https://flightjs.github.io/) couple of years, which is event-driven also (even templates looks similar to React UI).
- 12y ago

reactor 12y ago

"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.

deleted 12y ago

[deleted]

dwg 12y ago

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.

balls187 12y ago
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?
- woah 12y ago
  You can actually do a lot of that stuff with JavaScript, it turns out.
  - EugeneOZ 12y ago
    yeah, let's be cool guys to the end and use VanillaJS only.
  - balls187 12y ago
    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.

deleted 12y ago

[deleted]

nwienert 12y ago

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 https://www.youtube.com/watch?v=FALQU-pVKJo [0] https://github.com/facebook/react/issues/3398 https://github.com/facebook/react/issues/3398 [1] https://github.com/reapp/reapp-kit https://github.com/reapp/reapp-kit [2] https://www.tildedave.com/2014/11/15/introduction-to-contexts-in-react-js.html https://www.tildedave.com/2014/11/15/introduction-to-context...

woah 12y ago
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?
- nwienert 12y ago
  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.

deleted 12y ago

[deleted]

nogridbag 12y ago

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: 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; } If for some reason I was feeling crazy and I wanted the store to handle a second Ajax call, the store code becomes much more cumbersome so I avoid 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: 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; }

balls187 12y ago
> 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).

EugeneOZ 12y ago

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.

deleted 12y ago

[deleted]