Impressive job replying to what seems like a hatchet job, without losing his cool.
But my favorite part: The next React will allow returning an array of components without a div wrapper. Small change, but it annoyed me to no end that it wasn't already possible.
IMO, this really shows the maturity of React as a project and gives me a lot of confidence that working on React apps wont be in vein after another few years. They are able to see pain points and provide solutions to solve them without sacrificing backwards compatibility.
Sounds like the original post he was replying to was a hatchet job to begin with. The author did an admirable job of not getting down in the mud, I'm sure it was difficult not to take the original post personally and respond in kind.
Because, as I'm reading the response, the original post had a number of inaccuracies and FUD that it's not a good idea to leave out there unanswered since people will then assume they are true.
Yep, that was the main motivation. I should've made it clearer (I hope some edits to the post helped). It's far from the first post like this but I noticed some of the factual misconceptions seem to be picking up, so I wanted to set them straight on the record. But I didn't consider the tone enough, and I regret this. I hope it's a little better now. :-)
I'm on the React team and momentarily read this the same way you did. It probably could have been clearer, but I think I don't think number of components here is meant to be an accomplishment. Rather, it just means that we've done the work of testing compatibility already on a gigantic codebase so there's a good chance that most other apps will work out of the box.
How does testing work within FB, and how much of the frontend is tested? I don't think I have seen much on how FB does testing out there, and I have a good friend who complained about lack of tests at FB (he got called about his code change breaking the spam filter at midnight, and was pissed because there were no tests so he wasn't able to guarantee something like that wouldn't happen).
I only ask out of curiosity, it'd be good to know how FB approached testing as a data point on a major company's approach (vs. say Google)
I can't say much about Google, but at FB we have a combination of unit tests and integration tests. We don't strive to have 100% coverage, but the amount of tests is always growing, and we are investing effort into efficient tooling for running thousands of front-end tests: http://facebook.github.io/jest/.
My point being, you are doing a great job, if a person is frustrated over some tech and writes a blog post or whatever about it, maybe you should just leave it with that? Coming out defending design decisions etc just leaves a foul taste. React is awesome, but maybe it is not for everyone?
It's definitely not for everyone, but it would be nice for people to make that decision based on accurate information.
There is unfortunately a lot of FUD that has been spread around React in general, the React ecosystem, and the upcoming React Fiber rewrite. It's a combination of longstanding complaints like "HTML in my JS? EWW!", concerns about build tools like Babel and Webpack, badly written articles and headlines like the recent TechCrunch post that claimed "React Fiber is a complete change that Facebook has never talked about", and of course lots of arguments in comment sections.
If someone has taken time to evaluate React and determined that it's not for them, that's totally fine. But, when poor articles get upvoted and spread widely, it doesn't help anyone.
Thanks for feedback! I edited the article to remove those sentences, as indeed I can see how it can be seen as aggressive (that wasn't my intention, and Ben's interpretation is correct).
Regarding the motivation, it wasn't to defend any decisions. I'm sorry I didn't make this clear enough. The motivation for replying was to highlight some factual inaccuracies that have started to gain traction. I see posts like this every other week, and I've noticed a few incorrect points shared between them, so I felt this is a good time to jump in and help clarify them. I could've done it in a better way though.
I added these two paragraphs:
>Your post includes some misconceptions commonly held in the React community, so I wanted to take a moment to clarify them for everyone else who has the same concerns.
>That is not to say that React works well for everyone, or that the issues raised are not valid. But there are a few facts that I think are important to get right before considering those problems.
I agree. In general, I aim to never use emojis within a post like this because that leaves too much up in the air for interpretation. I did find it a bit high horse, and subtle jabs, albeit still jabs at the original article's author.
Left a bad taste in my mouth when I finished reading it.
I can understand the author's frustration when the user's criticism is unfounded in many areas but his points could've been made without the tongue in cheek comments.
It's a double standard for sure, but it's the same concept as when you're responding to a potential troll on social media. You don't want to add fuel to the fire.
Thanks for sharing! I edited the post in response to the negative feedback here, so I'd appreciate if you could give it another look and let me know if there's something else jumping out.
In all fairness, I wanted to make sure your points were heard clearly and I felt the tongue in cheek comments distracted from the clear explanation of how the author was offbase and incorrect.
Is that surprising? I have nothing to do with react and even I felt like ordering a shield after reading that original post. It wasn't well thought-out criticism, it was full of attacks and poorly researched complaints.
I'm sure Dan would have done nothing with it, had the HN community not upvoted the original post through the roof.
Admittedly, Dan does make it a point to search out confusion and concerns about React and try to offer help and address problems. But yes, that kind of high-profile post was definitely worth a response (particularly given the odd arguments and confusion in the post itself, much less the comment threads).
I didn't see the original article, but he was tossed a softball. The issues quoted in his response are so cliché.
React is great, and judging by the growing ecosystem, many people agree. If you don't like it because it requires you to learn a workflow you are unfamiliar with, don't use it.
> If you don't like it because it requires you to learn a workflow you are unfamiliar with, don't use it.
Unrelated to the technical side (which I haven't investigated in much depth yet as a third party to this discussion), I don't like it because of the patent license, which AFAICR is a valid concern for a non-trivial number of large firms.
How would that help? If Facebook has any patents on React, it's quite likely that preact is violating them. If you're using React then you're protected by the patent grant. If you're using preact then you aren't.
Well, please correct me if I'm wrong, but as I understand it by using React you're essentially giving up your right to sue FB for infringement of any of your patents (assuming you wish to keep using React). True, by using something like preact I suppose there is the alternative risk you pointed out. But perhaps it's a tradeoff some businesses might find acceptable.
You don't give up the right to sue them; you just lose the patent license if you do. If you use preact, you don't have the patent license at all, so you are in the same situation as if you used React and sued them over patents.
Tons of large firms patent everything under the sun, Facebook included. There's no telling when those will come in conflict, and I don't want to be on the wrong side of that battle just to use a framework with alternatives available.
I can look at external analyses, but the firms I've spoken with have had their own IP folks examine it and have each made their own decisions, so I'm merely parroting the accounts of those I've spoken to.
Edit: my initial comment (thread root) sits in the negatives but this one is high in the positives. It's interesting observing what I can only conclude is a proxy battle between the technical crowd and the crowd that understands legal realities.
The problem with the patents clause is that it's too broad wrt patents. If you have a valid patent that Facebook is infringing upon, no matter if it relates to React, Facebook revokes your right to use React. That's their prerogative, but it is generally too broad to allow some companies to actually use the library.
There are teams at Amazon and Google that use React. Honestly, the original patent license had some issues, but the new license seems to have alleviated concern for 2 of the remaining big 4. I don't know if MS uses it, but honestly 2/3 of the major tech firms are, and I can't imagine a world in which a concerning patent license is going to get passed the corporate lawyers at Google/Amazon.
Microsoft also currently owns a stake in Facebook, it's worth noting. That stake used to be 1.6% of the company, though I don't know how much they currently hold.
React is useful, it makes a lot of things easier to learn, and it has a beautiful architecture (imo).
But, React is still just another tool in our toolboxes.
If we're building prototypes or short-term apps, slap it together with whatever tool is fastest for you. If we're engineering something that needs to last and provide a great experience, it's important to know when to use a Philips head screwdriver versus a flathead, or either, or when we really just need a hammer.
I recently completed two projects, one in Elm and one in React. Elm was a lot more fun. JSX in particular felt very unwieldy compared to the Html package in Elm. Being able to write everything in a neat functional language was a nice experience for me.
React is very usable without Redux. I'm not sure how they became bound so tightly together.
I keep seeing this pattern of redux as a page-level data store, whereby on each page load you pull your data from rest APIs, put it in that page's part of the data store, to be modified with that page's reducers, triggered by that page's action creators. Then it's all hooked up to one single page-level connected component which passes all the state down to other components as props anyway, making it functionally identical to just using the React state in that page component.
The justification for this is usually either "Now you can make your page components pure functional components!" (whooptee-do) or "Redux scales better" (citation needed). Pretty thin.
Without ragging on developers that do this, I actually think it's a very serious problem. I frequent the #react irc channel a lot, and almost every beginner comes in with the same sentence: "I really like the way ___ does ___, where do I start?" (or some variation of)
If you're using the words "like" or "cool" to describe your latest dependency then that's a serious red flag. These libraries exist to solve problems, if you can't describe the problem you're trying to solve with one of them then you shouldn't be using it.
There _are_ definitely a number of benefits to using Redux in a React app. I actually co-authored an article that discusses some of them: https://www.fullstackreact.com/articles/redux-with-mark-erik... . TL;DR: time-travel debugging and better hot reloading for development, easier management of data that needs to be used in multiple places throughout the component tree, and all the niceties of having centralized state (logging, state persistence, issue reporting, etc).
I'm beginning to think there'd be a way to make Redux a helluva lot clearer by sticking everything in a class with a well-defined interface (but: ewwwww, classes, impure, burn the heretic!). Keep all the definitions for an actioncreator, event (action), and its reducer in one place. Hand the whole class to Redux and forget about it. Can compose actions/reducers inside those classes if you want/need to, so no loss there.
The pile o' reducers thing just isn't a very useful way to organize code IMO, and having everything split over several files makes following what's happening a PITA (especially without something like Typescript to let your tools give you the information you need, rather than having to keep it in your head or go look it up manually).
Redux feels... not over-engineered, exactly, but maybe mis-engineered.
... or we could just cut out the middleman and go all Actor model on this problem. Just sayin'. (yes, I know there are actor-model libs for React out there, but frankly the churn-related breakage and confusion in the most popular tools is so bad I'm afraid to step outside the mainstream, where it's probably even worse—plus we don't get to choose our own libs/patterns all of the time)
There's already a whole bunch of "define Redux action creators and reducers as classes" libraries out there. I've added the ones I've seen to my Redux addons catalog, in the "Variations" category: https://github.com/markerikson/redux-ecosystem-links/blob/ma... (which is where I list stuff that builds on Redux, but takes it in a "non-idiomatic" direction).
There's definitely several different schools of thought about how to organize and structure Redux-based code. Dan is a big fan of the "small independent slice reducers responding separately to the same action" approach. Others prefer to see all possible state changes for a given action in one place. And yes, while the intended use of Redux is based on functional programming, there's also those who prefer putting OOP layers on top.
I'm actually working on a blog post that will try to clarify and discuss what actual technical limitations Redux requires of you, vs how you are _encouraged_ to use Redux, vs how it's _possible_ to use Redux. Been busy with other stuff, but hoping to make progress on that post this week. If you're interested, keep an eye on my blog at http://blog.isquaredsoftware.com .
You may also be interested in an issue I recently opened to discuss possible future improvements and "ease-of-use" layers that could be built on top of the Redux core: https://github.com/reactjs/redux/issues/2295 .
Finally, I'm always happy to chat about Redux (and React) over in the Reactiflux chat channels on Discord. The invite link is at https://www.reactiflux.com . Feel free to drop by and ping me.
>I'm beginning to think there'd be a way to make Redux a helluva lot clearer by sticking everything in a class with a well-defined interface (but: ewwwww, classes, impure, burn the heretic!).
I thought the same thing. That's why I started using VueJS with Vuex. Vuex accomplishes the same things as redux in a much more manageable and centralized manner. Plus, you don't have to worry about connecting your components to the store through `react-redux` or whatever. With Vue and Vuex, you just pass the store object to the root view component and it's available in every single child component via `this.$store`. You can then `dispatch` actions which perform `commits` which call `mutations` which update the state. Then, in your component you create a computed property that uses a `getter` to return the piece of application state you want. It's a really simple top down data flow and everything is namespaced. It's so absurdly simple and easy that I don't understand why redux doesn't take a page from vuex's book.
I really should write a Vue + Vuex tutorial for beginners as I'm super happy with the way it works.
You don't even need a class, but either way, this is essentially how Elm works.
There are very different semantics at work there though. Elm is Fractal, Redux is not. Each have tradeoffs. Some stuff gets simpler, some stuff gets harder (the 1:1:1 scenario where you have a component, an action, and a reducer to achieve 1 thing gets easier. The N to N to N scenario where a reducer can handle things from all over the system, gets harder).
It's not misengineered, its just optimized to make a different set of problems easier at the cost of making others harder.
I don't understand Redux, I have almost 20 years of coding (I probably suck at it though). I once asked a developer at an interview if he could explain the redux stuff he had used in an assignment. He couldn't and I really tried to understand all the boilerplate and inner designs of the library, but I found it really hard to get into. Mobx though, 2 minutes and you get it AND you get more efficient in building complex UI:s.
I'd be happy to answer any questions you might have about Redux if you'd like. The Reactiflux chat channels on Discord are a great place to hang out, ask questions, and learn. The invite link is at https://www.reactiflux.com . Feel free to drop by and ping me.
Also, I keep a big list of links to high-quality tutorials and articles on React, Redux, and related topics, at https://github.com/markerikson/react-redux-links . Specifically intended to be a great starting point for anyone trying to learn the ecosystem, as well as a solid source of good info on more advanced topics. It includes links for learning core Javascript (ES5), modern Javascript (ES6+), React, and much more. I also published an "Intro to React (and Redux)" presentation at http://blog.isquaredsoftware.com/2017/02/presentation-react-... , which is a good overview of the basic concepts for both React and Redux.
This is my experience as well. The largest struggle I have with Redux is understanding where things belong. Where do ajax calls go? Should I use redux-thunk? That feels like an anti-pattern to me. Redux-saga is interesting, but it's going to be really tough for unfamiliar devs to understand generators with infinite loops. I also don't feel like writing an infinite loop every time I want to perform a simple fetch. With mobx, shared code goes in a class, it doesn't matter if it's async or not, and observable properties get a decorator.
As a short version: you _can_ put your async logic right into components, but it's nicer to move that logic outside components for reusability. Middleware have access to `dispatch` and `getState`, so they act as a loophole that enables you to perform async work and then interact with the store.
My own take is that `redux-thunk` is sort of the "bare minimum" approach to async behavior, as it allows you to do stuff with promises and async functions, or complex synchronous logic. Sagas are useful for complex async workflows, and there's also some popular observable-based side effects addons as well. Ultimately, the approach you use is up to you.
If you'd like more info on what good Redux code structure looks like, you may want to read through the "Redux Architecture" and "Redux Techniques" section of my React/Redux links list at https://github.com/markerikson/react-redux-links/blob/master... . Also happy to answer any questions you might have.
I learned the unidirectional data flow pattern with flux before redux and redux makes flux look like war & peace! :P
The no frills way I like to think about redux is your rendered page is the result of a function operating on a state object. Changes to the state object trigger re-renders. There's obviously some subtleties in there and complex use cases, but that's the basic gist.
You started on the wrong foot. Learning from someone who cannot explain his own code is not the right context to learn any tech.
Redux is a modern implementation of CQRS/Event sourcing, a design pattern that existed before you even started coding. Many developers, in different languages, learned it and used it (if you want to implement an undo stack for instance, there is not a lot of other solutions around). Trust yourself and your intelligence. Our devs learn it in about 3h with our training program and get a return on investment in about a week.
MobX is nice and if it fits you, go for it. If you are a hands-on kind of guy, you may discover the limits of MobX by using it, and from the trenches finally understand why Redux, and why does it need 3 objects (a store, a reducer, an action).
It's two event/message dispatchers slapped together. One for "reducers" that take an event/message and apply it to state, one that automagically applies the resulting state-change event to do stuff to your views. You mostly don't need to worry about the second one.
As far as I can tell, that's it.
For bad reasons they've decided to stick with the terrible "action" name for their events/messages, which has made the whole thing super confusing (turning "actionCreator" into "eventCreator" immediately makes things much clearer, for instance).
There's also a ton of convention/process taught on top of it for some reason that's IMO not that great, and makes it really hard to see what's actually part of Redux and what's cruft on top of it that you can skip/modify. Redux-as-typically-presented is mostly you doing stuff to follow a (kinda painful) pattern, not the Redux library helping you do stuff.
[EDIT] I'd add that the communication pattern of the docs and various attempts to help people understand Redux seems to largely be "oh, you didn't get it? Let me say the same thing again but louder". Which is why there's SO MUCH documentation and chatter for something fairly simple, I think. Which just compounds the problem.
A lot of the naming of stuff goes back to Redux's Flux heritage. The Flux architecture labeled those objects as "actions", so Redux (since it was intended as a "Flux implementation") kept that naming.
You are right that the majority of usage is really at the user level, than the library level. I'm actually working on a blog post that will try to clarify and discuss what actual technical limitations Redux requires of you, vs how you are _encouraged_ to use Redux, vs how it's _possible_ to use Redux. Been busy with other stuff, but hoping to make progress on that post this week. If you're interested, keep an eye on my blog at http://blog.isquaredsoftware.com .
If you have concerns with the docs, I'd appreciate any specific suggestions or ideas you might have for improving them. Docs issues and PRs are absolutely welcome, from you or anyone else who wants to help improve them.
Finally, I recently opened up an issue to discuss possible future improvements and "ease-of-use" layers that could be built on top of the Redux core: https://github.com/reactjs/redux/issues/2295 . Would be happy for any feedback you could offer.
(edit: just noted I replied to you a couple different times in this thread, and repeated myself a bit. Offer of discussion absolutely still stands :) )
A lot of Abramov's responses do refute the original points, but they also betray how much cognitive overhead is required to play in React's ecosystem.
The guy used Redux, I'm sure, because he knew he needed to manage state somehow - and the articles he found probably pointed him there (rather than vanilla component state)
He knew he wanted some sort of routing system, found react router, was got a bit scared by how quickly it has been moving lately - and also, likely, how many existing articles about it are somewhat outdated
I do think it's important to consider, however, that — contrary to the belief that React.js is a cesspool of anti-patterns — that we're actually watching creative destruction at it's best.
Yes, libraries are moving fast and breaking things. Yes, competitive solutions are releasing at breakneck speeds. But that's more or less what happens when you reinvent the way people build things, as happened with the virtual dom.
And while we're paying for it in up-front build setup, we're vastly making up for it where it counts: JS applications that can grow big (at least I am).
It's all relative. The point Dan was trying to make was that you shouldn't be using Redux until you need it. You shouldn't be using React Router until you need it.
The React team can't be held responsible for the amount of crappy advice on the Internet. And cognitive overhead is the nature of the beast with all frameworks. Nobody is going to launch an Angular/Ember app without a significant amount of research. Hell, Rails barely requires any knowledge of Ruby at all, since it's effectively its own ecosystem.
> The React team can't be held responsible for the amount of crappy advice on the Internet.
The React team should not be held responsible, but these problems do warn people to stay away from the React ecosystem. If the React team doesn't want people to stay away, it's in their interest to do something about it.
> And cognitive overhead is the nature of the beast with all frameworks.
It is, but they vary wildly in (a) the total amount of cognitive overhead required, and (b) whether you need to deal with that overhead before you even begin, or slowly, over time, as you develop your app. Modern JS development front-loads all of that overhead, which makes you handle it before you're even sure that you want to use a given tool in the first place.
The official docs are good. Create React App is great for getting started with minimal overhead. This very article is a remarkably restrained and informative reply. The React team is doing a good job.
> but these problems do warn people to stay away from the React ecosystem
No they don't. There is bad advice for every framework/language that exists. Following bad advice means carefully trusting sources. It is 100% on the user to determine whether an article applies, or it's plain wrong.
> If the React team doesn't want people to stay away, it's in their interest to do something about it.
Do what exactly? Start sending take-down notices for poorly written articles? Would you use a chainsaw to make a miniature, and then saw the chainsaw manufacturers need to "do something about it"?
> It is 100% on the user to determine whether an article applies, or it's plain wrong.
It is. But nobody has the time or patience to determine that for every article, so if the React team wants people to use React, then it's in their interest to insure good articles about React are easier to find than bad articles about React.
> Do what exactly? Start sending take-down notices for poorly written articles?
Write good articles & tutorials, as well as share & popularize the good articles that are out there. Ask the companies that use React talk about React and how it solves their problems. If developers like starter kits & scaffolded projects, then write some good ones and toss them up on Github. Make sure the message that they want to get out doesn't get buried under all of the poorly written cruft out there.
They're under no obligation to do any of this, but nor are most developers under any obligation to use React. If they want people to use React, and the message that React is a good, easy framework to use is getting lost, then... well, how do you think that's going to end up?
Or to put it another way: there are a lot of JS frameworks out there. React needs developers to use it, more than those developers need to use React specifically. So they should be willing to do some of the heavy lifting needed to attract people; moreso if there's a negative message already out there.
> There is bad advice for every framework/language that exists
I'm somewhat torn on this. I'm currently a JS dev, using React, and I have few complaints. In particular, without regard to the specific API, I think React promotes good models of thought and separation of concerns. It can definitely be done poorly, which can make it a pain to change, but as you say, that's true for anything.
BUT - Long ago I did a long stint as a Perl dev. Perl is somewhat infamous for the ease of writing terrible code. I can say with confidence that one can write solid Perl code that is easy to understand and modify. I actually credit the lessons I learned as a Perl dev for improving my code quality in all languages ever since, and there are expressive concepts in Perl that I wish would be implemented in other languages. That doesn't mean that the Perl community (and developers of the language itself) get to ignore that Perl was EASIER to write terrible code in - and in my opinion their(our) ineffectiveness at changing that reputation was as much to blame for the decline of Perl as the Perl 6 crawlout.
React is no Perl - I'm not trying to set up a strawman here. I'm just saying that "there is bad advice for every framework/language" can be true and still not contradict the concept that a reputation for problems warns/scares away devs. (That said, I think React isn't suffering that reputation, JS is)
> front-loads all of that overhead, which makes you handle it before you're even sure that you want to use a given tool in the first place.
Bang on. I not only found the same thing but found that the unknown potential complexities, as well as known complexities, outweighed the potential benefits. And since the potential benefits (React Native, primarily) are so great, that indicates a bit of an issue!!
How about: We hold developers responsible for the things they develop, which is what we've been doing all along?
PHP devs got well-deserved flak for a long time, not for the "crappy advice" (although there is plenty to go around), but for the language itself. That situation has improved, so yes, extend some courtesy.
React has done a pretty damn good job of looking at the "crappy advice" and treat it as pain point indicators, thus improving React further by fixing those. But you simply can't do that for everything, and a lot of the awful advice you find is what happens when you have a very low barrier of entry to both use something and give advice on it.
My uncle keeps telling me I'll get arthritis by cracking my knuckles. Do I blame my doctors because they don't go around actively and preventatively telling people that's not a thing?
I don't have a horse in this race at all, just noting the inconsistencies. Although the idea that React doesn't have some language "issues" is pretty amusing.
> "My uncle keeps telling me I'll get arthritis by cracking my knuckles. Do I blame my doctors because they don't go around actively and preventatively telling people that's not a thing?"
Really weird comeback at the end there. We do expect experts in various fields to work on educating the public, especially in regards to widely believed but inaccurate ideas.
> I don't have a horse in this race at all, just noting the inconsistencies.
PHP had some implementation issues that made the language god awful. Saying it's the same thing is a straw man.
> Really weird comeback at the end there. We do expect experts in various fields to work on educating the public, especially in regards to widely believed but inaccurate ideas.
They do, with their official docs, which are well-written. What, exactly, do you want them to do about third parties?
> "PHP had some implementation issues that made the language god awful. Saying it's the same thing is a straw man."
React does as well: JSX is a bad idea that's unfortunately not going anywhere. And I never said it was the same exact thing.
> "They do, with their official docs, which are well-written."
I was responding to the statement that field experts bear little responsibility to educating the general public on their fields of expertise, when in fact that is a key role experts play.
There is no absolute that says JSX is a bad idea. It's certainly not been established, and most people who say JSX is a bad idea are people who aren't familiar with the subject matter.
> I was responding to the statement that field experts bear little responsibility to educating the general public on their fields of expertise
My point is that regardless of whether they do (and most of them indeed do, React devs included), you shouldn't be blaming them for "not doing enough" in that regard. It's never going to be enough. That's the thing with experts: They're rare, otherwise they wouldn't be experts in their subject, they'd have the average amount of knowledge. There's always going to be less of them, thus it's harder to educate at scale.
> The React team can't be held responsible for the amount of crappy advice on the Internet
There is a lot of Rust evangelism on HN, but one ting they do seem to have grokked is that quality of documentation is important to building a userbase. If all that's out there are a series of out of date blog posts then that's the level of documentation.
Plus, I'm fairly sure I remember (but have no citation for) the Rust team reaching out to try and get the community to update old blog posts (or at least put in links to newer documentation).
It's not that the advice is necessarily 'crappy', it's more that it's no longer current. You might be looking at an article which is only a couple of months old but is already out of date because some lib (like react-router) has changed, or it's considered 'the wrong way' now (when it was 'the correct way' a couple of months ago).
Which is 100% on react-router. That has nothing to do with React. This would be akin to issues you have with some Ember plugin on the Ember team. It's odd.
In the space of making a single very simple tabbed app I found the need to use react router. I didn't want to have to "invent" a way to change urls on the fly so the back button would work. What happened with react for me was that there's no "common" pattern to perform basic tasks outside of popular libraries.
I've never understood the whole "Don't use Redux until you need it" idea. If you're building anything larger than a toy app, component state isn't gonna cut it, so you're better off structuring your app with Redux or MobX or something from the start than rewriting stuff to include it later.
Yes and no -- you could also get away with passing the state down from a higher-level component. This does break down quickly, but if your app isn't too complicated, it can be enough for the first version. (Certainly, if I was unfamiliar with React, I would try this before integrating another library like Redux.)
There's a difference between "don't try to learn Redux until you understand React", and "don't use Redux right away when you start building an app".
For most people, trying to learn to "think in React" is a pretty big jump, especially if they're coming from an imperative, jQuery-style background. Throwing in Redux's concepts at the same time is usually too much for most people, especially if they're relatively inexperienced programmers. So, the standard advice from both the React and Redux teams is to focus on learning React first. Once you have a good understanding of how React works, you will better appreciate why a state management library like Redux can be useful, and you can learn about other tools later.
On the other hand, if you are familiar with Redux, it does make a lot of sense to set it up from the beginning. I've been writing a tutorial series called "Practical Redux" ( http://blog.isquaredsoftware.com/series/practical-redux/ ) , which is intended to demonstrate a variety of useful React and Redux techniques in the context of a sample app. In that series, I create a new project using Create-React-App, and then immediately add Redux into it as a baseline.
Overall, what Dan is trying to push back against is the perception that you _must_ use Redux with React, or that you _must_ learn them both at the same time. Neither is true.
Honestly many developers don't have freedom to experiment with new things on their own. I got web project, I'm thinking, well, it's a good time to try out React, I've heard it's cool. I'm convincing my manager, if necessary and I'm starting to build production project without any prior React or Redux or whatever knowledge. I'm not going to do it step by step, no. I'm grabbing everything and trying to bundle it all together. I know, that my app will need state, so I'm using Redux. I know, that my app will need routing, so I'm using router. And my experience is similar to author's, I had a lot of troubles to even get build setup working. I guess, it's more about javascript development tools, not specifically about React, but point stands still. And if I'm understanding, that I just got buried under pile of things, I'll throw it out, rewrite everything on Angular I know and love and forget about it for a few years, until it matures and I could try it again, hopefully with less troubles.
If you've got a lot of free time and want to tinker a lot, that's a good advice. Pick simple project, make it with simplest setup, introduce additional dependencies, rewrite the project, and so on. But not everyone wants to learn without being paid for it.
I'd recommend pitching it to your manager as a one week spike, and if that goes well do a presentation on it and sell technical leadership on it from what you learned. Then you can add proper tooling. Make a few trade offs to save time as needed. That strategy worked for me.
Great advice, and well articulated. I'd add that if someone is coming from angular 1 or even has just built numerous single page apps, they will immediately see the benefit of a single source of truth client side data model.
For a simple CRUD application, there's not much wrong with just passing state down from a parent component. Eventually you end up abstracting and automating it; they're values, like everything else you program with.
Abramov has been beating this drum for a long time: there really are a lot of React apps that use Redux but really don't gain anything from it.
I really love Redux, and I use it for most things, but that is simply not true. Redux/MobX is a solution to the Angular 1-style issue where state is all over the place, but you sure can make full blown apps that way (it's not even a full solution, but rather a different set of tradeoffs...which is why a lot of people start using Redux then start pushing back in the other direction and you end up with a mess).
And even if you want to centralize state, with local state it's not even that hard to do yourself (put it at the top or in a few small containers, push everything down, have callbacks that bubble it back up. A bit verbose, but easy to abstract out, though you'll end up with something close to redux).
The main issue with all of this is that 95% of the stuff you read about all of it on the internet is wrong, namely because building a real app and maintaining it is very different from making a toy project or a Silicon Valley style MVP in 6 months. People optimize for the later, then when they start maintaining their app its shit. So all the info on the net helping you to reduce boilerplate, optimize for the first version, etc, is just hurting you (but its almost everything you find online)
I don't quite understand it either. React and Redux play nicely with each other but they are completely orthogonal. You can use one without the other, and I've seen Angular 2 developers use Redux to great effect. As Dan himself admits, Redux is inspired by Elm architecture and I personally find this approach extremely elegant. I admit it is demanding but it also forces you to put more effort into designing your application which in my experience is generally a good thing.
It's entirely possible I don't know what I'm missing and/or my React usage so far mostly falls in the "toy" scale, but I've not yet felt a need for Redux or another state management system. Our strategy so far involves very little use of component state (nearly all usage is for form fields and showing/hiding modals). Everything else is in the props, and all 'app state' lives in a collection of modules that get DI'd into the components via their props. It seems like it's probably not too far from what Redux is going for at a conceptual level, but so far it's worked well and been easy to work with.
We also use TypeScript though, so this more OO-style approach felt more natural. It's not particularly verbose (in the context of interfaces and static types, so YMMV) and it's been extremely easy to work with so far.
It's easy to counter criticism if your product has no canonical ways of doing anything. Just say the critics should use some other component or approach for every single thing they try to do. Of course, those other components/versions may have an entirely different set of issues, but since you don't have to deal with those yourself or consider trade-offs or even be consistent over time in your replies, you make the original point sound completely invalid. Just throw a bunch of options into the conversation and shift the burden of proof on the other guy. Yay.
I find it especially ridiculous when people use future versions of stuff to deflect high level criticism of some ecosystem as it is right now. It is one thing when the critic has a specific issue thar is a show stopper. It is an entirely different issue when someone describes their overall experience.
Gianluca Guarini is the maintainer of Riot.js. It's hard to believe he just naively tried React and this is what he came up with. Riots main page has more of these questionable comparisons.
This is worth noting primarily because the original almost got me: he kept mentioning Riot.js over and over, and I thought "huh...I haven't worked with that...I must be out of date."
Instead, this is a case of "I wrote a framework that works exactly the way I like it, and then used a framework that doesn't, so here's why the one that doesn't work the way I like is waaay worse than the one I wrote."
In the general case, this a big pain point for me. Having to wade through tons of shallow subjective "Well I like it" disguised as objective technical points can be very fustrating, especially when trying to learn something new and unfamiliar, such as my next major language or framework to learn or use.
Hat off for Dan, I wouldn't have that patience to explain and basically refute every claim from the former post. No framework/lib is perfect (for every job), that is the reason, we have so many. Critique is fine and necessary, but you should have quite a lot experience with the subject, or you might look "rookish" (as in this case). Sorry, but that guy did a really poor job criticizing react.
Off-topic, but can anyone explain why the comment system on Medium is so terrible? It always takes at least two clicks (and corresponding slow loads) to read a comment that you want to read.
> React 16 (work in progress) is a rewrite, but it has the same public API, and works with more than 30,000 (!) components at Facebook, so it will most likely work with your code too
This is uninformative without more context. Is he saying Facebook only had 30K components, and all of them worked with the new React? Or does FB have, say, 60K components and only 30K worked seamlessly on the upgrade?
I think the point is, they are testing it internally to ensure a minimal upgrade path. It works out of the box with 30,000 Facebook components right now. It's not released yet, so perhaps it will work with 100% on release, or 95% with a clear upgrade path on release.
You're point might be valid if this was software that's already available, but it isn't.
30k+ is the number of total components we have. Almost all of them worked without changes; most of the dozen or so components that needed changes were relying on unsupported, undocumented behaviors. About 99.9% of our components (literally) worked out of the box.
OT: When I tried Inferno as a drop-in replacement for React few months ago everything kept working fine. Inferno's author was hired by Facebook and some of his work might have been reused. Inferno was insanely fast and for me super compatible though missing some of the API.
I like Dan's answer and it shows that many are not really familiar with React and its trivial concept (like me before I tried). React is good and manageable even after a rewrite because it has a tiny API (compared to other frameworks/libs in this space).
"what do you expect from a framework with more than 1000 issues on github that will let you install alpha dependencies by default (React@16.0.0-alpha.6) to develop your native app?!?"
I'll answer it: When you become popular and have a lot of momentum, the Github issue tracker becomes extremely hard to manage. This is partly Github's fault as well (the tracker is optimized for small repositories and throwaway issues, which is also why I like it a lot).
This is aggravated in the JS world which is extremely Github-centric.
NodeJS: 730 open issues, 4323 closed issues, 324 open pull requests, 7201 closed pull requests: https://github.com/nodejs/node
React Native and React are developed by people who know each others' codebases pretty damn well. I trust them to know what's better for the end users; wouldn't you?
I admire Dan's patience and restrain. Personally, I see a paragraph like that original post scriptum, I dismiss the entire thing as a troll. The guy doesn't even talk about what problems he encountered with react native, he just says "Look! Lots of open issues, and big bad alpha software! What do you THINK happened, hmm?"
What I think happened is that he encountered maybe a couple of bugs and got pissed off at the whole thing, then tried justifying it with whatever strawman was readily available. Happens to me too. I get just as annoyed. I don't write articles shitting on the devs about it though, I generally file PRs to fix the bugs.
"Using it in production" is not the same thing as making it a dependency on master.
Also, you realize how silly that question is when the two programmers are actually one and the same, right? Like I said, there's nobody who knows the React codebase better than the React Native people.
Edit: You answered your own question better than I could have in your reply.
"This is intentional because the React Native releases follow the copy of RN in Facebook's repo, which also sometimes uses alpha versions of React. It is correct to depend on React 16 alpha 6."
"At times, React Native will depend on an alpha version of React – this happens in part due to the fact that RN has a more frequent release cycle than React itself, and that's the correct version to use when working with React Native.
We use alpha versions of React in production at Facebook so they should be pretty stable."
When did it become ok to use alpha versions in production? Or are they stable then? When did it become ok to call alpha something that is considered stable?
>The version of the `react` package is generally not relevant for React Native users because it contains very little code (`Component` and `createElement`). The reconciler code is synced to React Native separately. So this an artifact of the different release cycles of RN and React, and doesn’t at all mean that RN apps are using an unstable version of React. This is the same exact version we are using at Facebook in production. I agree it’s confusing though, and we hope to align the release process between React and React Native more closely in the future.
We develop React and test it on Facebook before making open source releases. In most cases, we update the version that Facebook is using every few weeks. Since they aren't full releases at that point, we call them alphas. They let us get a better appreciation for the issues that the new code may have and how hard it is to update before we make everyone in the community upgrade.
So (much like the OP), your non-answer is moving the goalpost and blaming something else, and even that only partially "addresses" the issue brought up? Seems appropriate.
I answered the matter of open issues, and I have enough experience in open source to back that up. There's not one issue brought up in the original post scriptum, there's two stitched together into a big fat strawman. Please voice your concerns about me only "partially" addressing anything to noreply@devnull.com.
This part of the original article was referring to React Native. React != React Native, they are two separate projects.
I realise that doesn't answer your question (which seems to be 'please justify React Native having a lot of open Github issues and being seemingly less stable than React') but it seems a bit misleading to conflate the two projects, and to expect the same amount of stability from each. React is a UI library. React Native comprises of a UI library, a JS <-> native binding system with wrappers for native APIs, a build system, and an implementation of CSS-like layout for native views. They are not really comparable.
Sorry, I should have said 'the question' rather than 'your question'. The original article attempted to pull in the author's issues with a bunch of React-adjacent technologies to what was purportedly a criticism of React, and I just wanted to make the point that this is needlessly muddying the waters.
There may be less headaches with riot.js, but Riot 3 was a rewrite of Riot 2, and Riot 4 is going to be another rewrite (https://github.com/riot/riot/issues/2283). I've been following Riot for a while, and I wouldn't call it stable either. But I do like riot's syntax and ease of use.
The React API is stable. There haven't been any major changes to its public-facing API in a long time. Third-party projects that you might also depend on are not always as stable but the React team has no control over that (and third-party dependencies don't have anything to do with React itself or fiber).
The core of React is the VirtualDOM and how it simplifies interaction with the hypermedia. React has gone way past that original simplification toward curing cancer or solving the faster-than-light-speed problem (take your pick). This shazz should have been a separate effort.
Most of the original criticisms centers around NPM, which belies the hell that is JavaScript. Since everyone compiles JS anyway, we should stop writing in it altogether. Pick some other language ecosystem that transpiles to JS. Delenda Est NPM.
It's often seen as an advantage of React that it's just a view library and not a framework. But if you want to build any reasonable kind of modern web app, you'll need those extra elements like routing and state management. You effectively must piece together your own framework and the cognitive overhead of this is huge. At least for the first time anyway.
> Create React App is a thin layer on top of Webpack and Babel. It doesn’t generate the project code for you, but it configures those tools in the recommended way.
TIL. I've been manually setting up my own configs for years now, and never touched this tool because I thought it was literally creating a sample/boilerplate app for you much like the express.js cli generator.
Yeah, CRA really isn't a "boilerplate". It's a prepackaged build system that can be upgraded. It doesn't come with dozens of app-level dependencies already installed and custom-configured, like most boilerplates do.
Overall, CRA serves three primary purposes: it allows React learners to set up an environment without having to learn Webpack and Babel first; it allows experienced React devs to spin up a project without having to do all the configuration work (or copy and paste it from somewhere); and it also provides a common starting point for instructions and tutorials. For example, my recent blog post on using the Cesium.js 3D globe library with Webpack and React ( http://blog.isquaredsoftware.com/2017/03/declarative-earth-p...) was able to start by just saying "Create a CRA project, eject, and modify these two config values".
Am I wrong to feel that this response is written a bit flippantly? Of course, it's his personal blog, but considering he's writing as a member of the React team (and seemingly writing on their behalf as he includes the word "we" in the second sentence) it really feels a bit unpolished and disrespectful. The use of emojis is really strange, and reading phrases like, "How many components do you have," and quoting "skeptical" and "doing your job," reads defensively and sarcastically, not something I want to see in a public post from a React dev member.
A bigger concern for me is the grating cheerfulness in what is a very critical article.
Don't pretend you're not fighting fire with fire with this article. You're mad and you're showing it. When you say stuff like...
>>To sum up, I love that you brought up these concerns in an article.
I don't believe you! Disingenuous.
(You should also think about whether or not the Riot.js author is worth responding to. Just because he's a framework author doesn't mean that framework has ever been held in high regard.)
My motivation was to address common misconceptions around React ecosystem. I'm genuinely happy people bring them up (since that's how we learn about the issues).
To me, reading posts filled with frustration serves as a motivation to improve things. I didn't reply to "fight with fire": I see these kinds of posts every week or two. But I replied this time because I think it was also important to separate real issues from the factual inaccuracies (that get a life of their own once somebody writes an article).
Some bitterness did come through, and I removed it. But I'm not lying when I tell you I'm happy people are sharing their concerns with React. It's all for the best. :-)
this is your opportunity to pointedly not listen to criticism about the React ecosystem, which you are taking in full.
if you were really motivated to improve things you wouldn't need to write a defensive article.
you and your team will continue on your status quo. why?
because you're not able to fix the problems with react router. you're not able to solve the MVC/total solution ecosystem conundrum React has.
you're completely unable to address the core criticisms of the critical article. better to admit that than pretend.
so what we have here is another technologist fighting with mud while loudly proclaiming that they're not fighting, we're all friends, 'it's all for the best.'
Hey Dan, thanks for replying back to me! The main reason that I felt it was strange was that it didn't feel like your personal post, which I feel warranted more professional/reserved writing. The way the current post is written is a lot better (it also does feel more like a personal blog post now), and I appreciate you took the time to rewrite it when you didn't have to. It really has a different tone now, and now that feels a lot less defensive and flippant wrt the original post. Thanks for all the work on React, excited to check out React 16!
I don't see it as disrespectful in the slightest. It looks like a response to some strawman arguments (eg. React 16 being a complete rewrite) and obvious but rather minor things (eg. className).
Also, if I understand it correctly, the original author is a maintainer of a competing framework, heavily inspired by React. So, this is not exactly an impartial account of an 'experienced dev'. Maybe I'm reading too much into that but it's not something I like seeing in the FOSS world.
I'm having trouble understanding what this accomplished, other than making the react (or I guess redux in this case) team look petty.
I agreed with the original post and this reply didn't sway me. I see in this thread that people who had already disagreed with the original post agreed with this, as expected.
Seriously, nobody not called Linus Torvalds should be writing direct replies to criticism of their technology in blog posts (and he's the only exception because reading his replies is very entertaining).
Yes, people like their technology and like how it is, it makes sense for them but, that's not universal; so addressing criticism (even as an attempt of countering the criticism) only legitimizes it.
If one doesn't want to acknowledge that one's technology is not for everyone... one is better off not acknowledging it, in any way; doing otherwise puts that shortsightedness in evidence.
Thanks for feedback, I just edited to include the reason I wrote this:
>Your post includes a lot of misconceptions commonly held in the React community, so I wanted to take a moment to clarify them for everyone else who has the same concerns.
I didn't reply to many similar posts before, but I felt like this is a good opportunity to jump in and provide some clarifications because there are some factual misconceptions in the post. When unaddressed, these tend to keep spreading and get a life of their own.
Also, we do take this feedback to the heart. In fact we spent time developing Create React App precisely thanks to feedback like this.
>If one doesn't want to acknowledge that one's technology is not for everyone.
We totally acknowledge React is not for everyone! I touched on this in the last paragraph, but it wasn’t the focus of my article. I do try to stress it when comparing React to other libraries in general, but this seemed like a React-specific post.
As a React developer, I also raised an eyebrow at the misconceptions given in the original article. (The worst, IMO, was definitely the part regarding Create React App and the overall toolchain).
I appreciate your take on the article and felt that you did a good job focusing on these issues, whereas someone like myself would've been a bit more biting in my response.
Replying at all and in such a passive aggressive tone is petty. If you're confident in your technology (and people making something as widely used as react/redux ought to be confident), you can let it speak for itself.
As for how much this actually set the record straight or how much the original post was false information, I guess I'll have to disagree.
Nothing in the original post was false per se, and I, for one, agreed with everything in it, every time I've tried to get into react since it was launched and it's always the same annoyances. It's just not for me and it's not for the author of the original post.
Two different points in OP's reply were "well yeah, but it'll be different in the next version/future!" (amusingly, another point was "well, just don't use the new version!") which means that the original post was... right.
"I started my app with React 15.5.0 knowing that my code is deprecate before even starting" (addressed by dan)
"in mobx you can prefix your store actions but “it’s just for the glam” because it won’t preserve overriding any observable property of your store as it was a normal object store.message = ‘hello’ from any component of your application!?!" (strict mode, right there on the page he even links to)
"React-router is not officially maintained by facebook and the maintainers had the great idea of bumping 3 major versions in 5 months completely not backward compatible to each other" (in the link he provides, you can see version 4 was released 03.2017, version 3 was released 10.2016, version 2 was released 02.2016. Even a charitable reading of "bumping 3 major versions" doesn't get you to 5 months)
I could only find one more assertion of fact, rather than opinion, which happens to be right:
"Once I understood what was the issue I was dragged into the rabbit hole being forced to add empty divs all over the place to let my app work properly"
> "I started my app with React 15.5.0 knowing that my code is deprecate before even starting" (addressed by dan)
If you buy into the fairy tale that a complete rewrite isn't going to break anything, all the power to you. I don't, and have no reason to, I've experienced it first hand what such a major change causes. So, not incorrect.
> "in mobx you can prefix your store actions but “it’s just for the glam” because it won’t preserve overriding any observable property of your store as it was a normal object store.message = ‘hello’ from any component of your application!?!" (strict mode, right there on the page he even links to)
So... it is possible but not when done a certain way? How that does make the point false? "well duh, you're using react wrong!" doesn't help react and doesn't address the criticism.
If it allows to do something, it does, and so it can be used to make bad code, which is where every criticism of every language/framework ever originates; none of it invalid.
That's just things one learns to live with, none of the tools we use is perfect.
> "React-router is not officially maintained by facebook and the maintainers had the great idea of bumping 3 major versions in 5 months completely not backward compatible to each other" (in the link he provides, you can see version 4 was released 03.2017, version 3 was released 10.2016, version 2 was released 02.2016. Even a charitable reading of "bumping 3 major versions" doesn't get you to 5 months)
... Except it does? At the start of October, the official version was 2; at the end of March, it was 4. That's three different versions in five months.
I gotta thank you for this one, because it precisely requires a very charitable reading of that.
And even a strict reading gives us two major versions in five months, hardly all that much better.
I'm sorry this is the impression my post has left for you. Could you clarify which parts you see as petty so I could further work on them?
I thought it was important to clarify the factual mistakes (such as the misconception about React rewrite), as these tend to keep spreading once they're mentioned in a few articles.
But I see now that I might have chosen the wrong venue and format to address them, as framing it as a response makes it seem personal. That wasn't my intention.
This post does a great job refuting minor points while completely ignoring the central arguments of the original.[1][2] The React TodoMVC weighs some 451 lines -- more than vanilla JS, jQuery, and over twice as much as Vue.
There are weird incentives in software ecosystems. Companies benefit by controlling one because they can hire easily, and ensure their code & tools will not become obsolete. And the more complex ecosystems become, the harder it is for devs to compare them or switch. I think there were similar forces at work in the UIs of large GUI applications like DAWs. Once you get through the painful learning process, you find you love it, and find it impossible to switch -- a phenomenon that has attracted comparisons to Stockholm syndrome.
React's benefits come through more at scale. If you just want to add a bit of interactivity to a page, sure, jQuery is going to be fewer LOC and KB. If you're trying to write a large full-blown application that's 10K, 50K, 100K LOC, with tons of views and lots of data to manage, jQuery won't cut it. React helps you build the UI in manageable, understandable, reusable pieces.
A valid point, but TodoMVC is enough of an app that I feel we shouldn't be multiplying jQuery by 2. No larger benchmarks exist, but I'm reasonably confident React would still be substantially larger than e.g. Riot, Vue, or Svelte. And yes, conventions have value, but it's a zero-sum kind of value that comes at the expense of all other possible conventions.
> we don't think size in raw lines of code is the most important metric in the code
I've read this claim from FB before (Pete Hunt I think). It's not possible to overstate my disagreement.
I guess if you want to say, 'people in general can't program, but they can plumb things together, and once they learn the conventions the boilerplate becomes transparent', I wouldn't argue. But you haven't said it, and it's not a direction I think is so great for software.
In the future we want one-line applications, right? "Siri, create a calendar app with conflict resolution for the local Owl's club." Not four pages of "Siri, open angle-bracket props colon..."[1]
Re. Vue, I'm sorry I mentioned it. I don't have a horse in the race. However if I did I would definitely have taken the time to try Vue by now. And likewise Guarini, if this is really his first time trying React, has not done basic due diligence by waiting this long.
We can't improve as a field unless we compare results. That TodoMVC is the only benchmark that even exists is unfortunate.
I think the point is that LOC is a bad metric in general. In the same way that you wouldn't want to measure a dev's output by LOC/day, just comparing LOC for a small task isn't really meaningful. That approach can be heavily gamed (see code golfing), and there's the apples/oranges aspect as well.
jQuery is meant for manipulating arbitrary DOM nodes in a page. Assuming they share a classname, I can hide a dozen divs scattered throughout the page with a single `$(".myClass").hide()`. In React, I'd probably need to pass some state through several components, and ultimately re-render, which would be considerably more LOC.
Does that mean that React is "worse"? No. It means they're meant for different kinds of tasks. React is meant for making codebases maintainable and understandable. Sure, fewer LOC is _usually_ a good thing, but many times being more explicit makes a codebase more maintainable.
"you must use className instead of class to define the DOM css classes" - op
"You are completely right it’s annoying. It’s one of those early design decisions to align better with the DOM APIs that has proved to be confusing. We might change this in the future." - dan
i appreciate dan's honesty here. it was little things like this made the framework look a bit immature and rushed but glad to know these are in the horizon to be improved on.
What React is missing is a set of idioms and patterns. When you inherit Angular or Django project it's quite easy to understand it and be productive if someone follows the philosophy.
Create-React-App is a great step, but what next? How to handle AJAX and state if I have a simple app and don't really need Redux. How to structure it so it would be easy to add it.
There _are_ many patterns that exist already, and have been widely discussed in the React world (such as "Higher Order Components" for code reuse).
You may be interested in several of the sections in my React/Redux links list at https://github.com/markerikson/react-redux-links . In particular, check out the "React Architecture", "React Component Patterns", "React State Management", "React and AJAX", "Redux Architecture", and "Project Structure" sections.
To pick out a few specific links related to your questions:
Is there a great mid-size open-source project that was created with Create React App? Any input on UI frameworks? I'm currently using React-Bootstrap, but I'm thinking about using Material-UI.
Mmm... not sure about apps specifically built with CRA. I do have a list of a few selected interesting-looking apps built with Redux (and React) in my Redux ecosystem catalog [0] . Haven't updated that section in a while, though, and it's definitely not comprehensive, but there's a useful variety of apps to look at.
I personally am using Semantic-UI-React [1] in a work project, as well as in the sample app for my "Practical Redux" tutorial series [2] [3]. I also frequently recommend a tutorial series called "Building a Simple CRUD App with React + Redux" [4] as another "real-world" tutorial/example. That tutorial doesn't use CRA, but my "Practical Redux" sample app does.
The best solution would probably be to bubble up state mutations to a single place per data model area, and factor out the http calls per data model area, grouping as needed. I'd rather just use redux with thunks that use async/await though personally than write this from scratch.
198 comments
[ 2.8 ms ] story [ 224 ms ] threadBut my favorite part: The next React will allow returning an array of components without a div wrapper. Small change, but it annoyed me to no end that it wasn't already possible.
I only ask out of curiosity, it'd be good to know how FB approached testing as a data point on a major company's approach (vs. say Google)
There is unfortunately a lot of FUD that has been spread around React in general, the React ecosystem, and the upcoming React Fiber rewrite. It's a combination of longstanding complaints like "HTML in my JS? EWW!", concerns about build tools like Babel and Webpack, badly written articles and headlines like the recent TechCrunch post that claimed "React Fiber is a complete change that Facebook has never talked about", and of course lots of arguments in comment sections.
If someone has taken time to evaluate React and determined that it's not for them, that's totally fine. But, when poor articles get upvoted and spread widely, it doesn't help anyone.
Regarding the motivation, it wasn't to defend any decisions. I'm sorry I didn't make this clear enough. The motivation for replying was to highlight some factual inaccuracies that have started to gain traction. I see posts like this every other week, and I've noticed a few incorrect points shared between them, so I felt this is a good time to jump in and help clarify them. I could've done it in a better way though.
I added these two paragraphs:
>Your post includes some misconceptions commonly held in the React community, so I wanted to take a moment to clarify them for everyone else who has the same concerns.
>That is not to say that React works well for everyone, or that the issues raised are not valid. But there are a few facts that I think are important to get right before considering those problems.
Left a bad taste in my mouth when I finished reading it.
I can understand the author's frustration when the user's criticism is unfounded in many areas but his points could've been made without the tongue in cheek comments.
It's a double standard for sure, but it's the same concept as when you're responding to a potential troll on social media. You don't want to add fuel to the fire.
In all fairness, I wanted to make sure your points were heard clearly and I felt the tongue in cheek comments distracted from the clear explanation of how the author was offbase and incorrect.
Looking forward to the future releases of React!
I'm sure Dan would have done nothing with it, had the HN community not upvoted the original post through the roof.
I edited the post, is it better now?
React is great, and judging by the growing ecosystem, many people agree. If you don't like it because it requires you to learn a workflow you are unfamiliar with, don't use it.
Unrelated to the technical side (which I haven't investigated in much depth yet as a third party to this discussion), I don't like it because of the patent license, which AFAICR is a valid concern for a non-trivial number of large firms.
https://github.com/facebook/react/blob/master/PATENTS
https://github.com/developit/preact
I can look at external analyses, but the firms I've spoken with have had their own IP folks examine it and have each made their own decisions, so I'm merely parroting the accounts of those I've spoken to.
Edit: my initial comment (thread root) sits in the negatives but this one is high in the positives. It's interesting observing what I can only conclude is a proxy battle between the technical crowd and the crowd that understands legal realities.
https://github.com/Microsoft/react-native-windows
https://microsoft.github.io/code-push/
https://mspoweruser.com/skype-is-testing-a-new-android-app-w...
But, React is still just another tool in our toolboxes.
If we're building prototypes or short-term apps, slap it together with whatever tool is fastest for you. If we're engineering something that needs to last and provide a great experience, it's important to know when to use a Philips head screwdriver versus a flathead, or either, or when we really just need a hammer.
However, my websites tend to be backend heavy and front-end light... no more interactive than Reddit.
https://github.com/Rajeev-K/mvc-router
Note that using MVC does not imply 2-way binding!
I keep seeing this pattern of redux as a page-level data store, whereby on each page load you pull your data from rest APIs, put it in that page's part of the data store, to be modified with that page's reducers, triggered by that page's action creators. Then it's all hooked up to one single page-level connected component which passes all the state down to other components as props anyway, making it functionally identical to just using the React state in that page component.
The justification for this is usually either "Now you can make your page components pure functional components!" (whooptee-do) or "Redux scales better" (citation needed). Pretty thin.
Because that's what easily-excited developers see on HN and Twitter, so they think they have to use it.
If you're using the words "like" or "cool" to describe your latest dependency then that's a serious red flag. These libraries exist to solve problems, if you can't describe the problem you're trying to solve with one of them then you shouldn't be using it.
There _are_ definitely a number of benefits to using Redux in a React app. I actually co-authored an article that discusses some of them: https://www.fullstackreact.com/articles/redux-with-mark-erik... . TL;DR: time-travel debugging and better hot reloading for development, easier management of data that needs to be used in multiple places throughout the component tree, and all the niceties of having centralized state (logging, state persistence, issue reporting, etc).
The pile o' reducers thing just isn't a very useful way to organize code IMO, and having everything split over several files makes following what's happening a PITA (especially without something like Typescript to let your tools give you the information you need, rather than having to keep it in your head or go look it up manually).
Redux feels... not over-engineered, exactly, but maybe mis-engineered.
... or we could just cut out the middleman and go all Actor model on this problem. Just sayin'. (yes, I know there are actor-model libs for React out there, but frankly the churn-related breakage and confusion in the most popular tools is so bad I'm afraid to step outside the mainstream, where it's probably even worse—plus we don't get to choose our own libs/patterns all of the time)
There's definitely several different schools of thought about how to organize and structure Redux-based code. Dan is a big fan of the "small independent slice reducers responding separately to the same action" approach. Others prefer to see all possible state changes for a given action in one place. And yes, while the intended use of Redux is based on functional programming, there's also those who prefer putting OOP layers on top.
I'm actually working on a blog post that will try to clarify and discuss what actual technical limitations Redux requires of you, vs how you are _encouraged_ to use Redux, vs how it's _possible_ to use Redux. Been busy with other stuff, but hoping to make progress on that post this week. If you're interested, keep an eye on my blog at http://blog.isquaredsoftware.com .
You may also be interested in an issue I recently opened to discuss possible future improvements and "ease-of-use" layers that could be built on top of the Redux core: https://github.com/reactjs/redux/issues/2295 .
Finally, I'm always happy to chat about Redux (and React) over in the Reactiflux chat channels on Discord. The invite link is at https://www.reactiflux.com . Feel free to drop by and ping me.
I thought the same thing. That's why I started using VueJS with Vuex. Vuex accomplishes the same things as redux in a much more manageable and centralized manner. Plus, you don't have to worry about connecting your components to the store through `react-redux` or whatever. With Vue and Vuex, you just pass the store object to the root view component and it's available in every single child component via `this.$store`. You can then `dispatch` actions which perform `commits` which call `mutations` which update the state. Then, in your component you create a computed property that uses a `getter` to return the piece of application state you want. It's a really simple top down data flow and everything is namespaced. It's so absurdly simple and easy that I don't understand why redux doesn't take a page from vuex's book.
I really should write a Vue + Vuex tutorial for beginners as I'm super happy with the way it works.
There are very different semantics at work there though. Elm is Fractal, Redux is not. Each have tradeoffs. Some stuff gets simpler, some stuff gets harder (the 1:1:1 scenario where you have a component, an action, and a reducer to achieve 1 thing gets easier. The N to N to N scenario where a reducer can handle things from all over the system, gets harder).
It's not misengineered, its just optimized to make a different set of problems easier at the cost of making others harder.
Also, I keep a big list of links to high-quality tutorials and articles on React, Redux, and related topics, at https://github.com/markerikson/react-redux-links . Specifically intended to be a great starting point for anyone trying to learn the ecosystem, as well as a solid source of good info on more advanced topics. It includes links for learning core Javascript (ES5), modern Javascript (ES6+), React, and much more. I also published an "Intro to React (and Redux)" presentation at http://blog.isquaredsoftware.com/2017/02/presentation-react-... , which is a good overview of the basic concepts for both React and Redux.
As a short version: you _can_ put your async logic right into components, but it's nicer to move that logic outside components for reusability. Middleware have access to `dispatch` and `getState`, so they act as a loophole that enables you to perform async work and then interact with the store.
My own take is that `redux-thunk` is sort of the "bare minimum" approach to async behavior, as it allows you to do stuff with promises and async functions, or complex synchronous logic. Sagas are useful for complex async workflows, and there's also some popular observable-based side effects addons as well. Ultimately, the approach you use is up to you.
If you'd like more info on what good Redux code structure looks like, you may want to read through the "Redux Architecture" and "Redux Techniques" section of my React/Redux links list at https://github.com/markerikson/react-redux-links/blob/master... . Also happy to answer any questions you might have.
The no frills way I like to think about redux is your rendered page is the result of a function operating on a state object. Changes to the state object trigger re-renders. There's obviously some subtleties in there and complex use cases, but that's the basic gist.
Redux is a modern implementation of CQRS/Event sourcing, a design pattern that existed before you even started coding. Many developers, in different languages, learned it and used it (if you want to implement an undo stack for instance, there is not a lot of other solutions around). Trust yourself and your intelligence. Our devs learn it in about 3h with our training program and get a return on investment in about a week.
MobX is nice and if it fits you, go for it. If you are a hands-on kind of guy, you may discover the limits of MobX by using it, and from the trenches finally understand why Redux, and why does it need 3 objects (a store, a reducer, an action).
As far as I can tell, that's it.
For bad reasons they've decided to stick with the terrible "action" name for their events/messages, which has made the whole thing super confusing (turning "actionCreator" into "eventCreator" immediately makes things much clearer, for instance).
There's also a ton of convention/process taught on top of it for some reason that's IMO not that great, and makes it really hard to see what's actually part of Redux and what's cruft on top of it that you can skip/modify. Redux-as-typically-presented is mostly you doing stuff to follow a (kinda painful) pattern, not the Redux library helping you do stuff.
[EDIT] I'd add that the communication pattern of the docs and various attempts to help people understand Redux seems to largely be "oh, you didn't get it? Let me say the same thing again but louder". Which is why there's SO MUCH documentation and chatter for something fairly simple, I think. Which just compounds the problem.
You are right that the majority of usage is really at the user level, than the library level. I'm actually working on a blog post that will try to clarify and discuss what actual technical limitations Redux requires of you, vs how you are _encouraged_ to use Redux, vs how it's _possible_ to use Redux. Been busy with other stuff, but hoping to make progress on that post this week. If you're interested, keep an eye on my blog at http://blog.isquaredsoftware.com .
If you have concerns with the docs, I'd appreciate any specific suggestions or ideas you might have for improving them. Docs issues and PRs are absolutely welcome, from you or anyone else who wants to help improve them.
Finally, I recently opened up an issue to discuss possible future improvements and "ease-of-use" layers that could be built on top of the Redux core: https://github.com/reactjs/redux/issues/2295 . Would be happy for any feedback you could offer.
(edit: just noted I replied to you a couple different times in this thread, and repeated myself a bit. Offer of discussion absolutely still stands :) )
[1] https://github.com/insin/babel-plugin-react-html-attrs
The guy used Redux, I'm sure, because he knew he needed to manage state somehow - and the articles he found probably pointed him there (rather than vanilla component state)
He knew he wanted some sort of routing system, found react router, was got a bit scared by how quickly it has been moving lately - and also, likely, how many existing articles about it are somewhat outdated
Etc
I do think it's important to consider, however, that — contrary to the belief that React.js is a cesspool of anti-patterns — that we're actually watching creative destruction at it's best.
Yes, libraries are moving fast and breaking things. Yes, competitive solutions are releasing at breakneck speeds. But that's more or less what happens when you reinvent the way people build things, as happened with the virtual dom.
And while we're paying for it in up-front build setup, we're vastly making up for it where it counts: JS applications that can grow big (at least I am).
The React team can't be held responsible for the amount of crappy advice on the Internet. And cognitive overhead is the nature of the beast with all frameworks. Nobody is going to launch an Angular/Ember app without a significant amount of research. Hell, Rails barely requires any knowledge of Ruby at all, since it's effectively its own ecosystem.
The React team should not be held responsible, but these problems do warn people to stay away from the React ecosystem. If the React team doesn't want people to stay away, it's in their interest to do something about it.
> And cognitive overhead is the nature of the beast with all frameworks.
It is, but they vary wildly in (a) the total amount of cognitive overhead required, and (b) whether you need to deal with that overhead before you even begin, or slowly, over time, as you develop your app. Modern JS development front-loads all of that overhead, which makes you handle it before you're even sure that you want to use a given tool in the first place.
No they don't. There is bad advice for every framework/language that exists. Following bad advice means carefully trusting sources. It is 100% on the user to determine whether an article applies, or it's plain wrong.
> If the React team doesn't want people to stay away, it's in their interest to do something about it.
Do what exactly? Start sending take-down notices for poorly written articles? Would you use a chainsaw to make a miniature, and then saw the chainsaw manufacturers need to "do something about it"?
People are so weird about frameworks.
You're not wrong, but isn't it especially difficult for an inexperienced person to judge whether an article applies?
It is. But nobody has the time or patience to determine that for every article, so if the React team wants people to use React, then it's in their interest to insure good articles about React are easier to find than bad articles about React.
> Do what exactly? Start sending take-down notices for poorly written articles?
Write good articles & tutorials, as well as share & popularize the good articles that are out there. Ask the companies that use React talk about React and how it solves their problems. If developers like starter kits & scaffolded projects, then write some good ones and toss them up on Github. Make sure the message that they want to get out doesn't get buried under all of the poorly written cruft out there.
They're under no obligation to do any of this, but nor are most developers under any obligation to use React. If they want people to use React, and the message that React is a good, easy framework to use is getting lost, then... well, how do you think that's going to end up?
Or to put it another way: there are a lot of JS frameworks out there. React needs developers to use it, more than those developers need to use React specifically. So they should be willing to do some of the heavy lifting needed to attract people; moreso if there's a negative message already out there.
I'm somewhat torn on this. I'm currently a JS dev, using React, and I have few complaints. In particular, without regard to the specific API, I think React promotes good models of thought and separation of concerns. It can definitely be done poorly, which can make it a pain to change, but as you say, that's true for anything.
BUT - Long ago I did a long stint as a Perl dev. Perl is somewhat infamous for the ease of writing terrible code. I can say with confidence that one can write solid Perl code that is easy to understand and modify. I actually credit the lessons I learned as a Perl dev for improving my code quality in all languages ever since, and there are expressive concepts in Perl that I wish would be implemented in other languages. That doesn't mean that the Perl community (and developers of the language itself) get to ignore that Perl was EASIER to write terrible code in - and in my opinion their(our) ineffectiveness at changing that reputation was as much to blame for the decline of Perl as the Perl 6 crawlout.
React is no Perl - I'm not trying to set up a strawman here. I'm just saying that "there is bad advice for every framework/language" can be true and still not contradict the concept that a reputation for problems warns/scares away devs. (That said, I think React isn't suffering that reputation, JS is)
Bang on. I not only found the same thing but found that the unknown potential complexities, as well as known complexities, outweighed the potential benefits. And since the potential benefits (React Native, primarily) are so great, that indicates a bit of an issue!!
Do we extend this same courtesy to the PHP team? Or do we treat it as indicative of something?
PHP devs got well-deserved flak for a long time, not for the "crappy advice" (although there is plenty to go around), but for the language itself. That situation has improved, so yes, extend some courtesy.
React has done a pretty damn good job of looking at the "crappy advice" and treat it as pain point indicators, thus improving React further by fixing those. But you simply can't do that for everything, and a lot of the awful advice you find is what happens when you have a very low barrier of entry to both use something and give advice on it.
My uncle keeps telling me I'll get arthritis by cracking my knuckles. Do I blame my doctors because they don't go around actively and preventatively telling people that's not a thing?
> "My uncle keeps telling me I'll get arthritis by cracking my knuckles. Do I blame my doctors because they don't go around actively and preventatively telling people that's not a thing?"
Really weird comeback at the end there. We do expect experts in various fields to work on educating the public, especially in regards to widely believed but inaccurate ideas.
PHP had some implementation issues that made the language god awful. Saying it's the same thing is a straw man.
> Really weird comeback at the end there. We do expect experts in various fields to work on educating the public, especially in regards to widely believed but inaccurate ideas.
They do, with their official docs, which are well-written. What, exactly, do you want them to do about third parties?
React does as well: JSX is a bad idea that's unfortunately not going anywhere. And I never said it was the same exact thing.
> "They do, with their official docs, which are well-written."
I was responding to the statement that field experts bear little responsibility to educating the general public on their fields of expertise, when in fact that is a key role experts play.
> I was responding to the statement that field experts bear little responsibility to educating the general public on their fields of expertise
My point is that regardless of whether they do (and most of them indeed do, React devs included), you shouldn't be blaming them for "not doing enough" in that regard. It's never going to be enough. That's the thing with experts: They're rare, otherwise they wouldn't be experts in their subject, they'd have the average amount of knowledge. There's always going to be less of them, thus it's harder to educate at scale.
JSX is syntactic sugar. That's it. Not a bad idea by an stretch.
There is a lot of Rust evangelism on HN, but one ting they do seem to have grokked is that quality of documentation is important to building a userbase. If all that's out there are a series of out of date blog posts then that's the level of documentation.
Plus, I'm fairly sure I remember (but have no citation for) the Rust team reaching out to try and get the community to update old blog posts (or at least put in links to newer documentation).
In my experience whenever you start dealing with state you need it. Which is in fact quite early in the project.
For most people, trying to learn to "think in React" is a pretty big jump, especially if they're coming from an imperative, jQuery-style background. Throwing in Redux's concepts at the same time is usually too much for most people, especially if they're relatively inexperienced programmers. So, the standard advice from both the React and Redux teams is to focus on learning React first. Once you have a good understanding of how React works, you will better appreciate why a state management library like Redux can be useful, and you can learn about other tools later.
On the other hand, if you are familiar with Redux, it does make a lot of sense to set it up from the beginning. I've been writing a tutorial series called "Practical Redux" ( http://blog.isquaredsoftware.com/series/practical-redux/ ) , which is intended to demonstrate a variety of useful React and Redux techniques in the context of a sample app. In that series, I create a new project using Create-React-App, and then immediately add Redux into it as a baseline.
Overall, what Dan is trying to push back against is the perception that you _must_ use Redux with React, or that you _must_ learn them both at the same time. Neither is true.
If you've got a lot of free time and want to tinker a lot, that's a good advice. Pick simple project, make it with simplest setup, introduce additional dependencies, rewrite the project, and so on. But not everyone wants to learn without being paid for it.
Abramov has been beating this drum for a long time: there really are a lot of React apps that use Redux but really don't gain anything from it.
And even if you want to centralize state, with local state it's not even that hard to do yourself (put it at the top or in a few small containers, push everything down, have callbacks that bubble it back up. A bit verbose, but easy to abstract out, though you'll end up with something close to redux).
The main issue with all of this is that 95% of the stuff you read about all of it on the internet is wrong, namely because building a real app and maintaining it is very different from making a toy project or a Silicon Valley style MVP in 6 months. People optimize for the later, then when they start maintaining their app its shit. So all the info on the net helping you to reduce boilerplate, optimize for the first version, etc, is just hurting you (but its almost everything you find online)
We also use TypeScript though, so this more OO-style approach felt more natural. It's not particularly verbose (in the context of interfaces and static types, so YMMV) and it's been extremely easy to work with so far.
I find it especially ridiculous when people use future versions of stuff to deflect high level criticism of some ecosystem as it is right now. It is one thing when the critic has a specific issue thar is a show stopper. It is an entirely different issue when someone describes their overall experience.
Instead, this is a case of "I wrote a framework that works exactly the way I like it, and then used a framework that doesn't, so here's why the one that doesn't work the way I like is waaay worse than the one I wrote."
This is uninformative without more context. Is he saying Facebook only had 30K components, and all of them worked with the new React? Or does FB have, say, 60K components and only 30K worked seamlessly on the upgrade?
You're point might be valid if this was software that's already available, but it isn't.
means basically that it is working like previous versions and if not then there is simply a bug
I like Dan's answer and it shows that many are not really familiar with React and its trivial concept (like me before I tried). React is good and manageable even after a rewrite because it has a tiny API (compared to other frameworks/libs in this space).
https://medium.com/@gianluca.guarini/things-nobody-will-tell...
"what do you expect from a framework with more than 1000 issues on github that will let you install alpha dependencies by default (React@16.0.0-alpha.6) to develop your native app?!?"
This is aggravated in the JS world which is extremely Github-centric.
NodeJS: 730 open issues, 4323 closed issues, 324 open pull requests, 7201 closed pull requests: https://github.com/nodejs/node
Ansible: 1863 open issues, 9204 closed issues, 1084 pull requests, 11762 closed pull requests: https://github.com/ansible/ansible/issues
I admire Dan's patience and restrain. Personally, I see a paragraph like that original post scriptum, I dismiss the entire thing as a troll. The guy doesn't even talk about what problems he encountered with react native, he just says "Look! Lots of open issues, and big bad alpha software! What do you THINK happened, hmm?"
What I think happened is that he encountered maybe a couple of bugs and got pissed off at the whole thing, then tried justifying it with whatever strawman was readily available. Happens to me too. I get just as annoyed. I don't write articles shitting on the devs about it though, I generally file PRs to fix the bugs.
Also, you realize how silly that question is when the two programmers are actually one and the same, right? Like I said, there's nobody who knows the React codebase better than the React Native people.
Edit: You answered your own question better than I could have in your reply.
source: https://github.com/facebook/react-native/issues/13291
"At times, React Native will depend on an alpha version of React – this happens in part due to the fact that RN has a more frequent release cycle than React itself, and that's the correct version to use when working with React Native. We use alpha versions of React in production at Facebook so they should be pretty stable."
source: https://discuss.reactjs.org/t/why-does-reactnative-0-43-inst...
When did it become ok to use alpha versions in production? Or are they stable then? When did it become ok to call alpha something that is considered stable?
If this thread is any indication, members of the react (et al) team frequent this place so I hope one of them can clear this doozy up.
>The version of the `react` package is generally not relevant for React Native users because it contains very little code (`Component` and `createElement`). The reconciler code is synced to React Native separately. So this an artifact of the different release cycles of RN and React, and doesn’t at all mean that RN apps are using an unstable version of React. This is the same exact version we are using at Facebook in production. I agree it’s confusing though, and we hope to align the release process between React and React Native more closely in the future.
https://en.wikipedia.org/wiki/Software_release_life_cycle
I realise that doesn't answer your question (which seems to be 'please justify React Native having a lot of open Github issues and being seemingly less stable than React') but it seems a bit misleading to conflate the two projects, and to expect the same amount of stability from each. React is a UI library. React Native comprises of a UI library, a JS <-> native binding system with wrappers for native APIs, a build system, and an implementation of CSS-like layout for native views. They are not really comparable.
I would prefer Riot.js instead.. a much less headaches
Most of the original criticisms centers around NPM, which belies the hell that is JavaScript. Since everyone compiles JS anyway, we should stop writing in it altogether. Pick some other language ecosystem that transpiles to JS. Delenda Est NPM.
(As someone who knows Dan, I'd bet money that this smiley face is genuine. Still, easy to misread.)
TIL. I've been manually setting up my own configs for years now, and never touched this tool because I thought it was literally creating a sample/boilerplate app for you much like the express.js cli generator.
Dan Abramov commented a while back on how CRA differs from boilerplates: https://www.reddit.com/r/reactjs/comments/5gt2c4/you_dont_ne... .
Also, I commented with some additional thoughts on why CRA is a better choice than "boilerplates" for someone who's trying to learn: https://www.reddit.com/r/reactjs/comments/5oem3g/recommended... .
Overall, CRA serves three primary purposes: it allows React learners to set up an environment without having to learn Webpack and Babel first; it allows experienced React devs to spin up a project without having to do all the configuration work (or copy and paste it from somewhere); and it also provides a common starting point for instructions and tutorials. For example, my recent blog post on using the Cesium.js 3D globe library with Webpack and React ( http://blog.isquaredsoftware.com/2017/03/declarative-earth-p...) was able to start by just saying "Create a CRA project, eject, and modify these two config values".
I do use emojis all the time in personal communication but I guess it doesn't read very well so I removed them.
The question about components wasn’t meant to be an insult but I can understand how one could see it that way, so I removed it.
Sorry!
Don't pretend you're not fighting fire with fire with this article. You're mad and you're showing it. When you say stuff like...
>>To sum up, I love that you brought up these concerns in an article.
I don't believe you! Disingenuous.
(You should also think about whether or not the Riot.js author is worth responding to. Just because he's a framework author doesn't mean that framework has ever been held in high regard.)
To me, reading posts filled with frustration serves as a motivation to improve things. I didn't reply to "fight with fire": I see these kinds of posts every week or two. But I replied this time because I think it was also important to separate real issues from the factual inaccuracies (that get a life of their own once somebody writes an article).
Some bitterness did come through, and I removed it. But I'm not lying when I tell you I'm happy people are sharing their concerns with React. It's all for the best. :-)
this is your opportunity to pointedly not listen to criticism about the React ecosystem, which you are taking in full.
if you were really motivated to improve things you wouldn't need to write a defensive article.
you and your team will continue on your status quo. why?
because you're not able to fix the problems with react router. you're not able to solve the MVC/total solution ecosystem conundrum React has.
you're completely unable to address the core criticisms of the critical article. better to admit that than pretend.
so what we have here is another technologist fighting with mud while loudly proclaiming that they're not fighting, we're all friends, 'it's all for the best.'
...As I said. Disingenuous.
Also, if I understand it correctly, the original author is a maintainer of a competing framework, heavily inspired by React. So, this is not exactly an impartial account of an 'experienced dev'. Maybe I'm reading too much into that but it's not something I like seeing in the FOSS world.
I agreed with the original post and this reply didn't sway me. I see in this thread that people who had already disagreed with the original post agreed with this, as expected.
Seriously, nobody not called Linus Torvalds should be writing direct replies to criticism of their technology in blog posts (and he's the only exception because reading his replies is very entertaining).
Yes, people like their technology and like how it is, it makes sense for them but, that's not universal; so addressing criticism (even as an attempt of countering the criticism) only legitimizes it.
If one doesn't want to acknowledge that one's technology is not for everyone... one is better off not acknowledging it, in any way; doing otherwise puts that shortsightedness in evidence.
>Your post includes a lot of misconceptions commonly held in the React community, so I wanted to take a moment to clarify them for everyone else who has the same concerns.
I didn't reply to many similar posts before, but I felt like this is a good opportunity to jump in and provide some clarifications because there are some factual misconceptions in the post. When unaddressed, these tend to keep spreading and get a life of their own.
Also, we do take this feedback to the heart. In fact we spent time developing Create React App precisely thanks to feedback like this.
>If one doesn't want to acknowledge that one's technology is not for everyone.
We totally acknowledge React is not for everyone! I touched on this in the last paragraph, but it wasn’t the focus of my article. I do try to stress it when comparing React to other libraries in general, but this seemed like a React-specific post.
As a React developer, I also raised an eyebrow at the misconceptions given in the original article. (The worst, IMO, was definitely the part regarding Create React App and the overall toolchain).
I appreciate your take on the article and felt that you did a good job focusing on these issues, whereas someone like myself would've been a bit more biting in my response.
As for how much this actually set the record straight or how much the original post was false information, I guess I'll have to disagree.
Nothing in the original post was false per se, and I, for one, agreed with everything in it, every time I've tried to get into react since it was launched and it's always the same annoyances. It's just not for me and it's not for the author of the original post.
Two different points in OP's reply were "well yeah, but it'll be different in the next version/future!" (amusingly, another point was "well, just don't use the new version!") which means that the original post was... right.
You mean besides:
"I started my app with React 15.5.0 knowing that my code is deprecate before even starting" (addressed by dan)
"in mobx you can prefix your store actions but “it’s just for the glam” because it won’t preserve overriding any observable property of your store as it was a normal object store.message = ‘hello’ from any component of your application!?!" (strict mode, right there on the page he even links to)
"React-router is not officially maintained by facebook and the maintainers had the great idea of bumping 3 major versions in 5 months completely not backward compatible to each other" (in the link he provides, you can see version 4 was released 03.2017, version 3 was released 10.2016, version 2 was released 02.2016. Even a charitable reading of "bumping 3 major versions" doesn't get you to 5 months)
I could only find one more assertion of fact, rather than opinion, which happens to be right:
"Once I understood what was the issue I was dragged into the rabbit hole being forced to add empty divs all over the place to let my app work properly"
However, it's also fixed in the next release.
If you buy into the fairy tale that a complete rewrite isn't going to break anything, all the power to you. I don't, and have no reason to, I've experienced it first hand what such a major change causes. So, not incorrect.
> "in mobx you can prefix your store actions but “it’s just for the glam” because it won’t preserve overriding any observable property of your store as it was a normal object store.message = ‘hello’ from any component of your application!?!" (strict mode, right there on the page he even links to)
So... it is possible but not when done a certain way? How that does make the point false? "well duh, you're using react wrong!" doesn't help react and doesn't address the criticism.
If it allows to do something, it does, and so it can be used to make bad code, which is where every criticism of every language/framework ever originates; none of it invalid.
That's just things one learns to live with, none of the tools we use is perfect.
> "React-router is not officially maintained by facebook and the maintainers had the great idea of bumping 3 major versions in 5 months completely not backward compatible to each other" (in the link he provides, you can see version 4 was released 03.2017, version 3 was released 10.2016, version 2 was released 02.2016. Even a charitable reading of "bumping 3 major versions" doesn't get you to 5 months)
... Except it does? At the start of October, the official version was 2; at the end of March, it was 4. That's three different versions in five months.
I gotta thank you for this one, because it precisely requires a very charitable reading of that.
And even a strict reading gives us two major versions in five months, hardly all that much better.
I've never used React (but have considered it) and this post just really turns me off from even bothering.
I thought it was important to clarify the factual mistakes (such as the misconception about React rewrite), as these tend to keep spreading once they're mentioned in a few articles.
But I see now that I might have chosen the wrong venue and format to address them, as framing it as a response makes it seem personal. That wasn't my intention.
There are weird incentives in software ecosystems. Companies benefit by controlling one because they can hire easily, and ensure their code & tools will not become obsolete. And the more complex ecosystems become, the harder it is for devs to compare them or switch. I think there were similar forces at work in the UIs of large GUI applications like DAWs. Once you get through the painful learning process, you find you love it, and find it impossible to switch -- a phenomenon that has attracted comparisons to Stockholm syndrome.
[1] https://gist.github.com/GianlucaGuarini/b9238a187ef13897b71e...
[2] https://news.ycombinator.com/item?id=14184666
Generally we are interested in solutions that allow us to iterate quickly, and to ship less buggy apps, and React has been helping out with this.
I don't have experience with Vue, but I also heard great things about it, so I'm glad there are many alternatives if React doesn't work well for you!
I've read this claim from FB before (Pete Hunt I think). It's not possible to overstate my disagreement.
I guess if you want to say, 'people in general can't program, but they can plumb things together, and once they learn the conventions the boilerplate becomes transparent', I wouldn't argue. But you haven't said it, and it's not a direction I think is so great for software.
In the future we want one-line applications, right? "Siri, create a calendar app with conflict resolution for the local Owl's club." Not four pages of "Siri, open angle-bracket props colon..."[1]
Re. Vue, I'm sorry I mentioned it. I don't have a horse in the race. However if I did I would definitely have taken the time to try Vue by now. And likewise Guarini, if this is really his first time trying React, has not done basic due diligence by waiting this long.
We can't improve as a field unless we compare results. That TodoMVC is the only benchmark that even exists is unfortunate.
[1] For some evidence in the meantime see http://blog.vivekhaldar.com/post/10669678292/size-is-the-bes...
jQuery is meant for manipulating arbitrary DOM nodes in a page. Assuming they share a classname, I can hide a dozen divs scattered throughout the page with a single `$(".myClass").hide()`. In React, I'd probably need to pass some state through several components, and ultimately re-render, which would be considerably more LOC.
Does that mean that React is "worse"? No. It means they're meant for different kinds of tasks. React is meant for making codebases maintainable and understandable. Sure, fewer LOC is _usually_ a good thing, but many times being more explicit makes a codebase more maintainable.
"You are completely right it’s annoying. It’s one of those early design decisions to align better with the DOM APIs that has proved to be confusing. We might change this in the future." - dan
i appreciate dan's honesty here. it was little things like this made the framework look a bit immature and rushed but glad to know these are in the horizon to be improved on.
Create-React-App is a great step, but what next? How to handle AJAX and state if I have a simple app and don't really need Redux. How to structure it so it would be easy to add it.
You may be interested in several of the sections in my React/Redux links list at https://github.com/markerikson/react-redux-links . In particular, check out the "React Architecture", "React Component Patterns", "React State Management", "React and AJAX", "Redux Architecture", and "Project Structure" sections.
To pick out a few specific links related to your questions:
- http://reactpatterns.com/
- https://github.com/vasanthk/react-bits
- https://medium.com/@dan_abramov/smart-and-dumb-components-7c...
- https://daveceddia.com/ajax-requests-in-react/
- https://daveceddia.com/visual-guide-to-state-in-react/
- https://hackernoon.com/redux-step-by-step-a-simple-and-robus...
Is there a great mid-size open-source project that was created with Create React App? Any input on UI frameworks? I'm currently using React-Bootstrap, but I'm thinking about using Material-UI.
I personally am using Semantic-UI-React [1] in a work project, as well as in the sample app for my "Practical Redux" tutorial series [2] [3]. I also frequently recommend a tutorial series called "Building a Simple CRUD App with React + Redux" [4] as another "real-world" tutorial/example. That tutorial doesn't use CRA, but my "Practical Redux" sample app does.
[0] https://github.com/markerikson/redux-ecosystem-links/blob/ma...
[1] http://react.semantic-ui.com/
[2] https://github.com/markerikson/project-minimek
[3] http://blog.isquaredsoftware.com/series/practical-redux/
[4] http://www.thegreatcodeadventure.com/building-a-simple-crud-...
i.e. you can just do it inside the component: https://gist.github.com/mentrie/8632e81ae2960df8d02947b8b743...