There should be an async version - `deferAsync`?

[mitschabaude]

This proposal adds a cool new feature (fetching/linking a module without executing immediately) but denies that feature to all modules which use top-level await (TLA).

This clashes with the current ESM model where modules that use TLA are treated just like any other modules, anywhere: import statements work normally for them and import() is async already. ESM established a world where modules can safely use TLA without downsides.

This proposal breaks that model. It makes modules that use TLA worse than other modules because there is no way to fetch them while defering their execution.

This seems unnecessary, because there could just be an async version of defer, which allows you to defer execution of an entire TLA module. Many consumers don't care about the described "problem" that exposing something becomes an async function; for them the async version of defer would be the better version, because it would defer a larger part of the execution.

I propose:

import deferAsync * as myModule from "mypath"

Let's examine possible behaviors:

• myModule is a promise itself, and executed only when it is awaited
  • this seems a bit weird, because awaiting a promise can usually not trigger anything in JS
• all properties of myModule are promises; the module is executed only when one of them is accessed.
  • this seems natural, and is very similar to defer, where myModule basically becomes a smart proxy for the module

To reiterate, deferAsync would be a strictly better version of defer for all consumers that are fine with getting promises.

[mitschabaude]

In light of https://github.com/tc39/proposal-defer-import-eval/pull/28, there could also be import.deferAsync('<specifier>')

[ljharb]

typically, a promise is a placeholder for the future value of work that has already begun, so I think it'd be very surprising and weird and unidiomatic to have awaiting it actually cause anything to happen.

[mitschabaude]

typically, a promise is a placeholder for the future value of work that has already begun, so I think it'd be very surprising and weird and unidiomatic to have awaiting it actually cause anything to happen.

yeah I wrote that as well. but having a bunch of properties that are promises and having the property access cause the work to happen seems fine (same as proposed behavior for defer)

[nicolo-ribaudo]

Oh the web you can already get this behaviour, by combining modulepreload and dynamic import:

<link rel="modulepreload" href="./that/module.js">

later(async () => {
  let mod = await import("./module.js");
});

Except for some specific circumstances, such as devices with very load bandwidth, when you call dynamic import the module will have already been fully loaded (including its dependencies), parsed and linked.

To reiterate, deferAsync would be a strictly better version of defer for all consumers that are fine with getting promises.

No, most of those consumers should just use dynamic import, since it allows skipping more work (i.e. loading/parsing).

The main motivation of this proposal is that, unlike dynamic import, allows deferring synchronously.

[mitschabaude]

@nicolo-ribaudo thanks for the answer. This is a good point.

I still feel deferAsync would be a natural addition, and a much "nicer" way to declare a lazy dependency than the html tag (also for the reason given in #15). Also, note that the preload tag isn't really accessible to library authors - my hope is that deferAsync would be, because bundlers would respect it.

But I accept that deferAsync doesn't add anything which is fundamentally impossible right now, while defer does.

[silverwind]

As for syntax, I suggest using import attributes, see https://github.com/tc39/proposal-defer-import-eval/issues/5#issuecomment-2038863806.