6 ms·

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

• 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.
    • aljones 10y ago
      The official docs are good. Create React App is great for getting started with minimal overhead. This very article is a remarkably restrained and informative reply. The React team is doing a good job.
    • jhall1468 10y ago
      > but these problems do warn people to stay away from the React ecosystem No they don't. There is bad advice for every framework/language that exists. Following bad advice means carefully trusting sources. It is 100% on the user to determine whether an article applies, or it's plain wrong. > If the React team doesn't want people to stay away, it's in their interest to do something about it. Do what exactly? Start sending take-down notices for poorly written articles? Would you use a chainsaw to make a miniature, and then saw the chainsaw manufacturers need to "do something about it"? People are so weird about frameworks.
      • BenMosher 10y ago
        > It is 100% on the user to determine whether an article applies, or it's plain wrong. You're not wrong, but isn't it especially difficult for an inexperienced person to judge whether an article applies?
      • mcphage 10y ago
        > It is 100% on the user to determine whether an article applies, or it's plain wrong. It is. But nobody has the time or patience to determine that for every article, so if the React team wants people to use React, then it's in their interest to insure good articles about React are easier to find than bad articles about React. > Do what exactly? Start sending take-down notices for poorly written articles? Write good articles & tutorials, as well as share & popularize the good articles that are out there. Ask the companies that use React talk about React and how it solves their problems. If developers like starter kits & scaffolded projects, then write some good ones and toss them up on Github. Make sure the message that they want to get out doesn't get buried under all of the poorly written cruft out there. They're under no obligation to do any of this, but nor are most developers under any obligation to use React. If they want people to use React, and the message that React is a good, easy framework to use is getting lost, then... well, how do you think that's going to end up? Or to put it another way: there are a lot of JS frameworks out there. React needs developers to use it, more than those developers need to use React specifically. So they should be willing to do some of the heavy lifting needed to attract people; moreso if there's a negative message already out there.
  • strictnein 10y ago
    > "The React team can't be held responsible for the amount of crappy advice on the Internet" Do we extend this same courtesy to the PHP team? Or do we treat it as indicative of something?
    • scrollaway 10y ago
      How about: We hold developers responsible for the things they develop, which is what we've been doing all along? PHP devs got well-deserved flak for a long time, not for the "crappy advice" (although there is plenty to go around), but for the language itself. That situation has improved, so yes, extend some courtesy. React has done a pretty damn good job of looking at the "crappy advice" and treat it as pain point indicators, thus improving React further by fixing those. But you simply can't do that for everything, and a lot of the awful advice you find is what happens when you have a very low barrier of entry to both use something and give advice on it. My uncle keeps telling me I'll get arthritis by cracking my knuckles. Do I blame my doctors because they don't go around actively and preventatively telling people that's not a thing?
      • strictnein 10y ago
        I don't have a horse in this race at all, just noting the inconsistencies. Although the idea that React doesn't have some language "issues" is pretty amusing. > "My uncle keeps telling me I'll get arthritis by cracking my knuckles. Do I blame my doctors because they don't go around actively and preventatively telling people that's not a thing?" Really weird comeback at the end there. We do expect experts in various fields to work on educating the public, especially in regards to widely believed but inaccurate ideas.
        • jhall1468 10y ago
          > I don't have a horse in this race at all, just noting the inconsistencies. PHP had some implementation issues that made the language god awful. Saying it's the same thing is a straw man. > Really weird comeback at the end there. We do expect experts in various fields to work on educating the public, especially in regards to widely believed but inaccurate ideas. They do, with their official docs, which are well-written. What, exactly, do you want them to do about third parties?
  • rkangel 10y ago
    > The React team can't be held responsible for the amount of crappy advice on the Internet There is a lot of Rust evangelism on HN, but one ting they do seem to have grokked is that quality of documentation is important to building a userbase. If all that's out there are a series of out of date blog posts then that's the level of documentation. Plus, I'm fairly sure I remember (but have no citation for) the Rust team reaching out to try and get the community to update old blog posts (or at least put in links to newer documentation).
    • Bjartr 10y ago
      For the other end of the spectrum see the GWT ecosystem. It can be really difficult to find out what's the right way to build something sometimes.
  • renlo 10y ago
    It's not that the advice is necessarily 'crappy', it's more that it's no longer current. You might be looking at an article which is only a couple of months old but is already out of date because some lib (like react-router) has changed, or it's considered 'the wrong way' now (when it was 'the correct way' a couple of months ago).
    • jhall1468 10y ago
      Which is 100% on react-router. That has nothing to do with React. This would be akin to issues you have with some Ember plugin on the Ember team. It's odd.
  • taurath 10y ago
    In the space of making a single very simple tabbed app I found the need to use react router. I didn't want to have to "invent" a way to change urls on the fly so the back button would work. What happened with react for me was that there's no "common" pattern to perform basic tasks outside of popular libraries.
  • darth_mastah 9y ago
    > you shouldn't be using Redux until you need it In my experience whenever you start dealing with state you need it. Which is in fact quite early in the project.
• philpee2 10y ago
  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.
  • nkohari 10y ago
    Yes and no -- you could also get away with passing the state down from a higher-level component. This does break down quickly, but if your app isn't too complicated, it can be enough for the first version. (Certainly, if I was unfamiliar with React, I would try this before integrating another library like Redux.)
  • acemarke 10y ago
    There's a difference between "don't try to learn Redux until you understand React", and "don't use Redux right away when you start building an app". For most people, trying to learn to "think in React" is a pretty big jump, especially if they're coming from an imperative, jQuery-style background. Throwing in Redux's concepts at the same time is usually too much for most people, especially if they're relatively inexperienced programmers. So, the standard advice from both the React and Redux teams is to focus on learning React first. Once you have a good understanding of how React works, you will better appreciate why a state management library like Redux can be useful, and you can learn about other tools later. On the other hand, if you are familiar with Redux, it does make a lot of sense to set it up from the beginning. I've been writing a tutorial series called "Practical Redux" ( http://blog.isquaredsoftware.com/series/practical-redux/ http://blog.isquaredsoftware.com/series/practical-redux/ ) , which is intended to demonstrate a variety of useful React and Redux techniques in the context of a sample app. In that series, I create a new project using Create-React-App, and then immediately add Redux into it as a baseline. Overall, what Dan is trying to push back against is the perception that you _must_ use Redux with React, or that you _must_ learn them both at the same time. Neither is true.
    • vbezhenar 10y ago
      Honestly many developers don't have freedom to experiment with new things on their own. I got web project, I'm thinking, well, it's a good time to try out React, I've heard it's cool. I'm convincing my manager, if necessary and I'm starting to build production project without any prior React or Redux or whatever knowledge. I'm not going to do it step by step, no. I'm grabbing everything and trying to bundle it all together. I know, that my app will need state, so I'm using Redux. I know, that my app will need routing, so I'm using router. And my experience is similar to author's, I had a lot of troubles to even get build setup working. I guess, it's more about javascript development tools, not specifically about React, but point stands still. And if I'm understanding, that I just got buried under pile of things, I'll throw it out, rewrite everything on Angular I know and love and forget about it for a few years, until it matures and I could try it again, hopefully with less troubles. If you've got a lot of free time and want to tinker a lot, that's a good advice. Pick simple project, make it with simplest setup, introduce additional dependencies, rewrite the project, and so on. But not everyone wants to learn without being paid for it.
• gambler 10y ago
  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.
• mlsarecmg 10y ago
  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.
  • ubertaco 10y ago
    This is worth noting primarily because the original almost got me: he kept mentioning Riot.js over and over, and I thought "huh...I haven't worked with that...I must be out of date." Instead, this is a case of "I wrote a framework that works exactly the way I like it, and then used a framework that doesn't, so here's why the one that doesn't work the way I like is waaay worse than the one I wrote."
    • Can_Not 10y ago
      In the general case, this a big pain point for me. Having to wade through tons of shallow subjective "Well I like it" disguised as objective technical points can be very fustrating, especially when trying to learn something new and unfamiliar, such as my next major language or framework to learn or use.
      • sotojuan 10y ago
        Unfortunately, you just described most of the tech blog posts posted on HN/elsewhere. It's a very big problem :-(