6 ms·

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'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.
  - ergothus 10y ago
    > There is bad advice for every framework/language that exists I'm somewhat torn on this. I'm currently a JS dev, using React, and I have few complaints. In particular, without regard to the specific API, I think React promotes good models of thought and separation of concerns. It can definitely be done poorly, which can make it a pain to change, but as you say, that's true for anything. BUT - Long ago I did a long stint as a Perl dev. Perl is somewhat infamous for the ease of writing terrible code. I can say with confidence that one can write solid Perl code that is easy to understand and modify. I actually credit the lessons I learned as a Perl dev for improving my code quality in all languages ever since, and there are expressive concepts in Perl that I wish would be implemented in other languages. That doesn't mean that the Perl community (and developers of the language itself) get to ignore that Perl was EASIER to write terrible code in - and in my opinion their(our) ineffectiveness at changing that reputation was as much to blame for the decline of Perl as the Perl 6 crawlout. React is no Perl - I'm not trying to set up a strawman here. I'm just saying that "there is bad advice for every framework/language" can be true and still not contradict the concept that a reputation for problems warns/scares away devs. (That said, I think React isn't suffering that reputation, JS is)
- deleted 10y ago
  [deleted]
- blueprint 10y ago
  > front-loads all of that overhead, which makes you handle it before you're even sure that you want to use a given tool in the first place. Bang on. I not only found the same thing but found that the unknown potential complexities, as well as known complexities, outweighed the potential benefits. And since the potential benefits (React Native, primarily) are so great, that indicates a bit of an issue!!
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 10y 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.

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.
- ergothus 10y ago
  > There is bad advice for every framework/language that exists I'm somewhat torn on this. I'm currently a JS dev, using React, and I have few complaints. In particular, without regard to the specific API, I think React promotes good models of thought and separation of concerns. It can definitely be done poorly, which can make it a pain to change, but as you say, that's true for anything. BUT - Long ago I did a long stint as a Perl dev. Perl is somewhat infamous for the ease of writing terrible code. I can say with confidence that one can write solid Perl code that is easy to understand and modify. I actually credit the lessons I learned as a Perl dev for improving my code quality in all languages ever since, and there are expressive concepts in Perl that I wish would be implemented in other languages. That doesn't mean that the Perl community (and developers of the language itself) get to ignore that Perl was EASIER to write terrible code in - and in my opinion their(our) ineffectiveness at changing that reputation was as much to blame for the decline of Perl as the Perl 6 crawlout. React is no Perl - I'm not trying to set up a strawman here. I'm just saying that "there is bad advice for every framework/language" can be true and still not contradict the concept that a reputation for problems warns/scares away devs. (That said, I think React isn't suffering that reputation, JS is)
deleted 10y ago
[deleted]
blueprint 10y ago
> front-loads all of that overhead, which makes you handle it before you're even sure that you want to use a given tool in the first place. Bang on. I not only found the same thing but found that the unknown potential complexities, as well as known complexities, outweighed the potential benefits. And since the potential benefits (React Native, primarily) are so great, that indicates a bit of an issue!!

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