Why does JavaScript have default exports?

2
votes

Context

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

EDIT: JavaScript has two types of export syntaxes

Normal exports

class Foo {...}
class Bar {...}

export {
  Foo,
  Bar,
};

or

export class Foo {...}
export class Bar {...}

Normal exports can be imported in two ways: namespace[1] imports and named imports (looks similar to destructuring).

Namespace imports

import * as Baz from './baz';

Named imports

import {Foo, Bar} from './baz';

Default exports

class Foo {...}
class Bar {...}

export default {
  Foo,
  Bar,
};

Default exports can also be imported in two ways: namespace imports and named imports (in a hackish way using destructuring in a separate statement)

Namespace imports

import Baz from './baz';

Named imports

import temp_Baz from './baz';
const {Foo, Bar} = temp_Baz;

Question

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.

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

import <varName> from <location>;

<varName> would allow destructuring like any variable assignment, without a special "named" import.

Node.js managed without default exports, and the only additional change would be to allow exporting of a single value:

module.exports = class Foo {...}

This could be done with export = or export only or something similar:

export only class Foo {...}

So now you might ask, what is the difference between export only and export default?

  • export only exports could be imported with the same syntax, whereas export default requires a different importing syntax. To allow both syntaxes to work for the module user, the module must both export and export default the same items (which is something I do in all my modules).
  • export default is renamed to export only which is a better term in my opinion (less confusing; clearer)

2) All the differences listed above are pros. Are there any other differences that are cons? Or can any of the above differences also be cons?

Edit

It seems I misunderstood the intended use for export default.

It's for adding a default export on top of the regular exports.

So I'd now like to know when are default exports used? Although I probably shouldn't add more to this question.

If the only use for default exports is if your module only has a single item to export, then this question still applies.

Edit 2

Now it seems that the intended use is if a module only exports a single item. So my question still applies. Why not replace default exports with export only, removing the need for an additional default import syntax?

Notes

[1] I am not sure if this is the correct term to use

3
javascriptes6-modules
Matter of preference, I’d say. I prefer named as well because IDEs autosuggest them whereas in case of default imports I need to type them myself. – The Witness
@TheWitness Both named imports and namespace imports can still be done without default exports. My question isn't about named vs namespace, but why default exports are a thing. Node.js doesn't have default exports but still allows named imports using destructuring. – David Callanan
import {Foo, Bar} from './baz'; != import temp_Baz from './baz'; const {Foo, Bar} = temp_Baz; – Tobiq
@Tobiq I'm aware they are not the same. But from what I know, it is the equivalent when working with default exports instead of regular exports. – David Callanan

3 Answers

2
votes

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.

2
votes

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.)

0
votes
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: ...}