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!
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.
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.
React Native [0]. Your view-specific code still has to be done per-platform, but your core logic can be shared, and all of it is written with Javascript using React as the framework. The JS creates and controls native elements, with the native parts mostly abstracted away.
I'm referring to native apps on iOS and Android as the code commonality is huge, with just a small number of platform specific components. The biggest surprise though was how much I could port out for a web version (and Electron based Windows and Mac applications)
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.
>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.
Did anyone claim the same about jQuery a few years ago? First people claim about js library fatigue, now we are complaining about there only being "one employable js library."
My point is more that, while Dan A.'s chart does a good job of addressing individual parts of React Sadness, it is sort of moot, because those choices will already be made for me, wholesale, via tangential incentives and community mob rule, instead of consideration and consensus on a per-project basis.
It doesn't matter (for example) if I am/am not comfortable with ES2015 syntax. A junior developer already made that decision for me when he decided to implement the modal window by adding React, Babel, and Webpack to the project, instead of just writing a two-line event listener and a CSS class. Meanwhile, my colleagues are standing at the kegerator toasting his choice, because how could we ever have maintained or optimized such archaic vanilla JavaScript before without arrow functions and DOM diffing!?
React is not bad. In fact, it is great. But instead of being "an option" it is becoming "the default." Sadness results from being forced by industry trends into using it everywhere, despite knowing that it doesn't solve any problems that I did have while introducing new problems that I didn't have.
Vanilla JS was so horrible when JQuery came out that pretty much everyone loved it, except for a few folks who had been early adopters of Prototype/Mootools/YUI/Ext and were decrying how JQuery didn't have their favorite pet utility function.
I think the JS fatigue we're seeing is because web development is now largely a mature industry. React is roughly the 4th generation of Javascript technologies (1st = DHTML/Layers, 2nd = JQuery/Prototype/Mootools/YUI/Ext/Dojo, 3rd = Angular/Ember/Backbone, 4th = React/Polymer). At this point, there are millions of JS developers, they have seen multiple generations go by, and they just want some stability. The folks who always want to be on the bleeding edge are off doing IoT and VR startups.
IMHO, React is a nice piece of software, but it's a nice piece of software entering a market where existing solutions are already pretty good and much of the action is moving elsewhere. They have to hype it up, because people won't give up their JQuery/Angular/VanillaJS otherwise. It's a very different situation than when JQuery was introduced and web development was recovering from the .com bust and years of stagnation in browser innovation.
Web development has reached "maturity"... How funny a thought us that.
Sorry to be brutal but. Fuck no it's not. An hours studying of the JavaScript ecosystem should be more than enough for most to see that not only is web development not mature its mutating and beginning to try to consume other programming disciplines like some form of cancer. Just look at how NodeJS has been creeping its way from server to desktop to mobile.
There's a new generation of web devs that are starting to feel old and cranky. jQuery will be 10 years old this year (I KNOW!?); Gnarls Barkley's Crazy was on the radio then.
you have a lot of truth in what you say. the funny thing is how this bunch of kiddos / noobs that started doing "websites" and "mobile apps" after iOS and Android thinks they know it all and they are doing the best thing ever when actually they are just implementing shitty designs that were done by other noobs that have never ever animated a button rollover properly or even a "website transition" in their life but call themselves "art director" , "senior bullshit" or something like that
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.
We're currently using Mithril and one of the biggest issues was getting started in it. It's adoption is lacking, making finding people who've had similar issues difficult. Solving every problem yourself is much harder than finding an existing answer on SO.
That said, we still use it, but we're considering moving to React in the future, mostly since its learning curve is a lot less steep and we would be able to iterate faster.
Have you tried the mithril.js gitter channel[1]? It's sort of the de-facto go-to-place for mithril questions; there are lots of active users there who are willing to help you out
You can also drop me a line via email, and I'd be happy to help too.
While domvm [1] is young and doesn't have the adoption of Mithril (not even within an order of magnitude), it does solve many issues that people frequently have with Mithril's architecture and magic. Check it out if you'd like. Disclaimer: I'm the author and 1.0 (stable) target is April 1st.
It's a half-joke date. I'm the only dev and there's still a crapload of docs and tests to write. If I can't hit it, then at least I have a good April Fools joke prepared :)
Truthfully, my knowledge is second hand. I haven't spent a ton of time with it, my coworker is the one who had issues learning it. I've spent a little time with it, and haven't had the same issues he ran into.
I think the issue comes from the learning curve between jQuery and Mithril. Coming to Mithril from React I'd imagine would be relatively easy, where coming to it from JS spaghetti would be rough due to the lack of adoption and step-by-step tutorials that exist compared to React.
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.
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.
I'm planning to keep the basic, most used APIs the same, but yes, there will be some breaking changes. Promises will follow ES6 API and advanced redraw control APIs will likely be changed to improve ergonomics and leverage good ideas from other vdom libraries.
Other correct comments about a quite active 'next' branch aside... The latest commit on master is Nov 12, 2015. That's not even half a year ago. The stable shelf life of software worth mentioning is longer than that, don't you think?
> That's not even half a year ago. The stable shelf life of software worth mentioning is longer than that, don't you think?
I can see that you haven't spent much time in the JavaScript ecosystem. And forget latest commit, if a JS project wasn't started in the last half year, it's already getting long in the tooth. After a half year, trendy devs will already start moving on to the next great framework and package manager.
Yes, that is my point, with so many options in JS frameworks, libs, etc, I normaly study Github activity before jumping in. Learning a new tool takes time and we cannot afford to waste it on dead-end projects.
Yes of course, but I would expect many commits between stable releases (patching issues). I guess this is just a different pattern where a solo-dev goes quitely working for a few months and then emerges with the next release.
To give some context, even though the version is at 0.2.x, it's been fairly stable for months, and there have been very few bug reports (despite it being used fairly extensively in relatively big codebases - see lichess.org, for example).
Most of the "bugs" (or rather, limitations) in the issue tracker are either discussions or things that are difficult to address w/ the current codebase - e.g. design/ergonomics issues, as opposed to implementation issues - Those are part of the reason for the rewrite.
Another thing that is worth mentioning is that Mithril's general philosophy is to avoid adding features for features' sake, so it can look less "active" than it actually is.
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.
He praises React because it makes it easy to change the UI design at any time in response to new requests from the designers. The hard parts he talks about are animations, pre-loading, and virtual rendering, which require some higher level orchestration to get right in any framework. You have to have some component keeping track of this stuff. They mentioned that they had to extend the standard transition component to make it more reliable.
He also talks about writing code in a way that will work on both the server and client side, which is something you have to think about no matter what library you're using.
> He praises React because it makes it easy to change the UI design at any time in response to new requests from the designers.
Does it though? I suspect their system is fairly brittle after all that "higher level orchestration".
I keep seeing this pattern repeat in different software disciplines. Unity is the same way: fantastic for prototyping, but often more painful in the long run.
It reminds me of a wise saying (can't remember the source) to the effect of this:
Javascript library user, day 1: "So expressive! So elegant! So easy!"
Day 300: "Kill me now."
C++ library user, day 1: "How can anyone live this way?"
Day 300: "Whoever wrote this was actually pretty smart."
This conversation could be had about any abstraction. They help with some things and hinder other things.
In this case, a purely functional transformation from application state to HTML means you don't have to think about every possible transition between states like you would in a normal jQuery application. However, since you are not thinking about transitions, implementing transition animations will be harder.
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?
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.
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.
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/) 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.
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.
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)
I was actually surprised when i started, because it starts with describing flux and how it works (and compares it to a more traditional MVC arch). Then it just slowly removes pieces until you get to a redux system.
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/
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.
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.
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.
I didn't find the webpack stuff to be too overwhelming, and split dev and prod into two webpack files.
`npm start` to start the dev server and `npm deploy` for a production build. The production build produces two files - a vendor file that contains vendor code, and a client file that contains custom code.
It probably contains more than you're interested in (redux, tests, etc.) but it should be clear how to strip that out.
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".
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 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.
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.
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.
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.
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.
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.
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.
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.
That's actually not what it's saying. It says if you're not in production and you are using a bundler, get rid of it. If you are in production and not using a bundler, start using it.
If you're in production using it and still sad, or if you're not in production and not using it and still sad, move to the next step.
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.
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.
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.
It's certainly a weird phrasing of an argument. However, it seems reasonable that some programmers will not like the specific style of structure that react espouses. Specifically the top-down push of data through parent-child component relationships. Specifically, if you are working with a lot of third party components that are not react based, it can be hard (or a lot of boilerplate) to contain them within react applications.
Sorry, that obviously isn't one of my better comments, and other commenters have done a much better job than I did reacting to the original argument.
What I'm objecting to isn't the idea that React's ideas aren't for everyone, or perfect for every application, but rather that React's issues somehow stem from some kind of Facebook-y need for "control". That's an especially weird claim to make given how simple and open-ended React (by itself) is.
> the top-down push of data through parent-child component relationships
This is a conventional approach when working with the DOM, since the XML is organized as a tree. Plus it happens to work nicely with their intended data flow pattern. But you make an interesting point, what about UIs that don't fit nicely into the document paradigm? Are there cases where it would be better to organize UI components in a graph, for example?
> if you are working with a lot of third party components that are not react based, it can be hard (or a lot of boilerplate) to contain them within react applications.
In my experience integrating third-party UI components has been much easier than I would have guessed. The difficulty has not really been in wiring the React parts to the component's API, but in making a stateful third-party component behave in a stateless fashion.
You can but fundamentally, if you dont buy into the fundamental guiding principles that a framework is based on, you probably shouldn't use the framework.
Its like saying lets use angular but not limit DOM manipulation in directives, build fat controllers that include direct requests to the server and business logic because all the service boiler plate is annoying and makes the application harder to reason about, and add objects directly to the global object because angulars dependency injection based on string values is error prone, not DRY, and kinda fool hardy, not use data binding because of the performance issues...
yeah those may be valid points, but if you buy into that you should just drop angular and use backbone or something else...
You can come around to the espoused best practices organically.
As I said before, it's reasonable that some people are not going to like these particular best practices, and that in some instances it's going to get in the way.
As a concrete example, I just put up a form that is basically just a SSR datatables.net table and a save button. Adding react into the mix is literally unnecessary, and just adds boilerplate/extra code for no gain. In other words, it gets in the way. So I chose not to use it.
I've actually found it surprisingly easy to wrap 3rd party libraries in thin React components once you figure out the lifecycle methods and findDOMNode().
That's what I thought until I actually tried. findDOMNode was the first thing I found and then I thought it would be trivial, but the problems of passing child state up to the parent left me befuddled for days.
I don't see how a desire for flexibility (hackability) is a weird argument. But I do see why React works this way to keep the hacking to minimum; unfortunately I needed to 'hack' react to do what I was doing and found it's use of readonly variables and state setting and availability during the lifecycle process to be highly frustrating.
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.
One of react's core tenets is unidirectional data flow. Trying to use it in a bidirectional way is... painful. There is also a struggle with state vs props. The quick version is that state is internal to a component and is changeable directly by it, and props are given out by the parent and are not directly changeable.
Generally the way the bidirectional issue is solved is by closing the loop via dispatchers and stores. The child components send out actions to the stores, which then flow down through the parent, back in to the child. Turning what used to be a bidirectional flow to a unidirectional flow (sometimes at the cost of a bit of boilerplate for pre-existing components).
I guess the real question is, what is the use for the parent to be able to see the 'state' (the child components internal state)? The answer to that question (in my limited experience) has often been either 'to trigger an event (ex: save a form)' or 'so the parent can make some other rendering decision'. Both of which I've generally been able to solve via a flux implementation and possibly changing a 'state' into a 'prop' in the child (where the child gets a prop, some action is taken, and instead of changing state internally, an event is dispatched to the store with the new data, and the parent rerenders the child with the new 'prop').
But ultimately, hack it how you need. It's your code after all.
I had the same problem until I saw the light. The problem wasn't React: it was me.
You shouldn't merely learn React, but also unidirectional-flow architectures (like Flux, but there are many others, including better ones IMHO). Bidirectional data flow is a pain in the ass and once you understand unidirectional data flow, everything fits much easier. Of course, trying to shoehorn a bidirectional data flow in React is going to cause a lot of pain.
If you still need a bidirectional data flow, messing with lifecycle callbacks is definitely not the way to go. It seems to me you didn't have problems with React. You had problems learning React.
Unfortunately I'm not looking for a Religion, I'm just looking to get my job done. Too much structure can be just as bad as not enough when it comes to programming.
Put ref properties on the child components. Put public methods on the child components. You can then access the refs from the parent in the parent's componentDidMount or componentDidUpdate methods.
> this turned a 2 hour job into a 3 day job for me
> just trying to find a way
That basically summarizes my entire career with CSS/HTML/Javascript.
"Oh, the page you made looks great! Can you just move that image 10 pixels to the left?" Spend two days hitting my head on the desk trying to figure out why it won't align correctly
"Oh, the page you made looks great! Except in IE and the version of Chrome on Android 4.0.3" Spend two days trying to fix those browsers without breaking the others
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.
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)?
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.
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.
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.
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?
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!
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.
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.
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)
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.
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?
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.
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.
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:
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.
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.
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.
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?
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).
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".
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.
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).
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.
If you take a close look at both flows you will see that point 1 and point 2 actually explain each other. :-)
If you use React in production and don’t use a bundler, you should. If you don’t use React in production and do use a bundler, perhaps you shouldn’t because it will distract you from learning process. Does that help?
The “need” for flowcharts like this comes from lots of misleading information on the internet about React, not from React itself.
Dan: I did not mean to offend, truly. As someone who has been working in this field for only ~ 2 years, it's just still kinda surprising to see such a thing. I wasn't sure at first if it was serious.
But I also understand the reality of our field, where such things are very serious, and yet always verging on self-parody. I'm getting used to it.
I talk to a lot of people on Twitter and I see real people turned off from React because they saw complicated boilerplate projects and assumed all of this is necessary just to get started. I’m just trying to counter the misinformation.
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.
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.
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.
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.
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.
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.
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? ;-)
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.
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.
On the other hand, React is from the same Facebook which determined that the same technologies which Apple uses to write, build and debug an entire OS aren't powerful enough to write a social media app which runs on that OS.
I have a react app that is almost 2 years old now and the only change I had to make was when they moved a function from the React to the ReactDOM namespace.
It is, but it's not written in javascript[1]. Flux came out when I was in the middle of developing it, and I spent hours reading about it, looking at it and playing with it, and it just didn't solve any problems that I had.
Note that the community's ideas of best-practices, and all of the ecosystem around react is changing at an absurd pace, but core react is fairly stable.
Sure, I started a react project and got everything working with es6 and babel in October. In December I upgraded to react 0.14 and had to refactor all the things. It was extremely difficult to figure out how to solve some of the arbitrary-seeming changes, such as now having to re-bind all of the methods in the constructor.
Wait, why did you refactor all things? I’m afraid you have been misinformed. :-(
Please read the official release notes when upgrading.
Nowhere does 0.14 say you need to change components to use classes. They are allowed now (since 0.13) but React.createClass() is still there and is not going away any time soon. I’m afraid you listened to bad advice.
1. Transitioning to 0.14 forced you to rewrite something (what? how? I assumed you meant transitioning to ES6 classes which wasn’t necessary but it seems like you meant something else)
2. What choice was it that you didn’t have? Just like 0.13, 0.14 (and 15 soon) allows you to use either ES6 classes or React.createClass(). Both approaches work and will keep working. What are you referring to?
It would really help if you could share at least a simple code example demonstrating your pain points. I want to help! Cheers.
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!