User guidance considering import defer and export defer

[guybedford]

I wanted to just take another step back and think about guidance in the ecosystem here.

With export defer:

lib.js

export defer { foo } from 'foo';
export defer { bar } from 'bar';

we usually encourage direct named imports to save network/fetching costs. That is the best practice.

Then when using import defer we have to incur the full network costs of loading all modules in the barrel file, but still do the lazy execution:

app.js

// loads and links both foo and bar, even if foo is never used
import defer * as lib from 'lib.js';
// executes bar lazily here
lib.bar;

In the case of a large barrel file (say 100s of modules), the execution savings in the above doesn't save you from the network cost.

From a user perspective, it might not be clear that there is a huge cost to using import defer * as lib over import { foo } from lib, so that it might actually be worth not recommending this case? But now we have a confusion - current guidance we want to send is "use import defer it's faster", but then with this proposal we want to send new guidance "don't use import defer with barrel modules". How are users to know which to use?

Some questions:

1. How to ensure clear ecosystem guidance? How should consumers know when to use import defer and not given that the usage guidance between these two forms is effectively contradictory to achieve best practices.
2. To better understand exactly the use case is for supporting import defer alongside export defer together? What sort of use cases and real user modules would need exclusively both, but not either? Given that if export defer is used for barrel files, then those barrel files should in general not be import deferred. All of the machinery around the [[DeferredModules]] field on Resolved Binding record seems to be entirely for this, so I just want to make sure we have a clear justified use case here that we have in mind as we are effectively implementing two separate features.
3. Is it worth considering a reframing of this proposal that prioritises one of these use cases over the other (barrel files, versus partial namespace execution). It would be nice if we had some numbers as well to back up which use case is more important to us here.

[ljharb]

Barrel modules are becoming more widely recognized as problematic anyways - so I think the best advice is "don't use barrel modules at all", personally.

[guybedford]

This is kind of the question I'm trying to understand here - what is the clear use case that is not barrel files that this proposal enables?