Why we have banned default exports in JavaScript

The author here, it's great to finally make it to the front page, thanks! :D Initial inspiration for writing this post was twitter discussion: https://twitter.com/krzKaczor/status/933705625883889664

I can for my life not understand why the standards committee did not make the NodeJS module system the standard, what where they thinking !?

Sometimes you don't care what the importing module names your thing, and it's the only thing your module does. Think of a super simple React component... I'm `export default function(props) { ... }`ing that every time. Is that bad?

Surely there are drawbacks in refactoring, as unless your editor supports bulk renaming references you will have to rename every single import and usage. Whereas with a default export you have no such issue.

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.