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
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.
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).
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
> 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".
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.
"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.
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).
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.
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.
> 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?
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.
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.
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.
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.
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:
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.
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.
7. And hopefully, everything with TypeScript if they can get over Flow.
Having worked on quite a few React projects, I have a boilerplate that mashes up the above combination and makes it work. With new project, I upgrade the dependencies.
But each time I start a new project in 3-4 months, something would have changed. Either its TS type defs or something in core React.
And as I discovered recently few days back - Webpack2, Router4 broke my boilerplate setup. Well, they actually improved react-router, and that made me remove some workarounds.
Every time I start, I end up spending at least half-to-one day setting up the same "Hello world" page and making sure the wiring works okay before I proceed to add functionality. That is just a waste of time. React core is cool, but I hope they had one highly-opinionated version of React that works out of the box.
Most of the tooling is stable enough that you can lock your dependencies to minor versions (the default behaviour in Yarn/NPM) and only update when you want the new features. There's no need to stay on the bleeding edge unless you want to. I've fallen prey to this myself before, but there's much to be said about just keeping it simple.
> Don’t use Redux if you don’t need it, as it is intentionally verbose.
Yeah... People say that, but is it true? Lifting the state gets very messy very quickly and you end up with a spaghetti code before you know it, with the separation of concerns dying short yet painful death. For that reason I use Redux even in small projects, guarding myself against unnecessary verbosity with redux-actions. It's really that simple. I understand the need to prove that React can stand on its own without Redux, but the truth is, without Redux it's limping.
[+] [-] nevir|9 years ago|reply
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
[+] [-] mlsarecmg|9 years ago|reply
[+] [-] kbuchanan|9 years ago|reply
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).
[+] [-] philpee2|9 years ago|reply
[+] [-] jhall1468|9 years ago|reply
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.
[+] [-] gambler|9 years ago|reply
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.
[+] [-] jannotti|9 years ago|reply
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.
[+] [-] STRML|9 years ago|reply
[+] [-] AustinG08|9 years ago|reply
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.
[+] [-] losteric|9 years ago|reply
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.
[+] [-] eganist|9 years ago|reply
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
[+] [-] julianmarq|9 years ago|reply
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.
[+] [-] danabramov|9 years ago|reply
>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.
[+] [-] armandososa|9 years ago|reply
[+] [-] plandis|9 years ago|reply
I've never used React (but have considered it) and this post just really turns me off from even bothering.
[+] [-] hising|9 years ago|reply
[+] [-] spicyj|9 years ago|reply
[+] [-] brogrammernot|9 years ago|reply
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.
[+] [-] ascendantlogic|9 years ago|reply
[+] [-] ww520|9 years ago|reply
[+] [-] finchisko|9 years ago|reply
[+] [-] samtho|9 years ago|reply
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.
[+] [-] acemarke|9 years ago|reply
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".
[+] [-] NoGravitas|9 years ago|reply
[+] [-] jaequery|9 years ago|reply
"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.
[+] [-] blurrywh|9 years ago|reply
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).
[+] [-] whitefish|9 years ago|reply
https://github.com/Rajeev-K/mvc-router
Note that using MVC does not imply 2-way binding!
[+] [-] BigJono|9 years ago|reply
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.
[+] [-] hising|9 years ago|reply
[+] [-] choward|9 years ago|reply
[+] [-] _greim_|9 years ago|reply
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?
[+] [-] spicyj|9 years ago|reply
[+] [-] jhall1468|9 years ago|reply
You're point might be valid if this was software that's already available, but it isn't.
[+] [-] pps|9 years ago|reply
means basically that it is working like previous versions and if not then there is simply a bug
[+] [-] yladiz|9 years ago|reply
[+] [-] fishnchips|9 years ago|reply
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.
[+] [-] danabramov|9 years ago|reply
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!
[+] [-] andrethegiant|9 years ago|reply
[1] https://github.com/insin/babel-plugin-react-html-attrs
[+] [-] ed_balls|9 years ago|reply
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.
[+] [-] acemarke|9 years ago|reply
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...
[+] [-] mmmpop|9 years ago|reply
[+] [-] davidjnelson|9 years ago|reply
[+] [-] nfRfqX5n|9 years ago|reply
i.e. you can just do it inside the component: https://gist.github.com/mentrie/8632e81ae2960df8d02947b8b743...
[+] [-] nickbauman|9 years ago|reply
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.
[+] [-] philmander|9 years ago|reply
[+] [-] noshbrinken|9 years ago|reply
1. something about programming;
2. something about communicating with people.
[+] [-] smdz|9 years ago|reply
1. Redux
2. React Router
3. Smart components
4. Dumb components
5. Services (This is combination of Redux, redux-thunk and axios(or whatever))
6. Webpack (CSS loader, SCSS, fonts, html, etc...)
7. And hopefully, everything with TypeScript if they can get over Flow.
Having worked on quite a few React projects, I have a boilerplate that mashes up the above combination and makes it work. With new project, I upgrade the dependencies.
But each time I start a new project in 3-4 months, something would have changed. Either its TS type defs or something in core React.
And as I discovered recently few days back - Webpack2, Router4 broke my boilerplate setup. Well, they actually improved react-router, and that made me remove some workarounds.
Every time I start, I end up spending at least half-to-one day setting up the same "Hello world" page and making sure the wiring works okay before I proceed to add functionality. That is just a waste of time. React core is cool, but I hope they had one highly-opinionated version of React that works out of the box.
[+] [-] haukur|9 years ago|reply
[+] [-] asdfgadsfgasfdg|9 years ago|reply
[+] [-] darth_mastah|9 years ago|reply
Yeah... People say that, but is it true? Lifting the state gets very messy very quickly and you end up with a spaghetti code before you know it, with the separation of concerns dying short yet painful death. For that reason I use Redux even in small projects, guarding myself against unnecessary verbosity with redux-actions. It's really that simple. I understand the need to prove that React can stand on its own without Redux, but the truth is, without Redux it's limping.