Comment by iamleppert | Hacker News Reader

Comment by iamleppert | Hacker News Reader

I'll preface this by saying I'm not a huge fan of ES2015 modules. Everything ES2015 provides (syntactical sugar) could be achieved with CommonJS exports. If you don't want to export an object and only a single thing, you can enforce those restrictions via code reviews, linting tools, etc. rather than bloating the language spec. And the backwards compatibility is very poor with older CommonJS (the weird __default stuff). This is what happens when you try to bolt on features from other languages that make no sense with javascript.

The next point is regarding IDE's. Honestly, I don't understand the obsession with designing a language around tooltips in an IDE. I personally use vim and once I know a code base I rarely need to look stuff up. If your code and internal APIs are that complicated where you can't remember basic function signatures, its time to refactor and simplify so you can fit all that stuff in your memory without the need for hints.

To the point about refactoring: I really doubt named imports are going to save you much time here at all. How much time do you spend figuring out the import/exports from a file vs. refactoring what the actual code is doing? Unless you're talking about some kind of formal AST automation (which could benefit from being more explicit)?

The next comment is about tree shaking. Better known as "dead code elimination" and its been in uglifiyjs and closure compiler for 10 years but somehow the webpack folks thought tree shaking sounded cooler, even though they don't even implement it and just shell out to uglifer. My argument here is that if your code is so messy and is in need of good shake (no pun intended, well...err), you have big problems. I cringe when I see people trying to layer on tools to paper over technical debt. You should actually go through the source and remove what isn't needed or used anymore.

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.

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.

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.

> I personally use vim and once I know a code base I rarely need to look stuff up.

How much code do you work with, out of curiosity? At my work, we have about 500,000 lines of code, and while I'm usually working on a specific part of that, modifying and interfacing with other parts of the code is common. And, of course, for new people and people switching teams, all code is unfamiliar. IMO, expecting people to "just know the code" is really unreasonable; working with code you're not familiar with is very common in software engineering, and our tools and practices should take that into consideration.

> I personally use vim and once I know a code base I rarely need to look stuff up.

Must be nice to work on stuff you're familiar with for years, day in and day out. That's not the use-case.

DCO is still important in libraries. If you have a large-ish library of mostly unrelated code (think lodash/underscore), DCO is pretty darn useful for the end users: you don't need to weigh in filesize (pun intended) as much when developing new features.

default exports are precisely as tree-shakeable/dead-code-eliminate-able as named exports; this topic just isn't remotely relevant to the discussion.

Reply on news.ycombinator.com