3 ms·

Your comments don't scale well. Projects have dependencies from teams with various skill levels and external dependencies over most of which you have little or

by dwg 9y ago

Your comments don't scale well. Projects have dependencies from teams with various skill levels and external dependencies over most of which you have little or no control. For this and many others reasons "refactoring to simplify" often isn't an option. Similarly, tree shaking doesn't just apply to the code from your project. Also, what about the time when you first start on a project? Or maybe you're only working on a project for a short time? Wouldn't it be nice if the experience was good regardless? The author makes a good suggestion for consideration. Anytime we find a principle which is likely to lead to an overall improvement at scale it's worth considering, especially when it comes without much if any a downside. I'm not necessarily agreeing that this is the case here, but just don't think your comments add much.

iamleppert 9y ago
If the source of the problems are external dependencies, which, as you stated, you lack control, how would you go about banning default exports in those libraries? The correct and pragmatic course of action to address problems in code quality is to address them by refactoring, one file at a time. If you want to see the effects of explicit imports, go ahead and look at any large java code base. What ends up happening is fragmentation and enormous and tediously huge import declarations at the top of every file. Again, it's better to address the real problem and not the symptom of poor code quality.
- dwg 9y ago
  Look I happen to agree about refactoring, but my point was that the authors reasons do matter in the context of an organization or the community, even if they don't matter to you as an individual. If there is a best practice here (which is far from decided from this article along) then it's a worthwhile point to bring up for discussion because while you can't control, you can hope to influence. Also your point about tree-shaking is incorrect as it endeavors to apply to dependencies as well. Finally, even without default exports one can still import the entire package with import *, so I don't see how it would lead to the same "problem" of a huge import declaration in Java. In any case I _do_ agree that the authors suggestion should not be taken as a substitute for refactoring, but discussing this as a possible best practice is NOT mutually exclusive to this belief.

by dwg 9y ago

iamleppert 9y ago

If the source of the problems are external dependencies, which, as you stated, you lack control, how would you go about banning default exports in those libraries? The correct and pragmatic course of action to address problems in code quality is to address them by refactoring, one file at a time. If you want to see the effects of explicit imports, go ahead and look at any large java code base. What ends up happening is fragmentation and enormous and tediously huge import declarations at the top of every file. Again, it's better to address the real problem and not the symptom of poor code quality.

dwg 9y ago
Look I happen to agree about refactoring, but my point was that the authors reasons do matter in the context of an organization or the community, even if they don't matter to you as an individual. If there is a best practice here (which is far from decided from this article along) then it's a worthwhile point to bring up for discussion because while you can't control, you can hope to influence. Also your point about tree-shaking is incorrect as it endeavors to apply to dependencies as well. Finally, even without default exports one can still import the entire package with import *, so I don't see how it would lead to the same "problem" of a huge import declaration in Java. In any case I _do_ agree that the authors suggestion should not be taken as a substitute for refactoring, but discussing this as a possible best practice is NOT mutually exclusive to this belief.