Why does JavaScript have default exports?

Question

Context

JavaScript has two types of exports: normal^[1] and default.

EDIT: JavaScript has two types of export syntaxes

Answer 1

JavaScript has two types of exports: normal and default.

No, not really. JavaScript has only one kind of export structure. It has different syntaxes though.

export default function x() {} is just a shorthand notation for function x(){}; export { x as default }.
import x from '…' is just a shorthand notation for import { default as x } from '…'.

The difference between your the two module exports you discussed is much bigger than the single default keyword. They only look so similar because you used shorthand notations. Fully spelled out, it's

export {
  Foo as Foo,
  Bar as Bar,
} // a declaration

vs

export default ({
  Foo: Foo,
  Bar: Bar,
}); // an object literal

Both normal exports and default exports have the same functionality - they can be imported into a namespace, and they can be destructured into smaller pieces.

No, they don't. Imports provide aliases for the exported variable declarations, there's no destructuring - and you cannot do that to properties of a default-exported object.

What are the reasons JavaScript has default exports, instead of sticking with just normal exports and having the import syntax be the following?

See https://esdiscuss.org/topic/moduleimport. The default-export syntax provides a shorthand syntax for exporting under the special name default (which is not a valid variable name otherwise), as it is a quite common use case to export only a single thing from a module. It doesn't require explicitly naming a value when there is only one in this module anyway. In this regard, it has very much the purpose you envisioned for your export only suggestion, but it is only one export not providing a full namespace of multiple aliasable exports.

Answer 2

export default {
  Foo,
  Bar,
}

I don't understand why you've demonstrated this structure. This isn't how it's supposed to be used.

The default export really be though of as just another export. If you import * as Package from "package" you'll realise... Package.default is the default export

The only change is the syntactic shortcut:

import alias from "package" = import {default as alias} from "package"

It makes consumption of many packages easier / simpler.

---

export = ... is not the same as export default ...

The prior returns a module structure of ... where as latter returns a module structure of {default: ...}

Answer 3

The existence of "default exports" as well as "named exports" is due to design by committee. This was convincingly argued by Andreas Rossberg during the original design discussions:

Some want modules in the conventional sense, as encapsulated namespaces with named exports, which you can import and access qualified or unqualified, and where imports are checked.

Some want modules in the specific pre-ES6 JavaScript style, where they can be any arbitrary JS value, and in the good old JavaScript tradition that checking doesn't matter.

The current design (including the newest suggestions for imports) seems to please neither side, because it tries to be the former semantically, but wants to optimise for the latter syntactically. The main outcome is confusion.

That is, the motivation for "default exports" was not technical, but political, designed to appease those in the CommonJS and AMD worlds, where a module exports a single value. This neatly explains why we have two module systems in one; something we don't see in other programming languages.

(Thanks a lot to Bergi, who found and cited this thread in his answer. However, I disagree with his conclusion that default exports are motivated by a need for a shorthand. I don't see much discussion of this in the original threads.)