13 ms·

A response to “An experienced JavaScript dev’s account of learning React”

216 points by nachtigall 10y ago

jannotti 10y ago
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.
- STRML 10y ago
  It will also allow returning raw strings (TextNodes), which will allow for some very light i18n libraries.
  - ChicagoBoy11 10y ago
    I had never considered the i18n of it until now. That's a great point.
  - samtho 9y ago
    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.
hising 10y ago
Maybe I read this with the wrong glasses, but I find some of the answers a bit high-horse? "How many components do you have" etc.
- ascendantlogic 10y ago
  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.
  - hising 10y ago
    Why respond at all if so?
    - ascendantlogic 10y ago
      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.
      - danabramov 9y ago
        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. :-)
- spicyj 10y ago
  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.
  - Bahamut 10y ago
    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)
    - danabramov 9y ago
      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/ http://facebook.github.io/jest/.
  - hising 10y ago
    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?
    - acemarke 10y ago
      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.
- brogrammernot 10y ago
  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.
  - danabramov 9y ago
    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.
    - brogrammernot 9y ago
      It looks quite good! 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!
- ww520 10y ago
  The responses felt very defensive.
  - scrollaway 9y ago
    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.
    - acemarke 9y ago
      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).
  - danabramov 9y ago
    Thanks for feedback! I certainly made a mess there. :-) I edited the post, is it better now?
AustinG08 10y ago
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.
- eganist 10y ago
  > 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/facebook/react/blob/master/PATENTS
  - peller 10y ago
    If this is a concern, maybe you could just use something like preact as a drop-in replacement for react? https://github.com/developit/preact https://github.com/developit/preact
    - bryanlarsen 10y ago
      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.
      - peller 9y ago
        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.
whitefish 10y ago
Those who think React + ReactRouter + Redux is too complex -- you're right. But there is an easier way to use React: MVC. React is the V in MVC. https://github.com/Rajeev-K/mvc-router https://github.com/Rajeev-K/mvc-router Note that using MVC does not imply 2-way binding!
- choward 10y ago
  Or you could just cut out the middle steps and make the switch all the way over to Elm ;)
  - lolc 10y ago
    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.
- BigJono 10y ago
  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.
  - sotojuan 10y ago
    > React is very usable without Redux. I'm not sure how they became bound so tightly together Because that's what easily-excited developers see on HN and Twitter, so they think they have to use it.
deleted 10y ago
[deleted]
andrethegiant 10y ago
If anyone isn't aware, you can use babel-plugin-react-html-attrs[1] to address the class/className issue addressed in the author's last point. [1] https://github.com/insin/babel-plugin-react-html-attrs https://github.com/insin/babel-plugin-react-html-attrs
nevir 10y ago
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 Etc
- kbuchanan 10y ago
  I agree with this point. 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).
- jhall1468 10y ago
  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.
  - mcphage 10y ago
    > 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.
finchisko 10y ago
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.
NoGravitas 10y ago
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.
_greim_ 10y ago
> 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?
- jhall1468 10y ago
  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.
- pps 10y ago
  > it has the same public API means basically that it is working like previous versions and if not then there is simply a bug
- spicyj 10y ago
  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.
  - danabramov 9y ago
    Thanks for writing this clarification. Edited the post to include it.
  - _greim_ 9y ago
    Thanks!
blurrywh 10y ago
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).
bigato 10y ago
Here's the article this one is meant to answer: https://medium.com/@gianluca.guarini/things-nobody-will-tell-you-about-react-js-3a373c1b03b4 https://medium.com/@gianluca.guarini/things-nobody-will-tell...
- lucaspiller 9y ago
  It is actually linked at the top of this article, although Medium's minimal design doesn't make that very clear.
sksixk 10y ago
i find the passive-aggresive emojis in these "response" blog posts amusing.
- danabramov 9y ago
  Thanks for feedback! I use them all the time on Twitter, and didn't mean to do it in a passive aggressive way. I removed them.
bigato 10y ago
I'd love to read an answer to this: "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?!?"
- scrollaway 10y ago
  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 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 https://github.com/ansible/ansible/issues
  - bigato 10y ago
    Does that justify alpha dependencies?
    - scrollaway 10y ago
      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.
      - 10y ago
metehe 10y ago
Facebook rewrites gonna scare whole lot users.. react projects seems to be very fragile in versioning process.. I would prefer Riot.js instead.. a much less headaches
- joobus 10y ago
  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 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.
- haukur 9y ago
  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).
nickbauman 10y ago
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.
mcguire 10y ago
To quote Doc Martin, that sounds appalling.
mswift42 10y ago
While Abramov's points sound reasonable, his post could do with a less patronising tone.
- danabramov 9y ago
  Sorry. Fixed. :-)
  - spicyj 9y ago
    You're doing it again with the smiley faces Dan. (As someone who knows Dan, I'd bet money that this smiley face is genuine. Still, easy to misread.)
    - danabramov 9y ago
      I'll attach webcam photos next time. :-)
philmander 10y ago
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.
samtho 9y ago
> 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.
- acemarke 9y ago
  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. Dan Abramov commented a while back on how CRA differs from boilerplates: https://www.reddit.com/r/reactjs/comments/5gt2c4/you_dont_need_a_boilerplate/ 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_reactredux_starter_kits/ 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... 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".
yladiz 9y ago
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.
- danabramov 9y ago
  Thanks for feedback. I agree I got too defensive, so I edited the post to be less flippant. (Didn’t expect it to jump to HN in an hour.) 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!
  - throwawaymaroon 9y ago
    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.)
    - deleted 9y ago
      [deleted]
    - danabramov 9y ago
      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. :-)
julianmarq 9y ago
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.
- danabramov 9y ago
  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.
  - dentemple 9y ago
    Thank you for your efforts! 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.
beefman 9y ago
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. [1] https://gist.github.com/GianlucaGuarini/b9238a187ef13897b71e15e4906e4499 https://gist.github.com/GianlucaGuarini/b9238a187ef13897b71e... [2] https://news.ycombinator.com/item?id=14184666 https://news.ycombinator.com/item?id=14184666
- oblio 9y ago
  It's a trade off. At least we also get access to their internal frameworks, unlike in the old days.
- acemarke 9y ago
  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.
  - davidjnelson 9y ago
    Exactly, which also helps with maintenance and testing.
  - beefman 9y ago
    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.
jaequery 9y ago
"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.
ed_balls 9y ago
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.
- acemarke 9y ago
  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 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/ http://reactpatterns.com/ - https://github.com/vasanthk/react-bits https://github.com/vasanthk/react-bits - https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0 https://medium.com/@dan_abramov/smart-and-dumb-components-7c... - https://daveceddia.com/ajax-requests-in-react/ https://daveceddia.com/ajax-requests-in-react/ - https://daveceddia.com/visual-guide-to-state-in-react/ https://daveceddia.com/visual-guide-to-state-in-react/ - https://hackernoon.com/redux-step-by-step-a-simple-and-robust-workflow-for-real-life-apps-1fdf7df46092 https://hackernoon.com/redux-step-by-step-a-simple-and-robus...
  - ed_balls 9y ago
    Thanks for that. Really helpful. 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.
    - acemarke 9y ago
      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. [0] https://github.com/markerikson/redux-ecosystem-links/blob/master/apps-and-examples.md https://github.com/markerikson/redux-ecosystem-links/blob/ma... [1] http://react.semantic-ui.com/ http://react.semantic-ui.com/ [2] https://github.com/markerikson/project-minimek https://github.com/markerikson/project-minimek [3] http://blog.isquaredsoftware.com/series/practical-redux/ http://blog.isquaredsoftware.com/series/practical-redux/ [4] http://www.thegreatcodeadventure.com/building-a-simple-crud-app-with-react-redux-part-1/ http://www.thegreatcodeadventure.com/building-a-simple-crud-...
smdz 9y ago
There are a few things in React ecosystem that need to be abstracted. 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.
- asdfgadsfgasfdg 9y ago
  create-react-app
  - buchanaf 9y ago
    This quite frankly is answer to approximately 75% of the complaints that you hear about the React/JS community. Unless you are doing something relatively cutting edge like isomorphic rendering (next.js), you are basically wasting your time if you aren't leveraging create-react-app for your scaffolding.
  - smdz 9y ago
    I get thrown that a lot, but unfortunately create-react-app is not the solution. It simply summarizes all the complexities in one place, it doesn't abstract those out. For starters - yes, definitely. They should start with it
    - spicyj 9y ago
      If there are areas where create-react-app is a leaky abstraction, please file bugs. My understanding is that the maintainers aspire to have it completely shield you from configuring the underlying tools.
noshbrinken 9y ago
I love reading Dan Abramov's writing because I always learn two things at the same time: 1. something about programming; 2. something about communicating with people.
plandis 9y ago
This is a failure in obsessing over your customers. Rather than refuting a noobs comments, perhaps that is a great time to learn what exactly is painful for new people and fixing it?
- aeze 9y ago
  The comments are being mostly refuted because they're mostly misconceptions.
spion 9y ago
Here is what is missing now in the React ecosystem http://guides.rubyonrails.org/ http://guides.rubyonrails.org/ Thats it. A central place with an organised list of guides. Not a blog though. Also must cover things such as redux, mobx and routers, and how it all fits together.
- acemarke 9y ago
  I already have something pretty close to that :) 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 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. (The entire list has just been me working it by myself with the occasional "add a link" PR from random other people, but I'd certainly appreciate any actual offers to help improve it, especially since my own knowledge is rather limited in a number of areas.)
  - lucaspiller 9y ago
    The work you have done here is useful, but as pointed out in the original article, articles very quickly become outdated in the Javascript ecosystem. It's not just how libraries work (I haven't looked through the list too much, but I'm sure there are plenty of articles suggesting a Webpack 1.x configuration) but also the recommended way of doing things and what tools to use that changes. I guess this is one of the advantages Rails has being a monolith - as it provides nearly everything, it's very easy for them to keep up to date documentation of the 'Rails way' to do things. React and Redux have been relatively stable, but it's everything else that goes along with it that is the issue.
    - acemarke 9y ago
      True, but it's also worth noting that the existence of a newer version of a lib doesn't completely invalidate the older version. For example, Webpack 2 _is_ out, but a Webpack 1 config and setup will still keep working just fine. Ditto for, say, React-Router v3 vs v4.
darth_mastah 9y ago
> 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.

216 points by nachtigall 10y ago

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.

STRML 10y ago
It will also allow returning raw strings (TextNodes), which will allow for some very light i18n libraries.
- ChicagoBoy11 10y ago
  I had never considered the i18n of it until now. That's a great point.
- samtho 9y ago
  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.

hising 10y ago

Maybe I read this with the wrong glasses, but I find some of the answers a bit high-horse? "How many components do you have" etc.

ascendantlogic 10y ago
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.
- hising 10y ago
  Why respond at all if so?
  - ascendantlogic 10y ago
    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.
    - danabramov 9y ago
      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. :-)
spicyj 10y ago
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.
- Bahamut 10y ago
  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)
  - danabramov 9y ago
    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/ http://facebook.github.io/jest/.
- hising 10y ago
  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?
  - acemarke 10y ago
    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.
brogrammernot 10y ago
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.
- danabramov 9y ago
  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.
  - brogrammernot 9y ago
    It looks quite good! 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!
ww520 10y ago
The responses felt very defensive.
- scrollaway 9y ago
  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.
  - acemarke 9y ago
    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).
- danabramov 9y ago
  Thanks for feedback! I certainly made a mess there. :-) I edited the post, is it better now?

AustinG08 10y ago

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.

eganist 10y ago
> 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/facebook/react/blob/master/PATENTS
- peller 10y ago
  If this is a concern, maybe you could just use something like preact as a drop-in replacement for react? https://github.com/developit/preact https://github.com/developit/preact
  - bryanlarsen 10y ago
    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.
    - peller 9y ago
      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.

whitefish 10y ago

Those who think React + ReactRouter + Redux is too complex -- you're right. But there is an easier way to use React: MVC. React is the V in MVC. https://github.com/Rajeev-K/mvc-router https://github.com/Rajeev-K/mvc-router Note that using MVC does not imply 2-way binding!

choward 10y ago
Or you could just cut out the middle steps and make the switch all the way over to Elm ;)
- lolc 10y ago
  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.
BigJono 10y ago
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.
- sotojuan 10y ago
  > React is very usable without Redux. I'm not sure how they became bound so tightly together Because that's what easily-excited developers see on HN and Twitter, so they think they have to use it.

deleted 10y ago

[deleted]

andrethegiant 10y ago

If anyone isn't aware, you can use babel-plugin-react-html-attrs[1] to address the class/className issue addressed in the author's last point. [1] https://github.com/insin/babel-plugin-react-html-attrs https://github.com/insin/babel-plugin-react-html-attrs

nevir 10y ago

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 Etc

kbuchanan 10y ago
I agree with this point. 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).
jhall1468 10y ago
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.
- mcphage 10y ago
  > 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.

finchisko 10y ago

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.

NoGravitas 10y ago

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.

_greim_ 10y ago

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

jhall1468 10y ago
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.
pps 10y ago
> it has the same public API means basically that it is working like previous versions and if not then there is simply a bug
spicyj 10y ago
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.
- danabramov 9y ago
  Thanks for writing this clarification. Edited the post to include it.
- _greim_ 9y ago
  Thanks!

blurrywh 10y ago

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

bigato 10y ago

Here's the article this one is meant to answer: https://medium.com/@gianluca.guarini/things-nobody-will-tell-you-about-react-js-3a373c1b03b4 https://medium.com/@gianluca.guarini/things-nobody-will-tell...

lucaspiller 9y ago
It is actually linked at the top of this article, although Medium's minimal design doesn't make that very clear.

sksixk 10y ago

i find the passive-aggresive emojis in these "response" blog posts amusing.

danabramov 9y ago
Thanks for feedback! I use them all the time on Twitter, and didn't mean to do it in a passive aggressive way. I removed them.

bigato 10y ago

I'd love to read an answer to this: "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?!?"

scrollaway 10y ago
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 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 https://github.com/ansible/ansible/issues
- bigato 10y ago
  Does that justify alpha dependencies?
  - scrollaway 10y ago
    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.
    - 10y ago

metehe 10y ago

Facebook rewrites gonna scare whole lot users.. react projects seems to be very fragile in versioning process.. I would prefer Riot.js instead.. a much less headaches

joobus 10y ago
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 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.
haukur 9y ago
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).

nickbauman 10y ago

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.

mcguire 10y ago

To quote Doc Martin, that sounds appalling.

mswift42 10y ago

While Abramov's points sound reasonable, his post could do with a less patronising tone.

danabramov 9y ago
Sorry. Fixed. :-)
- spicyj 9y ago
  You're doing it again with the smiley faces Dan. (As someone who knows Dan, I'd bet money that this smiley face is genuine. Still, easy to misread.)
  - danabramov 9y ago
    I'll attach webcam photos next time. :-)

philmander 10y ago

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.

samtho 9y ago

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

acemarke 9y ago
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. Dan Abramov commented a while back on how CRA differs from boilerplates: https://www.reddit.com/r/reactjs/comments/5gt2c4/you_dont_need_a_boilerplate/ 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_reactredux_starter_kits/ 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... 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".

yladiz 9y ago

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.

danabramov 9y ago
Thanks for feedback. I agree I got too defensive, so I edited the post to be less flippant. (Didn’t expect it to jump to HN in an hour.) 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!
- throwawaymaroon 9y ago
  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.)
  - deleted 9y ago
    [deleted]
  - danabramov 9y ago
    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. :-)

julianmarq 9y ago

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.

danabramov 9y ago
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.
- dentemple 9y ago
  Thank you for your efforts! 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.

beefman 9y ago

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. [1] https://gist.github.com/GianlucaGuarini/b9238a187ef13897b71e15e4906e4499 https://gist.github.com/GianlucaGuarini/b9238a187ef13897b71e... [2] https://news.ycombinator.com/item?id=14184666 https://news.ycombinator.com/item?id=14184666

oblio 9y ago
It's a trade off. At least we also get access to their internal frameworks, unlike in the old days.
acemarke 9y ago
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.
- davidjnelson 9y ago
  Exactly, which also helps with maintenance and testing.
- beefman 9y ago
  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.

jaequery 9y ago

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

ed_balls 9y ago

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.

acemarke 9y ago
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 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/ http://reactpatterns.com/ - https://github.com/vasanthk/react-bits https://github.com/vasanthk/react-bits - https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0 https://medium.com/@dan_abramov/smart-and-dumb-components-7c... - https://daveceddia.com/ajax-requests-in-react/ https://daveceddia.com/ajax-requests-in-react/ - https://daveceddia.com/visual-guide-to-state-in-react/ https://daveceddia.com/visual-guide-to-state-in-react/ - https://hackernoon.com/redux-step-by-step-a-simple-and-robust-workflow-for-real-life-apps-1fdf7df46092 https://hackernoon.com/redux-step-by-step-a-simple-and-robus...
- ed_balls 9y ago
  Thanks for that. Really helpful. 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.
  - acemarke 9y ago
    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. [0] https://github.com/markerikson/redux-ecosystem-links/blob/master/apps-and-examples.md https://github.com/markerikson/redux-ecosystem-links/blob/ma... [1] http://react.semantic-ui.com/ http://react.semantic-ui.com/ [2] https://github.com/markerikson/project-minimek https://github.com/markerikson/project-minimek [3] http://blog.isquaredsoftware.com/series/practical-redux/ http://blog.isquaredsoftware.com/series/practical-redux/ [4] http://www.thegreatcodeadventure.com/building-a-simple-crud-app-with-react-redux-part-1/ http://www.thegreatcodeadventure.com/building-a-simple-crud-...

smdz 9y ago

There are a few things in React ecosystem that need to be abstracted. 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.

asdfgadsfgasfdg 9y ago
create-react-app
- buchanaf 9y ago
  This quite frankly is answer to approximately 75% of the complaints that you hear about the React/JS community. Unless you are doing something relatively cutting edge like isomorphic rendering (next.js), you are basically wasting your time if you aren't leveraging create-react-app for your scaffolding.
- smdz 9y ago
  I get thrown that a lot, but unfortunately create-react-app is not the solution. It simply summarizes all the complexities in one place, it doesn't abstract those out. For starters - yes, definitely. They should start with it
  - spicyj 9y ago
    If there are areas where create-react-app is a leaky abstraction, please file bugs. My understanding is that the maintainers aspire to have it completely shield you from configuring the underlying tools.

noshbrinken 9y ago

I love reading Dan Abramov's writing because I always learn two things at the same time: 1. something about programming; 2. something about communicating with people.

plandis 9y ago

This is a failure in obsessing over your customers. Rather than refuting a noobs comments, perhaps that is a great time to learn what exactly is painful for new people and fixing it?

aeze 9y ago
The comments are being mostly refuted because they're mostly misconceptions.

spion 9y ago

Here is what is missing now in the React ecosystem http://guides.rubyonrails.org/ http://guides.rubyonrails.org/ Thats it. A central place with an organised list of guides. Not a blog though. Also must cover things such as redux, mobx and routers, and how it all fits together.

acemarke 9y ago
I already have something pretty close to that :) 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 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. (The entire list has just been me working it by myself with the occasional "add a link" PR from random other people, but I'd certainly appreciate any actual offers to help improve it, especially since my own knowledge is rather limited in a number of areas.)
- lucaspiller 9y ago
  The work you have done here is useful, but as pointed out in the original article, articles very quickly become outdated in the Javascript ecosystem. It's not just how libraries work (I haven't looked through the list too much, but I'm sure there are plenty of articles suggesting a Webpack 1.x configuration) but also the recommended way of doing things and what tools to use that changes. I guess this is one of the advantages Rails has being a monolith - as it provides nearly everything, it's very easy for them to keep up to date documentation of the 'Rails way' to do things. React and Redux have been relatively stable, but it's everything else that goes along with it that is the issue.
  - acemarke 9y ago
    True, but it's also worth noting that the existence of a newer version of a lib doesn't completely invalidate the older version. For example, Webpack 2 _is_ out, but a Webpack 1 config and setup will still keep working just fine. Ditto for, say, React-Router v3 vs v4.

darth_mastah 9y ago

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