Describe fallback based on top-level await

[littledan]

Addresses #61

[ljharb]

I’d be hesitant to include TLA in the readme - its current semantics are viral and may end up being untenable (in particular, they might make CJS support in ESM not possible, as well as having impacts in a pure ESM graph).

[littledan]

@ljharb @jdalton Even if you have concerns with the proposed solution, do you think the use case is realistic?

[ljharb]

All of my use cases require synchronous feature testing, method caching, and polyfilling/shimming, so I’m not sure if an await-based solution would help any of them.

[MylesBorins]

in particular, they might make CJS support in ESM not possible

Unsure how this is the case when it is only supported in the module goal

[ljharb]

My understanding is something like this: ESM A imports CJS B which requires ESM C, and C suddenly adds TLA, which would force B to be async, which would interfere with A's import of it.

[MylesBorins]

@ljharb there is no current plan that would have ESM being able to be required in CJS... only option right now is dynamic import which is already async... I still fail to see this limitation

[zenparsing]

There are practical module systems (e.g. esm) that allow CJS to depend directly on ESM source modules. Top-level await will present difficulties for such systems, widening the impedance mismatch between CJS and ESM rather than narrowing it.

Regarding this PR specifically, it highlights another concern that I have about TLA. By adding an attractively dynamic alternate import form (await import(...) ) we risk confusing users about which variant to use.

[littledan]

Well, I proposed another solution in #61 which does not depend on top-level await. Let's discuss the problem there.

[dcleao]

@ljharb, I think that @littledan was asking if you think that the described use case is realistic, and not if it is one of your (node?) use cases...

I feel a constant push-back on TLA, or on any form of user-land JS being able to participate in module resolution, and possibly loading. As described in the explainer, the presented reason is that switching between JS and native context is very expensive. That's surely objective, and I don't think anyone argues that that is true. However, that's not what's relevant, imo. Instead: how much slower is it compared to the alternatives that users will have to resort to to implement those use cases? Or, how worse is that compared to the impact that its absence causes on the shape of APIs?

We're flooded with valid, still current use cases. Just observe existing AMD/RequireJS applications (or SystemJS)! Definitely, these applications favor a JavaScript-centric approach to components.

Other proposed technologies, such as HTML-modules, CSS-modules and JSON-modules (let's create a spec for each file type!?) favor an HTML-centric approach to components.

I think that not having TLA or some form of loader plugin technology, it won't be possible to effectively develop JS-centric components (and probably also severely limit HTML-centric components).

Some use cases:

• i18n loader plugin — implement a way to ("statically") import a "JSON strings" resource file corresponding to the browser's current locale; the plugin can be configured with the list of locales for which resource files exist.

• theme loader plugin — load a different set of CSSs depending on the currently selected application theme; the plugin is configured with available theme names and corresponding CSS files/modules.

• module configuration plugin — load the configuration (similar to out-of-band metadata) of a JS module; the effective configuration is the result of merging multiple JSON files/modules; the set of applicable files depends on the values of "global" variables of the current environment (which can change on each load; not defined at compile time (a fixed manifest, as suggested, doesn't work).

None of these would be possible to be implemented solely with client-side technologies (without dynamic, server-side endpoints).

Not everything is defined at static, compile time. The desired flexibility requires late-binding of configurations. And, we don't want that the asynchronous loading of configurations to leak asynchronicity (Promise in every return value?) to the APIs themselves.

CJS and the Node environment are not of the same nature of the Web environment. And the Web environment shouldn't become "jailed" by the nature of CJS.

I'd love to know the opinion of @guybedford on these subjects.

[littledan]

This is an interesting discussion. Can we move it to the top-level await repo?

[domenic]

LGTM with some minor nits, pushing those nits and merging

[domenic]

It doesn't block import; it suspends execution like a normal await does. So I'll remove this last sentence as it seems to add confusion.