17 ms·

React Makes You Sad?

288 points by danabramov 11y ago

joelcollinsdc 11y ago
There is an abundance of poorly written react apps popping up everywhere. Go to netflix and search for movies... the experience is terrible. The search box lags typing by a long shot. So much so its almost impossible to type in the full text of a movie name. I'm sure there is the correct way to do this (not making the field a controlled component?) but the problem being there on such a major site is a sign that its hard to do react correctly.
- jaegerpicker 11y ago
  I just went to netflix and it's not at all how you describe. It's incredibly fast and live filters as I type. There may be an abundance of poorly written react apps out there but netflix does not appear to be one.
  - joelcollinsdc 11y ago
    maybe i'm just typing too fast. I tried "the best marigold" (for the best marigold hotel). I watched the i in marigold disappear from the search box. Deleting the string (by holding down the delete key, the X works just fine) takes forever as well. I'm using chrome if it matters.
    - janpieterz 11y ago
      Just tested it and didn't find it super bad, but I am honestly (negatively) surprised. It does indeed lag quite a bit and feels very unnatural. Chrome here as well. I use React quite a bit myself and haven't experienced this in my own apps. Odd! There's also a slightly annoying flicker when you type the last bit and it keeps returning the same movies.
      - sushid 11y ago
        The slow text input problem is probably because they're updating their redux or flux store on every keypress.
        janpieterz 11y ago
        Something like that certainly plays it's role. I'm doing that as well for certain inputs and experience no lag at all, so it depends more on their implementation of the store. I think their search store is probably doing a lot more than mine (although, entering text, querying an API, processing response async). It seems like they could introduce some optimizations there.
vdnkh 11y ago
Everyone complaining about how React is just a trend is missing the point of React. It's not some revolutionary flash-in-the-pan technology based on a mystical black box, it's an aggregation of best practices that everyone (including yourself) has been clamoring to have implemented for years. Web components? Check. Object.Observer? Check. Virtual DOM? Check.
- kawera 11y ago
  Why not Web components directly? (genuinely interested, soon I'll have to chose one way or another for a new project)
  - vdnkh 11y ago
    They're still experimental. React handles a lot of the legwork towards getting proper web components today.
  - spankalee 11y ago
    I work on a web components library, so I'm very biased here, but web components will very soon have broad compatible support across all the major browser engines. It's the only interoperable solution going forward, because every framework out there right now is a silo unto itself.
    - kawera 11y ago
      Thanks, that's my understanding too. I've used Polymer in the past but before 1.0, will look at it again. No doubt web components are the future though, I only wonder if widespread browser support will be a reality in a 12-18 months timeframe.
- spankalee 11y ago
  React in no way implements Web Components. It doesn't create custom elements, period.
ajsharp 11y ago
Ah, of course, a flowchart! The CLASSIC path to understanding a library.
tylermauthe 11y ago
This is flipping brilliant!
gavi 11y ago
I am glad to be able to copy the links off the flowchart
ryannevius 11y ago
React made me sad, so I switched to Mithril[1]. Not only is it significantly smaller in size, but it's way faster and includes a router and AJAX methods out of the box. I wish more people would give it a shot. That said, I do still love React Native, and use React on a daily basis to take advantage of the "write once, run anywhere" paradigm. [1] https://lhorie.github.io/mithril/ https://lhorie.github.io/mithril/
- bcassedy 11y ago
  I've recently started playing with Mithril as well and I quite like it. I haven't used React or Mithril enough to speak confidently about the differences, but it seems Mithril offers everything React does and more with better performance and documentation.
- grinich 11y ago
  The React Native approach is actually "learn once, write anywhere." https://code.facebook.com/posts/1014532261909640/react-native-bringing-modern-web-techniques-to-mobile/ https://code.facebook.com/posts/1014532261909640/react-nativ...
  - coldtea 11y ago
    Those are just slogans, like Java's was. In practice you'll learn React Native once (1), learn some of each platform's intricacies (N), and sometimes need to debug (at most for each platform, so 0...N.
- bikamonki 11y ago
  Project seems abandoned, no?
  - timdorr 11y ago
    Looks active to me: https://github.com/lhorie/mithril.js/commits/next https://github.com/lhorie/mithril.js/commits/next
  - deleted 11y ago
    [deleted]
programminggeek 11y ago
Perhaps the answer is to not use React.
- dsp1234 11y ago
  FTA: Q: "Are you still sad?" A: "... Consider another stack that better suites[sic] your needs (eg. Ember)" The author has anticipated that react is not always the solution that is appropriate, and provided guidance in the case that react isn't actually a good fit for the project at hand.
- draw_down 11y ago
  Heck, why not just give up on trying to write software entirely? It's hard, and there's TV on.
gorkemyurt 11y ago
Please keep writing dan abramov! May I suggest turning some of your stackoverflow answers to longer essays/blog posts in an organized fashion like https://www.objc.io/issues/ https://www.objc.io/issues/
auggierose 11y ago
Lol. I found React interesting, too, but I don't like to read Javascript code, so I rolled my own React-like framework in Scala. Life is so much easier if you don't have to depend on other peoples mess.
- acjohnson55 11y ago
  Your comment would be helpful if it linked to something people could see, but otherwise, it just comes off as empty bragging, without a coherent critique. To me at least.
  - Confiks 11y ago
    I think publishing code would be in conflict with parent's message; by using your own hand-rolled mess, you at least don't have to depend on other people's mess. I must agree that my own mess is far more comprehensible that someone else's. Until Old Code Syndrome strikes, anyway.
- untog 11y ago
  Life is so much easier if you don't have to depend on other peoples mess. Future-you is going to look back on this comment and curse loudly.
  - auggierose 11y ago
    I am already future me as I did this about 1.5 years ago :-) The stuff is not open-source yet, but reading most of the comments here I wonder why anyone would want to open-source things? To meet the friendly people of HN? ;-)
- verisimilidude 11y ago
  ...where "other peoples mess" is based on battle-hardened production code from Facebook...
  - kec 11y ago
toosmart4u12 11y ago
The flow of that chart is so convoluted. No different from React I guess ;)
raziel2p 11y ago
Some of these are a bit dubious. "Are you using a bundler?" If yes: "try not using a bundler." If no: "try using a bundler." Same for flux/redux.
- tptacek 11y ago
  I think you've missed the point. The thesis of the flowchart isn't that there's just one way to build React programs, but rather that it's the opposite: one reason people get sad with React is that they cargo-cult things from other projects that aren't relevant to their own project, and another reason is that people are missing things from other projects that might help.
  - debacle 11y ago
    Using React without having a clear understanding of why is cargo-culting.
    - tptacek 11y ago
      I don't think that's true, or if it is, the first time you use any new tool you're probably cargo-culting.
- deleted 11y ago
  [deleted]
- vonklaus 11y ago
  I'm with tptacek here. I think the point is to try different things, especially for dif use cases. For learning, get a holistic view, for production consider X instead of Y. I found react to be really complicated and heretical personally. I don't like mixing languages, but if I do, I would like them to be tightly coupled. I have started to mess with vue.js which is really awesome. Even in as a meta point it would be like: > using vue.js? > give react a try again. It has changed a lot in 2 years.
- deleted 11y ago
  [deleted]
kruhft 11y ago
I've just started playing with React and my general opinion is that it's a very 'Facebook' project. Lots of restrictions on what you can do and when keeping all of the coders in line with what you're supposed to be doing and following the 'Facebook' way of programming. I'm sure it's great for writing traditional crud apps, but anything outside of the box that it wasn't intended is a major pain requiring major hacks just to get around it's ideas of data protection and timing. I'm sure there are plenty that like this rigidity, but for me, I'll pass.
- tptacek 11y ago
  This is the weirdest argument I've ever heard against React, and, as someone who does a fair bit of React work, I try to pay attention to all those arguments.
  - kruhft 11y ago
    Just my experience. Obviously not one that's common, but I was also doing something quite a bit different than most people that use it, I'm sure.
    - HeyImAlex 11y ago
      What were you doing?
      - kruhft 11y ago
        Writing a 'driver' to integrate my low level UI component library to be usable with React. My major issue was the 'rule' that a parent can't access the 'state' of it's children; this turned a 2 hour job into a 3 day job for me just trying to find a way to get access to this state through all of the lifecycle callbacks while instantiating children at the same time. When asked in #reactjs, they said that if you need access to a child's state you should put it into the parent, which makes sense but not in my case. There is a natural way of hiding working 'upwards' through the chain, but I can't say I've seen it ever work downwards like in React, and I found that rather frustrating and difficult to work around.
blainesch 11y ago
This feels like it builds off of the philosophy of not being a victim.. if you find a problem, just fix it. In these use cases, that is simple to do.
acjohnson55 11y ago
As someone who was almost immediately made happy by React, ES6, Redux, and boilerplates, I'm not the target audience. But I feel like this would make me un-sad if I felt overwhelmed by all the choices. I think the Redux guide itself (http://redux.js.org/ http://redux.js.org/) also does a fantastic job of a very gradual release into complexity. I recommend that anyone who feels they may want a Flux-like store read through the whole guide. It took me a day or two, but I found it to be extremely clear and enlightening.
- davej 11y ago
  Also, the free "Getting Started with Redux" video course: https://egghead.io/series/getting-started-with-redux https://egghead.io/series/getting-started-with-redux The approach taken in the videos is great because it starts off with implementing your own simplified version of Redux and builds on that. There are no "magic" steps, this makes it much easier to develop an understanding of how it works.
  - Klathmon 11y ago
    Just to throw another one in there, this github tutorial really helped it click for me: https://github.com/happypoulp/redux-tutorial/blob/master/00_introduction.js https://github.com/happypoulp/redux-tutorial/blob/master/00_... The rest of the tutorials left me feeling frustrated not really knowing why. This one i just breezed through.
    - merpnderp 11y ago
      Following the official redux tutorials left me and my boss independently frustrated and turned off by the app.js description. We had both given up on redux until I followed this tutorial and it explained how simple and elegant the way components received properties from the redux state in th connect call. Without this tutorial we wouldn't be experiencing the ease and joy redux can bring to large react apps (We're currently porting a large messy Angular app to react piece by piece by replacing just leafs of the app at a time)
draw_down 11y ago
This comment thread feels so barren, without a bunch of seasoned software professionals encountering JS build tools and immediately taking leave of their senses and declaring defeat.
et1337 11y ago
This reminds me of that Netflix talk on React [1]. In it, the guy first praises React to the heavens, then spends the rest of the session explaining all the ways they had to disable and work around React to get what they wanted with decent performance. It seemed to me like their use case could have been done with jQuery in a few hundred lines. Maybe I missed something. [1] https://www.youtube.com/watch?v=g01dGsKbXOk https://www.youtube.com/watch?v=g01dGsKbXOk
- igorgue 11y ago
  Nah you got the point, all these JavaScript frameworks are just over-engineering.
- deleted 11y ago
  [deleted]
- SonicSoul 11y ago
  just curious how you arrived at jQuery comparison. isn't that just a library for DOM utilities while react is a view engine optimized for minimum dom manipulation using observable pattern?
  - et1337 11y ago
    I made the comparison because at the beginning of the video, he talks about how they split into two teams; one used jQuery and the other React. Apparently the jQuery team moved significantly slower. I found that hard to believe given all the hacks they had to with React later on.
    - tiglionabbit 11y ago
      The React team was probably quicker at responding to the designers' ideas. The stuff that took a longer time was getting all the transition animations to work, which can be difficult in any higher-level framework.
  - qudat 11y ago
    jQuery and React are DOM manipulation libraries. jQuery packaged a bunch of other stuff in it but at its core it is all about DOM manipulation.
marcusr 11y ago
As a C and then a Ruby on Rails programmer, I never thought I would see the day that my main programming language was Javascript. But I find React such an enabling technology that I made the effort to learn Javascript properly, and am glad that I did. React itself is allowing me to write web applications faster and with less bugs, primarily because of the unidirectional information flow, but also because of the way it guides you into making everything components, which keeps the borders up between objects and makes testing easy. Even better, I can now create both iOS apps and Android apps at the same time (I knew Objective C but not Java for Android), and at a much faster speed than before - the flex layout model alone has saved me days and weeks of debugging the iOS layouts in storyboards, and now I'm able to shift code between the app codebase and the web codebase with ease. It is indeed overwhelming when first trying to learn React, especially when trying to learn Javascript at the same time, and this flowchart is so spot-on with the tendency to start using packagers, boilerplate, redux before understanding why they are useful. Follow the flowchart, and you will find happiness!
- Omnipresent 11y ago
  Can you provide more details about your path to learning JS and React?
- deleted 11y ago
  [deleted]
- sombremesa 11y ago
  I just want to point out that there is no mandate to use a framework in JavaScript. While I'm not familiar with React and I agree that it probably helps developers structure their apps, there is no need to use a framework just to have a component/modular architecture. One of my favorite examples of clean modular JS that does not depend on a framework is Mozilla's browserquest: https://github.com/mozilla/BrowserQuest/tree/master/client/js https://github.com/mozilla/BrowserQuest/tree/master/client/j... Many things that make life easier when making relatively small web apps also make debugging more complicated, compared to programming from scratch with minimal reliance on third parties. Choose wisely.
  - 11y ago
marknutter 11y ago
I had a hard time determining whether or not this flowchart was satire or not.
- grumblestumble 11y ago
  Agreed. I was kind of shocked to open up the comments and see people taking this at face value. I know this isn't reddit, but "upvoted because React" seems to be just as much in play over here.
  - uptownJimmy 11y ago
    I lol'd the minute I saw the flow chart. It's absurd. Helpful and well-intentioned, but absurd.
    - danabramov 11y ago
      Thank you for the criticism! Would you like to help me understand its flaws better so I can improve in the future?
      - grumblestumble 11y ago
        3 things: 1. Much of it reads as"are you taking this approach? yes? don't take this approach. no? take this approach." 2. There are also a couple of flowchart errors ("are you working on a production app" appears twice for no reason). 3. The main reason React makes me sad is the need for excruciating flowcharts like this. As a result, the entire thing comes across as self-parody. For context, I'm a developer who works on a large enterprise app with a full build toolchain (npm, babel, webpack, sass, etc ad infinitum).
        danneu 11y ago
        If you work with such a large build chain, how did you not realize that the flowchart is really about tooling complexity in the javascript ecosystem, in general? Also, the "are you working on a production app?" has two nodes so that it can model the fork into {yes bundle, no bundle}, common in flowcharts.
Scarbutt 11y ago
can JSX be translated in the browser? that will make it even easier to avoid tooling and just use script tags for dev.
- th0ma5 11y ago
  Yes, there is additional js loaded to do that. In the developer console you get a warning. It may be a tad slower.
  - zodiac 11y ago
    Are you referring to JSXTransformer? I thought that was deprecated?
    - andreynering 11y ago
      Yes, but now there's a version of Babel that runs in the browser and transpiles from JSX.
- pietro 11y ago
  Yes. The link is in the flowchart.
falcolas 11y ago
Where's the branch for "sad because I know react, and have to change half a dozen files with dozens of lines of boilerplate each for each change request"? I know a few of those - folks who aren't beginners and who loved react to begin with, but are getting slowly disillusioned by the sheer volume of changes required to modify a data source or add a new widget. Dropping flux or changing bundlers won't change the core of react... nor will writing any number of "helpful criticism" blog posts.
- danabramov 11y ago
  Would you mind expanding on this with some specific examples?
rickhanlonii 11y ago
TL;DR: If React makes you sad: try it without boilerplates, *flux, or ES6.
mrharrison 11y ago
I want to start using React but I think I'm going to stick with Angular for now. I have all of the gotchas of Angular figured out and I think I want to wait another year for the dust to settle on React. By looking at the flowchart it looks like the React ecosystem is still quite Alpha and learning to grow up.
- ENGNR 11y ago
  As someone who came from angular, if your app is going to get large react is far better than angular. For small pages / forms angular is in the sweet spot, so it depends on how your application is setup (not to say you can't do large apps.. but performance is harder in angular)
  - mrharrison 11y ago
    Looking to use react because of code cleanliness. Never had a performance problem with angular and have done two apps large apps thus far. I feel like people who have performance problems are just putting too much html on the page, and should rethink their design and rendering philosophy.
qntmfred 11y ago
what's the point of presenting this as a flowchart?
todd3834 11y ago
We wanted to make it as easy as possible for new developers to jump into the React ecosystem without having to worry about how to set up WebPack, hook up redux, worry about styles etc… That's why we created https://github.com/TrueCar/gluestick https://github.com/TrueCar/gluestick which is a command line interface to help you get started. As Rails developers we missed commands like `rails new` or `rails generate` so we tried to make something similar for our front-end environment. I highly recommend this blog post for anyone who is struggling with setting up React/Redux https://www.drivenbycode.com/getting-started-with-gluestick/ https://www.drivenbycode.com/getting-started-with-gluestick/
happytrails 11y ago
All these libraries make me sad.
aidenn0 11y ago
This flowchart assumes you are writing in javascript. Perhaps this is understandable as it's a javascript library, but there are several frameworks for other languages (most notably Om/Clojurescript).
- erichmond 11y ago
  Why in the world is this downvoted? Om/CLJS has some of the nicest bindings for React. It's extremely valid that if you are frustrated with React that you could experiment with the clojurescript ecosystem to see if that would "make you happy".
rmetzler 11y ago
I really like React, but I have to admit, that I don't write big apps with it (yet). There is one thing though which I find results in subtil bugs (entirely my fault): When one input is changing and depending on that input another output value has to change than the input shouldn't change state yet and the output should be computed from input (+ state where necessary). Only then you should set the state. Do not set the state before computing the output and don't compute the output from the previous state only. This will result in subtle and sometimes hard-to-find bugs.
- danabramov 11y ago
  If you’re saying that `this.state` doesn’t update immediately after `this.setState` so you can‘t use the previous value, one way to get around this is to use `this.setState` overload that takes a function: this.setState(prevState => ({ prevState.count + 1 })) This way all the changes will be stacked on top of each other correctly.
novaleaf 11y ago
nice flowchart, i know the point of redux but man the boilerplate needed to create a component sucks: class _MyActualComponent extends React.Component<reduxScafolding.Action & { myReduxState: reduxScafolding.ReduxState; pushPath: ReduxSimpleRouter.pushPath; } & { myActualProp: string; }, {}>{ //my component's implementation goes here. } /** type for casting (so consumers know the props they are required to pass */ class IMyComponentVisibleType extends React.Component<{ myActualProp: string; }, {}> { }; /** instrument my component with redux */ export var MyComponent = ReactRedux.connect( (reduxStoreState) => { //subscripbe to reduxStore updates (Called every change). return { myReduxState: reduxStoreState.myReduxState }; //map myReduxState to props } , _.merge({}, {}, { pushPath: ReduxSimpleRouter.pushPath }, reduxScafolding.action) as any //redux-binds, then includes the pushPath() method for use in our _App Component )(_MyActualComponent) as any as typeof IMyComponentVisibleType; ps: yes, about 3 lines of that is because I use Typescript.
- deleted 11y ago
  [deleted]
- olalonde 11y ago
  What language is this? I'm using es6 and most of my components just look like this: export default ({ name }) => ( <div>hello {name}</div> ) With Redux connect: const SomeComponent = ({ name }) => ( <div>hello {name}</div> ) export default connect(s => ({ name: s.user.name }))(SomeComponent)
  - novaleaf 11y ago
    The code I wrote is Typescript (ES6 with typings), I am using the ES6 class style React Components. you are using the lambda style components which is fine for simple stuff but for heavier stuff the class-style components are needed. also you are not passing the reducer actions, etc. Still, what you are showing in your simple example looks pretty similar to the amount of boilerplate I'm seeing with Redux, so it looks like there's not really an easier way.
vietnameselady1 11y ago
Although I like this a lot, and I think it addresses most individual nuggets of React Sadness in a pretty reasonable way, I am still sad. I am sad because every process rectangle in this chart should also point to a decision diamond that says: "Does it seem that the entire industry has migrated to this stack, whether or not it really makes sense for everyone to? That a feedback loop now influences shops to choose these tools/technologies not because they are called for, but simply because they are trendy? That present excitement outweighs the question of 'whether you need this or not' in the eyes of most of your peers and colleagues? That the incentive to not get left behind is stronger than the incentive to stop and consider?" And then, that diamond should point to a final rectangle that says: "If you wish to remain employable, learn React + Redux + ES2017 + Webpack now, or join a different sector of the industry. As for the sadness, deal with it." This isn't only true of React, of course. The underlying sadness comes from watching one's valid hesitations drowned out by the mob.
- vcarl 11y ago
  >Does it seem that the entire industry has migrated to this stack, whether or not it really makes sense for everyone to? It definitely doesn't make sense for all types of websites, but React seems to me like a solid choice any time a) a true web application is desired and b) maintainability, interactivity, and scalability are high priorities. React isn't the best choice for static informational sites and such, but I can't think of an application that wouldn't be well suited to React.
  - SomeCallMeTim 11y ago
    > but I can't think of an application that wouldn't be well suited to React. A truly complex app where speed is crucial. [0] Like Atom. [1] [0] https://aerotwist.com/blog/react-plus-performance-equals-what/ https://aerotwist.com/blog/react-plus-performance-equals-wha... [1] https://github.com/atom/atom/pull/5624 https://github.com/atom/atom/pull/5624
    - vcarl 11y ago
      Fair enough, low latency, high interactivity applications aren't well suited, but those will always benefit from being as "bare metal" as possible.
joslin01 11y ago
I don't know what's worse. A poorly-worded expression of someone's experience with React, or the no-info-or-even-attempt-to-understand judgment from you. Oh man, you're a guy who does a fair amount of React work and tries to pay attention to weird arguments against it? Let me immediately downvote that guy and upvote you! What's so weird about someone not enjoying the rigidity React offers and realizing that Facebook prefers this style since it has an army of programmers that would do well to stay in style with one another? By the way, I remember you. You're that guy who was relentlessly defending Facebook's chief of security in the comment thread after he acted like a scumbag. It was so weird how you responded to nearly every comment vindicating your pal.
- kruhft 11y ago
  Thanks.
  - joslin01 11y ago
    No problem. Don't worry about that guy or the downvotes. He's smart, but gets off on putting people down with snide one liners.
- wglb 11y ago
  By the way, I remember you. You're that guy who was relentlessly defending Facebook's chief of security in the comment thread after he acted like a scumbag. It was so weird how you responded to nearly every comment vindicating your pal. This is quite off-topic and accusatory. Please don't do that here.
  - joslin01 11y ago
    No I will continue just for him and hey look at that, you're both in security.
- dang 11y ago
  No personal attacks on HN, please. We detached this subthread from https://news.ycombinator.com/item?id=11196675 https://news.ycombinator.com/item?id=11196675 and marked it off-topic.
ryanswapp 11y ago
I think Meteor 1.3 + React is a really promising stack. If you are overwhelmed by all that comes with the default React stack (Webpack, Redux, React Router, etc...) then give Meteor 1.3 + React a try. It eliminates the need to write your own build system, makes writing a full stack JS app stupid simple, and overall makes you a lot happier.
- tyh 11y ago
  As a js newbie I have to say Meteor + React is very easy to get started in. Add in webstorm ide and I feel like I am back in .net world. I am still using 1.2.1, but I am excited about the more streamlined npm integration in 1.3.
amadeusw 11y ago
I wish I saw this a couple weeks earlier, before I gave up on React-Redux. Its documentation and Dan's talks work well for isolated samples, but I had no luck building a larger system that binds all the pieces together. There is no definitive documentation source (like msdn or angular docs) and every tutorial and guide came with its own massive set of boilerplates and libraries. These libraries did not have good documentation, either. React-redux brings a fantastic way of thinking about the application, and I'm looking forward to seeing appropriate documentation.
- danabramov 11y ago
  Mind expanding on specific challenges? We’re happy to hear your input at https://productpains.com/product/redux/ https://productpains.com/product/redux/.
hahamrfunnyguy 11y ago
It makes me sad looking at apps made with React. I am currently using Knockout.js and Router.js which is working out very well. I like that your code is concerned with maintaining the state of the VM, not rendering the view. What is gained by building an app in React, and are there certain scenarios where it really shines?
- badthingfactory 11y ago
  Having built a rather large SPA with Knockout, these are advantages I've found with React: 1) I don't have to worry about whether a property should be observable or not. 2) When changing a property from non-observable to observable, adding parens to most (or all) references is a burden 3) Screens with a large amount of state become difficult to manage and reason about with knockout. Should I use .subscribe, .computed, .pureComputed etc. With React, call .setState, and write plain javascript for everything else. 4) Mapping large objects to observable view models manually isn't fun and the knockout mapping plugin isn't good. React deals with plain objects. 5) Knockout components perform poorly compared to react components with large amounts of data. 6) Knockout is not intelligent in the way it renders. If you replace the value of an observableArray, Knockout will completely re-render any piece of UI bound to that array. This is especially bad when paired with #5. React does a virtual DOM diff and only renders the bits that have changed. 7) With knockout, I have to concern myself with how to go about importing html templates into my components. React is javascript-only. Just use React.createElement, or JSX if you're OK with transpiling. 8) React tooling is infinitely better. I waste a lot of time trying to figure out why some binding is throwing errors in knockout. I've never experienced this issue in react, especially when using PropTypes. 9) Custom knockout bindings to implement 3rd party libraries can be an absolute disaster - especially when attempting to support 2-way binding. It felt like every custom binding I wrote in knockout was full of hacks and terrible code. I haven't felt this way at all with React, and I only have to worry about binding in one direction.
plexicle 11y ago
I have tried to get in to React all week. The technology is easy, but it's Webpack that I'm having trouble enjoying. All I want is are two simple configs. A dev one with a server/hot loader, and a prod one that concats/minifies. ES2015. That's it. That just doesn't exist out there. It's either no decent production bundler, or it's like 15 files and 900 lines of configuration that seem completely overkill. I don't know. I don't have time to learn how the tooling works, but I also don't want a bunch of magic. Angular 2 is looking really good right now even with the (still very incomplete) angular-cli tool. Dang. I just want my simple gulpfile back.
- danabramov 11y ago
  Check out https://github.com/ryanflorence/react-project https://github.com/ryanflorence/react-project, it’s very new but seems similar to what you are aiming for.
  - plexicle 11y ago
    Thanks! I'll take a look tonight.
  - octref 11y ago
    Isn't that exactly what he's not aiming for, namely "15 files and 900 lines of configuration that seem completely overkill"? This seems to remove complexity but it just hides the complexity in the dependency. When something doesn't work out or he wants to change the behavior he still has to delve into these "15 files and 900 lines of configuration".
    - danabramov 11y ago
      It has focus on great production features without diving into config until you are ready. For something more approachable but less powerful check out https://github.com/insin/nwb https://github.com/insin/nwb.
- mst 11y ago
  Maybe look at the reactuate configs - those don't seem horribly complex and are a nice prepack.
christopher_ 11y ago
It's an interesting topic since React and the React ecosystem is great but it's so fragmented that it's difficult to get started with. What's the trade off between modularity in tools and productivity?
glossyscr 11y ago
tl;dr + my suggestion: Use React together with Redux, Webpack and Immutable (my suggestion). http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial.html http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial...
amelius 11y ago
Short version: 1. Does react make you sad? 2. Refactor all your code. 3. React makes you happy.
djfm 11y ago
I think React, in particular in combination with a flux pattern such as redux, has only shifted complexity. Complexity shifted from a mess of jQuery event handlers shuffling the DOM around to an intimidating mathematical abstraction in the form of functional programming. The benefit is that you can reason about pure functions, whereas you cannot reason about a mess of intertwined event handlers. Between to equally complex problems, react forces you to converge on a problem that you can actually solve. Programming is hard. I think what's happening now is that we're starting to discover issues that were previously hidden by problems that are now solved.
c0ffe 11y ago
Sometime ago, i tried react and found a property named like "do_not_modify_or_you_will_be_fired" (i dont remember in which object). I understand encapsulation is necessary, but i wonder how feels working with someone who writes code with a shotgun next to him / her.
- danabramov 11y ago
  Not sure what your point is about th shotgun. The point of that export is to keep supporting old API with a deprecation warning while it is being moved into another package. It is temporary.
sergiotapia 11y ago
Give React a try with Meteor and your head will explode. Suddenly everything works out of the box, you get nice ES6 syntax out of the box, files structure is flexible out of the box - notice a trend? Meteor and React is hands down the best way to use React in my honest opinion. Meteor 1.3 will come out very soon and will have full NPM and module support, after that I think Meteor will take the web by storm and become the defacto way to build modern webapps. None of this webpack silliness.
- beefsack 11y ago
  Does Meteor scale to hundreds of concurrent users yet? I've used it multiple times in the past and have always hit performance barriers even at tens of users, and have found it make scaling your infrastructure nigh on impossible.
  - sergiotapia 11y ago
    Yes it does, easily. And scaling is even easier when you use React because you 'subscribe' to data when the component is 'mounted' and when the component is destroyed you remove that subscription. And this all happens for you automatically. No lie, React makes Meteor scale by virtue of how it forces you to architect your data usage.
shruubi 11y ago
Am I the only one that finds it weird that this entire chart is about morphing how you use React into something that works for you rather than helping you evaluate your needs and identify what might be a non-react solution. Why are we as an industry suddenly so married to the idea that rather than evaluating other solutions we should just hammer away at React until it works for what we need?
- danabramov 11y ago
  Because this is exactly what people do before writing sad posts about how you “have to” use Flux, ES6, Webpack to use React. People get that impression because they search for “React boilerplates” and extrapolate. It’s great that you avoided this trap!
fludlight 11y ago
React makes me sad because the PATENTS file means I can't sell my creation to anyone suing Facebook for patent infringement. Personally, I don't think that software should be patentable, but it is and deep pocketed companies are always suing each other over this and other IP. Even if they aren't today, there is no guarantee that they won't tomorrow. So why bother with a technology that pisses in the proverbial pool, especially one full of lawyers (aka deal killers)?
LAMike 11y ago
React did make me sad, I was confused and frustrated configuring my app instead of building it. I switched to Vue.js and now I'm happy again.

288 points by danabramov 11y ago

There is an abundance of poorly written react apps popping up everywhere. Go to netflix and search for movies... the experience is terrible. The search box lags typing by a long shot. So much so its almost impossible to type in the full text of a movie name. I'm sure there is the correct way to do this (not making the field a controlled component?) but the problem being there on such a major site is a sign that its hard to do react correctly.

jaegerpicker 11y ago
I just went to netflix and it's not at all how you describe. It's incredibly fast and live filters as I type. There may be an abundance of poorly written react apps out there but netflix does not appear to be one.
- joelcollinsdc 11y ago
  maybe i'm just typing too fast. I tried "the best marigold" (for the best marigold hotel). I watched the i in marigold disappear from the search box. Deleting the string (by holding down the delete key, the X works just fine) takes forever as well. I'm using chrome if it matters.
  - janpieterz 11y ago
    Just tested it and didn't find it super bad, but I am honestly (negatively) surprised. It does indeed lag quite a bit and feels very unnatural. Chrome here as well. I use React quite a bit myself and haven't experienced this in my own apps. Odd! There's also a slightly annoying flicker when you type the last bit and it keeps returning the same movies.
    - sushid 11y ago
      The slow text input problem is probably because they're updating their redux or flux store on every keypress.
      - janpieterz 11y ago
        Something like that certainly plays it's role. I'm doing that as well for certain inputs and experience no lag at all, so it depends more on their implementation of the store. I think their search store is probably doing a lot more than mine (although, entering text, querying an API, processing response async). It seems like they could introduce some optimizations there.

vdnkh 11y ago

Everyone complaining about how React is just a trend is missing the point of React. It's not some revolutionary flash-in-the-pan technology based on a mystical black box, it's an aggregation of best practices that everyone (including yourself) has been clamoring to have implemented for years. Web components? Check. Object.Observer? Check. Virtual DOM? Check.

kawera 11y ago
Why not Web components directly? (genuinely interested, soon I'll have to chose one way or another for a new project)
- vdnkh 11y ago
  They're still experimental. React handles a lot of the legwork towards getting proper web components today.
- spankalee 11y ago
  I work on a web components library, so I'm very biased here, but web components will very soon have broad compatible support across all the major browser engines. It's the only interoperable solution going forward, because every framework out there right now is a silo unto itself.
  - kawera 11y ago
    Thanks, that's my understanding too. I've used Polymer in the past but before 1.0, will look at it again. No doubt web components are the future though, I only wonder if widespread browser support will be a reality in a 12-18 months timeframe.
spankalee 11y ago
React in no way implements Web Components. It doesn't create custom elements, period.

ajsharp 11y ago

Ah, of course, a flowchart! The CLASSIC path to understanding a library.

tylermauthe 11y ago

This is flipping brilliant!

gavi 11y ago

I am glad to be able to copy the links off the flowchart

ryannevius 11y ago

React made me sad, so I switched to Mithril[1]. Not only is it significantly smaller in size, but it's way faster and includes a router and AJAX methods out of the box. I wish more people would give it a shot. That said, I do still love React Native, and use React on a daily basis to take advantage of the "write once, run anywhere" paradigm. [1] https://lhorie.github.io/mithril/ https://lhorie.github.io/mithril/

bcassedy 11y ago
I've recently started playing with Mithril as well and I quite like it. I haven't used React or Mithril enough to speak confidently about the differences, but it seems Mithril offers everything React does and more with better performance and documentation.
grinich 11y ago
The React Native approach is actually "learn once, write anywhere." https://code.facebook.com/posts/1014532261909640/react-native-bringing-modern-web-techniques-to-mobile/ https://code.facebook.com/posts/1014532261909640/react-nativ...
- coldtea 11y ago
  Those are just slogans, like Java's was. In practice you'll learn React Native once (1), learn some of each platform's intricacies (N), and sometimes need to debug (at most for each platform, so 0...N.
bikamonki 11y ago
Project seems abandoned, no?
- timdorr 11y ago
  Looks active to me: https://github.com/lhorie/mithril.js/commits/next https://github.com/lhorie/mithril.js/commits/next
- deleted 11y ago
  [deleted]

programminggeek 11y ago

Perhaps the answer is to not use React.

dsp1234 11y ago
FTA: Q: "Are you still sad?" A: "... Consider another stack that better suites[sic] your needs (eg. Ember)" The author has anticipated that react is not always the solution that is appropriate, and provided guidance in the case that react isn't actually a good fit for the project at hand.
draw_down 11y ago
Heck, why not just give up on trying to write software entirely? It's hard, and there's TV on.

gorkemyurt 11y ago

Please keep writing dan abramov! May I suggest turning some of your stackoverflow answers to longer essays/blog posts in an organized fashion like https://www.objc.io/issues/ https://www.objc.io/issues/

auggierose 11y ago

Lol. I found React interesting, too, but I don't like to read Javascript code, so I rolled my own React-like framework in Scala. Life is so much easier if you don't have to depend on other peoples mess.

acjohnson55 11y ago
Your comment would be helpful if it linked to something people could see, but otherwise, it just comes off as empty bragging, without a coherent critique. To me at least.
- Confiks 11y ago
  I think publishing code would be in conflict with parent's message; by using your own hand-rolled mess, you at least don't have to depend on other people's mess. I must agree that my own mess is far more comprehensible that someone else's. Until Old Code Syndrome strikes, anyway.
untog 11y ago
Life is so much easier if you don't have to depend on other peoples mess. Future-you is going to look back on this comment and curse loudly.
- auggierose 11y ago
  I am already future me as I did this about 1.5 years ago :-) The stuff is not open-source yet, but reading most of the comments here I wonder why anyone would want to open-source things? To meet the friendly people of HN? ;-)
verisimilidude 11y ago
...where "other peoples mess" is based on battle-hardened production code from Facebook...
- kec 11y ago

toosmart4u12 11y ago

The flow of that chart is so convoluted. No different from React I guess ;)

raziel2p 11y ago

Some of these are a bit dubious. "Are you using a bundler?" If yes: "try not using a bundler." If no: "try using a bundler." Same for flux/redux.

tptacek 11y ago
I think you've missed the point. The thesis of the flowchart isn't that there's just one way to build React programs, but rather that it's the opposite: one reason people get sad with React is that they cargo-cult things from other projects that aren't relevant to their own project, and another reason is that people are missing things from other projects that might help.
- debacle 11y ago
  Using React without having a clear understanding of why is cargo-culting.
  - tptacek 11y ago
    I don't think that's true, or if it is, the first time you use any new tool you're probably cargo-culting.
deleted 11y ago
[deleted]
vonklaus 11y ago
I'm with tptacek here. I think the point is to try different things, especially for dif use cases. For learning, get a holistic view, for production consider X instead of Y. I found react to be really complicated and heretical personally. I don't like mixing languages, but if I do, I would like them to be tightly coupled. I have started to mess with vue.js which is really awesome. Even in as a meta point it would be like: > using vue.js? > give react a try again. It has changed a lot in 2 years.
deleted 11y ago
[deleted]

kruhft 11y ago

I've just started playing with React and my general opinion is that it's a very 'Facebook' project. Lots of restrictions on what you can do and when keeping all of the coders in line with what you're supposed to be doing and following the 'Facebook' way of programming. I'm sure it's great for writing traditional crud apps, but anything outside of the box that it wasn't intended is a major pain requiring major hacks just to get around it's ideas of data protection and timing. I'm sure there are plenty that like this rigidity, but for me, I'll pass.

tptacek 11y ago
This is the weirdest argument I've ever heard against React, and, as someone who does a fair bit of React work, I try to pay attention to all those arguments.
- kruhft 11y ago
  Just my experience. Obviously not one that's common, but I was also doing something quite a bit different than most people that use it, I'm sure.
  - HeyImAlex 11y ago
    What were you doing?
    - kruhft 11y ago
      Writing a 'driver' to integrate my low level UI component library to be usable with React. My major issue was the 'rule' that a parent can't access the 'state' of it's children; this turned a 2 hour job into a 3 day job for me just trying to find a way to get access to this state through all of the lifecycle callbacks while instantiating children at the same time. When asked in #reactjs, they said that if you need access to a child's state you should put it into the parent, which makes sense but not in my case. There is a natural way of hiding working 'upwards' through the chain, but I can't say I've seen it ever work downwards like in React, and I found that rather frustrating and difficult to work around.

blainesch 11y ago

This feels like it builds off of the philosophy of not being a victim.. if you find a problem, just fix it. In these use cases, that is simple to do.

acjohnson55 11y ago

As someone who was almost immediately made happy by React, ES6, Redux, and boilerplates, I'm not the target audience. But I feel like this would make me un-sad if I felt overwhelmed by all the choices. I think the Redux guide itself (http://redux.js.org/ http://redux.js.org/) also does a fantastic job of a very gradual release into complexity. I recommend that anyone who feels they may want a Flux-like store read through the whole guide. It took me a day or two, but I found it to be extremely clear and enlightening.

davej 11y ago
Also, the free "Getting Started with Redux" video course: https://egghead.io/series/getting-started-with-redux https://egghead.io/series/getting-started-with-redux The approach taken in the videos is great because it starts off with implementing your own simplified version of Redux and builds on that. There are no "magic" steps, this makes it much easier to develop an understanding of how it works.
- Klathmon 11y ago
  Just to throw another one in there, this github tutorial really helped it click for me: https://github.com/happypoulp/redux-tutorial/blob/master/00_introduction.js https://github.com/happypoulp/redux-tutorial/blob/master/00_... The rest of the tutorials left me feeling frustrated not really knowing why. This one i just breezed through.
  - merpnderp 11y ago
    Following the official redux tutorials left me and my boss independently frustrated and turned off by the app.js description. We had both given up on redux until I followed this tutorial and it explained how simple and elegant the way components received properties from the redux state in th connect call. Without this tutorial we wouldn't be experiencing the ease and joy redux can bring to large react apps (We're currently porting a large messy Angular app to react piece by piece by replacing just leafs of the app at a time)

draw_down 11y ago

This comment thread feels so barren, without a bunch of seasoned software professionals encountering JS build tools and immediately taking leave of their senses and declaring defeat.

et1337 11y ago

This reminds me of that Netflix talk on React [1]. In it, the guy first praises React to the heavens, then spends the rest of the session explaining all the ways they had to disable and work around React to get what they wanted with decent performance. It seemed to me like their use case could have been done with jQuery in a few hundred lines. Maybe I missed something. [1] https://www.youtube.com/watch?v=g01dGsKbXOk https://www.youtube.com/watch?v=g01dGsKbXOk

igorgue 11y ago
Nah you got the point, all these JavaScript frameworks are just over-engineering.
deleted 11y ago
[deleted]
SonicSoul 11y ago
just curious how you arrived at jQuery comparison. isn't that just a library for DOM utilities while react is a view engine optimized for minimum dom manipulation using observable pattern?
- et1337 11y ago
  I made the comparison because at the beginning of the video, he talks about how they split into two teams; one used jQuery and the other React. Apparently the jQuery team moved significantly slower. I found that hard to believe given all the hacks they had to with React later on.
  - tiglionabbit 11y ago
    The React team was probably quicker at responding to the designers' ideas. The stuff that took a longer time was getting all the transition animations to work, which can be difficult in any higher-level framework.
- qudat 11y ago
  jQuery and React are DOM manipulation libraries. jQuery packaged a bunch of other stuff in it but at its core it is all about DOM manipulation.

marcusr 11y ago

As a C and then a Ruby on Rails programmer, I never thought I would see the day that my main programming language was Javascript. But I find React such an enabling technology that I made the effort to learn Javascript properly, and am glad that I did. React itself is allowing me to write web applications faster and with less bugs, primarily because of the unidirectional information flow, but also because of the way it guides you into making everything components, which keeps the borders up between objects and makes testing easy. Even better, I can now create both iOS apps and Android apps at the same time (I knew Objective C but not Java for Android), and at a much faster speed than before - the flex layout model alone has saved me days and weeks of debugging the iOS layouts in storyboards, and now I'm able to shift code between the app codebase and the web codebase with ease. It is indeed overwhelming when first trying to learn React, especially when trying to learn Javascript at the same time, and this flowchart is so spot-on with the tendency to start using packagers, boilerplate, redux before understanding why they are useful. Follow the flowchart, and you will find happiness!

Omnipresent 11y ago
Can you provide more details about your path to learning JS and React?
deleted 11y ago
[deleted]
sombremesa 11y ago
I just want to point out that there is no mandate to use a framework in JavaScript. While I'm not familiar with React and I agree that it probably helps developers structure their apps, there is no need to use a framework just to have a component/modular architecture. One of my favorite examples of clean modular JS that does not depend on a framework is Mozilla's browserquest: https://github.com/mozilla/BrowserQuest/tree/master/client/js https://github.com/mozilla/BrowserQuest/tree/master/client/j... Many things that make life easier when making relatively small web apps also make debugging more complicated, compared to programming from scratch with minimal reliance on third parties. Choose wisely.
- 11y ago

marknutter 11y ago

I had a hard time determining whether or not this flowchart was satire or not.

grumblestumble 11y ago
Agreed. I was kind of shocked to open up the comments and see people taking this at face value. I know this isn't reddit, but "upvoted because React" seems to be just as much in play over here.
- uptownJimmy 11y ago
  I lol'd the minute I saw the flow chart. It's absurd. Helpful and well-intentioned, but absurd.
  - danabramov 11y ago
    Thank you for the criticism! Would you like to help me understand its flaws better so I can improve in the future?
    - grumblestumble 11y ago
      3 things: 1. Much of it reads as"are you taking this approach? yes? don't take this approach. no? take this approach." 2. There are also a couple of flowchart errors ("are you working on a production app" appears twice for no reason). 3. The main reason React makes me sad is the need for excruciating flowcharts like this. As a result, the entire thing comes across as self-parody. For context, I'm a developer who works on a large enterprise app with a full build toolchain (npm, babel, webpack, sass, etc ad infinitum).
      - danneu 11y ago
        If you work with such a large build chain, how did you not realize that the flowchart is really about tooling complexity in the javascript ecosystem, in general? Also, the "are you working on a production app?" has two nodes so that it can model the fork into {yes bundle, no bundle}, common in flowcharts.

Scarbutt 11y ago

can JSX be translated in the browser? that will make it even easier to avoid tooling and just use script tags for dev.

th0ma5 11y ago
Yes, there is additional js loaded to do that. In the developer console you get a warning. It may be a tad slower.
- zodiac 11y ago
  Are you referring to JSXTransformer? I thought that was deprecated?
  - andreynering 11y ago
    Yes, but now there's a version of Babel that runs in the browser and transpiles from JSX.
pietro 11y ago
Yes. The link is in the flowchart.

falcolas 11y ago

Where's the branch for "sad because I know react, and have to change half a dozen files with dozens of lines of boilerplate each for each change request"? I know a few of those - folks who aren't beginners and who loved react to begin with, but are getting slowly disillusioned by the sheer volume of changes required to modify a data source or add a new widget. Dropping flux or changing bundlers won't change the core of react... nor will writing any number of "helpful criticism" blog posts.

danabramov 11y ago
Would you mind expanding on this with some specific examples?

rickhanlonii 11y ago

TL;DR: If React makes you sad: try it without boilerplates, *flux, or ES6.

mrharrison 11y ago

I want to start using React but I think I'm going to stick with Angular for now. I have all of the gotchas of Angular figured out and I think I want to wait another year for the dust to settle on React. By looking at the flowchart it looks like the React ecosystem is still quite Alpha and learning to grow up.

ENGNR 11y ago
As someone who came from angular, if your app is going to get large react is far better than angular. For small pages / forms angular is in the sweet spot, so it depends on how your application is setup (not to say you can't do large apps.. but performance is harder in angular)
- mrharrison 11y ago
  Looking to use react because of code cleanliness. Never had a performance problem with angular and have done two apps large apps thus far. I feel like people who have performance problems are just putting too much html on the page, and should rethink their design and rendering philosophy.

qntmfred 11y ago

what's the point of presenting this as a flowchart?

todd3834 11y ago

We wanted to make it as easy as possible for new developers to jump into the React ecosystem without having to worry about how to set up WebPack, hook up redux, worry about styles etc… That's why we created https://github.com/TrueCar/gluestick https://github.com/TrueCar/gluestick which is a command line interface to help you get started. As Rails developers we missed commands like `rails new` or `rails generate` so we tried to make something similar for our front-end environment. I highly recommend this blog post for anyone who is struggling with setting up React/Redux https://www.drivenbycode.com/getting-started-with-gluestick/ https://www.drivenbycode.com/getting-started-with-gluestick/

happytrails 11y ago

All these libraries make me sad.

aidenn0 11y ago

This flowchart assumes you are writing in javascript. Perhaps this is understandable as it's a javascript library, but there are several frameworks for other languages (most notably Om/Clojurescript).

erichmond 11y ago
Why in the world is this downvoted? Om/CLJS has some of the nicest bindings for React. It's extremely valid that if you are frustrated with React that you could experiment with the clojurescript ecosystem to see if that would "make you happy".

rmetzler 11y ago

I really like React, but I have to admit, that I don't write big apps with it (yet). There is one thing though which I find results in subtil bugs (entirely my fault): When one input is changing and depending on that input another output value has to change than the input shouldn't change state yet and the output should be computed from input (+ state where necessary). Only then you should set the state. Do not set the state before computing the output and don't compute the output from the previous state only. This will result in subtle and sometimes hard-to-find bugs.

danabramov 11y ago
If you’re saying that `this.state` doesn’t update immediately after `this.setState` so you can‘t use the previous value, one way to get around this is to use `this.setState` overload that takes a function: this.setState(prevState => ({ prevState.count + 1 })) This way all the changes will be stacked on top of each other correctly.

novaleaf 11y ago

nice flowchart, i know the point of redux but man the boilerplate needed to create a component sucks: class _MyActualComponent extends React.Component<reduxScafolding.Action & { myReduxState: reduxScafolding.ReduxState; pushPath: ReduxSimpleRouter.pushPath; } & { myActualProp: string; }, {}>{ //my component's implementation goes here. } /** type for casting (so consumers know the props they are required to pass */ class IMyComponentVisibleType extends React.Component<{ myActualProp: string; }, {}> { }; /** instrument my component with redux */ export var MyComponent = ReactRedux.connect( (reduxStoreState) => { //subscripbe to reduxStore updates (Called every change). return { myReduxState: reduxStoreState.myReduxState }; //map myReduxState to props } , _.merge({}, {}, { pushPath: ReduxSimpleRouter.pushPath }, reduxScafolding.action) as any //redux-binds, then includes the pushPath() method for use in our _App Component )(_MyActualComponent) as any as typeof IMyComponentVisibleType; ps: yes, about 3 lines of that is because I use Typescript.

deleted 11y ago
[deleted]
olalonde 11y ago
What language is this? I'm using es6 and most of my components just look like this: export default ({ name }) => ( <div>hello {name}</div> ) With Redux connect: const SomeComponent = ({ name }) => ( <div>hello {name}</div> ) export default connect(s => ({ name: s.user.name }))(SomeComponent)
- novaleaf 11y ago
  The code I wrote is Typescript (ES6 with typings), I am using the ES6 class style React Components. you are using the lambda style components which is fine for simple stuff but for heavier stuff the class-style components are needed. also you are not passing the reducer actions, etc. Still, what you are showing in your simple example looks pretty similar to the amount of boilerplate I'm seeing with Redux, so it looks like there's not really an easier way.

vietnameselady1 11y ago

Although I like this a lot, and I think it addresses most individual nuggets of React Sadness in a pretty reasonable way, I am still sad. I am sad because every process rectangle in this chart should also point to a decision diamond that says: "Does it seem that the entire industry has migrated to this stack, whether or not it really makes sense for everyone to? That a feedback loop now influences shops to choose these tools/technologies not because they are called for, but simply because they are trendy? That present excitement outweighs the question of 'whether you need this or not' in the eyes of most of your peers and colleagues? That the incentive to not get left behind is stronger than the incentive to stop and consider?" And then, that diamond should point to a final rectangle that says: "If you wish to remain employable, learn React + Redux + ES2017 + Webpack now, or join a different sector of the industry. As for the sadness, deal with it." This isn't only true of React, of course. The underlying sadness comes from watching one's valid hesitations drowned out by the mob.

vcarl 11y ago
>Does it seem that the entire industry has migrated to this stack, whether or not it really makes sense for everyone to? It definitely doesn't make sense for all types of websites, but React seems to me like a solid choice any time a) a true web application is desired and b) maintainability, interactivity, and scalability are high priorities. React isn't the best choice for static informational sites and such, but I can't think of an application that wouldn't be well suited to React.
- SomeCallMeTim 11y ago
  > but I can't think of an application that wouldn't be well suited to React. A truly complex app where speed is crucial. [0] Like Atom. [1] [0] https://aerotwist.com/blog/react-plus-performance-equals-what/ https://aerotwist.com/blog/react-plus-performance-equals-wha... [1] https://github.com/atom/atom/pull/5624 https://github.com/atom/atom/pull/5624
  - vcarl 11y ago
    Fair enough, low latency, high interactivity applications aren't well suited, but those will always benefit from being as "bare metal" as possible.

joslin01 11y ago

I don't know what's worse. A poorly-worded expression of someone's experience with React, or the no-info-or-even-attempt-to-understand judgment from you. Oh man, you're a guy who does a fair amount of React work and tries to pay attention to weird arguments against it? Let me immediately downvote that guy and upvote you! What's so weird about someone not enjoying the rigidity React offers and realizing that Facebook prefers this style since it has an army of programmers that would do well to stay in style with one another? By the way, I remember you. You're that guy who was relentlessly defending Facebook's chief of security in the comment thread after he acted like a scumbag. It was so weird how you responded to nearly every comment vindicating your pal.

kruhft 11y ago
Thanks.
- joslin01 11y ago
  No problem. Don't worry about that guy or the downvotes. He's smart, but gets off on putting people down with snide one liners.
wglb 11y ago
By the way, I remember you. You're that guy who was relentlessly defending Facebook's chief of security in the comment thread after he acted like a scumbag. It was so weird how you responded to nearly every comment vindicating your pal. This is quite off-topic and accusatory. Please don't do that here.
- joslin01 11y ago
  No I will continue just for him and hey look at that, you're both in security.
dang 11y ago
No personal attacks on HN, please. We detached this subthread from https://news.ycombinator.com/item?id=11196675 https://news.ycombinator.com/item?id=11196675 and marked it off-topic.

ryanswapp 11y ago

I think Meteor 1.3 + React is a really promising stack. If you are overwhelmed by all that comes with the default React stack (Webpack, Redux, React Router, etc...) then give Meteor 1.3 + React a try. It eliminates the need to write your own build system, makes writing a full stack JS app stupid simple, and overall makes you a lot happier.

tyh 11y ago
As a js newbie I have to say Meteor + React is very easy to get started in. Add in webstorm ide and I feel like I am back in .net world. I am still using 1.2.1, but I am excited about the more streamlined npm integration in 1.3.

amadeusw 11y ago

I wish I saw this a couple weeks earlier, before I gave up on React-Redux. Its documentation and Dan's talks work well for isolated samples, but I had no luck building a larger system that binds all the pieces together. There is no definitive documentation source (like msdn or angular docs) and every tutorial and guide came with its own massive set of boilerplates and libraries. These libraries did not have good documentation, either. React-redux brings a fantastic way of thinking about the application, and I'm looking forward to seeing appropriate documentation.

danabramov 11y ago
Mind expanding on specific challenges? We’re happy to hear your input at https://productpains.com/product/redux/ https://productpains.com/product/redux/.

hahamrfunnyguy 11y ago

It makes me sad looking at apps made with React. I am currently using Knockout.js and Router.js which is working out very well. I like that your code is concerned with maintaining the state of the VM, not rendering the view. What is gained by building an app in React, and are there certain scenarios where it really shines?

badthingfactory 11y ago
Having built a rather large SPA with Knockout, these are advantages I've found with React: 1) I don't have to worry about whether a property should be observable or not. 2) When changing a property from non-observable to observable, adding parens to most (or all) references is a burden 3) Screens with a large amount of state become difficult to manage and reason about with knockout. Should I use .subscribe, .computed, .pureComputed etc. With React, call .setState, and write plain javascript for everything else. 4) Mapping large objects to observable view models manually isn't fun and the knockout mapping plugin isn't good. React deals with plain objects. 5) Knockout components perform poorly compared to react components with large amounts of data. 6) Knockout is not intelligent in the way it renders. If you replace the value of an observableArray, Knockout will completely re-render any piece of UI bound to that array. This is especially bad when paired with #5. React does a virtual DOM diff and only renders the bits that have changed. 7) With knockout, I have to concern myself with how to go about importing html templates into my components. React is javascript-only. Just use React.createElement, or JSX if you're OK with transpiling. 8) React tooling is infinitely better. I waste a lot of time trying to figure out why some binding is throwing errors in knockout. I've never experienced this issue in react, especially when using PropTypes. 9) Custom knockout bindings to implement 3rd party libraries can be an absolute disaster - especially when attempting to support 2-way binding. It felt like every custom binding I wrote in knockout was full of hacks and terrible code. I haven't felt this way at all with React, and I only have to worry about binding in one direction.

plexicle 11y ago

I have tried to get in to React all week. The technology is easy, but it's Webpack that I'm having trouble enjoying. All I want is are two simple configs. A dev one with a server/hot loader, and a prod one that concats/minifies. ES2015. That's it. That just doesn't exist out there. It's either no decent production bundler, or it's like 15 files and 900 lines of configuration that seem completely overkill. I don't know. I don't have time to learn how the tooling works, but I also don't want a bunch of magic. Angular 2 is looking really good right now even with the (still very incomplete) angular-cli tool. Dang. I just want my simple gulpfile back.

danabramov 11y ago
Check out https://github.com/ryanflorence/react-project https://github.com/ryanflorence/react-project, it’s very new but seems similar to what you are aiming for.
- plexicle 11y ago
  Thanks! I'll take a look tonight.
- octref 11y ago
  Isn't that exactly what he's not aiming for, namely "15 files and 900 lines of configuration that seem completely overkill"? This seems to remove complexity but it just hides the complexity in the dependency. When something doesn't work out or he wants to change the behavior he still has to delve into these "15 files and 900 lines of configuration".
  - danabramov 11y ago
    It has focus on great production features without diving into config until you are ready. For something more approachable but less powerful check out https://github.com/insin/nwb https://github.com/insin/nwb.
mst 11y ago
Maybe look at the reactuate configs - those don't seem horribly complex and are a nice prepack.

christopher_ 11y ago

It's an interesting topic since React and the React ecosystem is great but it's so fragmented that it's difficult to get started with. What's the trade off between modularity in tools and productivity?

glossyscr 11y ago

tl;dr + my suggestion: Use React together with Redux, Webpack and Immutable (my suggestion). http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial.html http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial...

amelius 11y ago

Short version: 1. Does react make you sad? 2. Refactor all your code. 3. React makes you happy.

djfm 11y ago

I think React, in particular in combination with a flux pattern such as redux, has only shifted complexity. Complexity shifted from a mess of jQuery event handlers shuffling the DOM around to an intimidating mathematical abstraction in the form of functional programming. The benefit is that you can reason about pure functions, whereas you cannot reason about a mess of intertwined event handlers. Between to equally complex problems, react forces you to converge on a problem that you can actually solve. Programming is hard. I think what's happening now is that we're starting to discover issues that were previously hidden by problems that are now solved.

c0ffe 11y ago

Sometime ago, i tried react and found a property named like "do_not_modify_or_you_will_be_fired" (i dont remember in which object). I understand encapsulation is necessary, but i wonder how feels working with someone who writes code with a shotgun next to him / her.

danabramov 11y ago
Not sure what your point is about th shotgun. The point of that export is to keep supporting old API with a deprecation warning while it is being moved into another package. It is temporary.

sergiotapia 11y ago

Give React a try with Meteor and your head will explode. Suddenly everything works out of the box, you get nice ES6 syntax out of the box, files structure is flexible out of the box - notice a trend? Meteor and React is hands down the best way to use React in my honest opinion. Meteor 1.3 will come out very soon and will have full NPM and module support, after that I think Meteor will take the web by storm and become the defacto way to build modern webapps. None of this webpack silliness.

beefsack 11y ago
Does Meteor scale to hundreds of concurrent users yet? I've used it multiple times in the past and have always hit performance barriers even at tens of users, and have found it make scaling your infrastructure nigh on impossible.
- sergiotapia 11y ago
  Yes it does, easily. And scaling is even easier when you use React because you 'subscribe' to data when the component is 'mounted' and when the component is destroyed you remove that subscription. And this all happens for you automatically. No lie, React makes Meteor scale by virtue of how it forces you to architect your data usage.

shruubi 11y ago

Am I the only one that finds it weird that this entire chart is about morphing how you use React into something that works for you rather than helping you evaluate your needs and identify what might be a non-react solution. Why are we as an industry suddenly so married to the idea that rather than evaluating other solutions we should just hammer away at React until it works for what we need?

danabramov 11y ago
Because this is exactly what people do before writing sad posts about how you “have to” use Flux, ES6, Webpack to use React. People get that impression because they search for “React boilerplates” and extrapolate. It’s great that you avoided this trap!

fludlight 11y ago

React makes me sad because the PATENTS file means I can't sell my creation to anyone suing Facebook for patent infringement. Personally, I don't think that software should be patentable, but it is and deep pocketed companies are always suing each other over this and other IP. Even if they aren't today, there is no guarantee that they won't tomorrow. So why bother with a technology that pisses in the proverbial pool, especially one full of lawyers (aka deal killers)?

LAMike 11y ago

React did make me sad, I was confused and frustrated configuring my app instead of building it. I switched to Vue.js and now I'm happy again.