We had a discussion in TC39 this week about how to think about the JS module system's default export feature. It turns out one of the ways people explain this feature is as a shorthand for an export with the name `default`

. For example:

```
import LoadingSpinner from 'loading-spinner';
```

is equivalent to:

```
import { default as LoadingSpinner } from 'loading-spinner';
```

This is technically accurate information. But it doesn't explain the *programming intuition*. After all, if these two forms are equivalent, why is the shorthand even there?

The insight of CommonJS modules is that a module is often organized around a single abstraction, where the conceptual name of the module wants to be the same as the primary abstraction it publishes (`LoadingSpinner`

, `SkipList`

, etc.). That's why we added these defaults to the UX: to express this common use case naturally. The fact that default exports are represented with the name `default`

is secondary.

This reminds me of Terence Tao's great blog post about the three stages of maturity in mathematicians, which he calls the "pre-rigorous," "rigorous," and "post-rigorous" stages. What he noticed is that a lot of people get stuck in that second stage:

It is of course vitally important that you know how to think rigorously, as this gives you the discipline to avoid many common errors and purge many misconceptions. Unfortunately, this has the unintended consequence that

“fuzzier” or “intuitive” thinking... gets deprecated as “non-rigorous”. All too often, one ends up discarding one’s initial intuitionand is only able to process mathematics at a formal level, thus getting stalled at the second stage of one’s mathematical education.

I see this a lot in standards and design: as we spend more and more of our time swimming in formalisms like specs, semantics, or implementations, it's easy for us to overlook those "fuzzier intuitions." Just like in mathematics, rigorous tools like specs help us to be precise, but the mechanism of our designs and the developer's mental model they support are two separate things. Learning to be able to move back and forth between rigor and intuition is one of the key skills of good design.