DaveH's presentation about module loaders
Shouldn't any newly designed async loading APIs support promises?
No, for the very simple reason that promises have not been standardized
and won't be in ES6.
Understood. Though this leaves us with:
- use of module loaders could profit from promises (eg, importing several
modules in parallel, waiting for all of them to be available, or mixing
module with other promise-based dependencies)
- promises are in wide-spread use, are not standardized in ES, and do not
seem to converge on a single implementation/API; as long as ES specs
couldn't profit from promises, that was not as much of a problem
For the special case of modules, one could add off-spec support for a
currently popular promise library, to avoid further divergence.
It Just Works. :) JS is a multi-staged language. One stage can modify
the module table, and then later scripts will be compiled in the context
of that new module table. The module itself is immutable.
So, a set only influences later dynamic loads? And the latest set before
load wins? And, since "static" import is synchronous (same stage), any
"static" construct textually after the set, but in the same stage, refer to
the old module table, while the set-effect is implicitly pending?
Is the multi-stage aspect spelled out somewhere? In particular, I
would have expected to be able to use "static" module constructs
in module loader callbacks:
// stage n
System.load("m", m => // "static" checks for stage n+1 at load-time
import {f,g} from m; // stage n+1
f(1,2);
)
but ImportDeclaration seems limited to Program and ModuleBody.
Wouldn't it be more honest to use conditional
loading, falling back to dynamic module handling?
You can certainly do that too. But the idea of polyfills is that client
code (including third-party libraries you may be using that you don't
want to or can't change) should be able to be written to recent
versions of a standard API, and the polyfill makes sure to back-fill
any gaps in older environments.
I keep forgetting that parameterized modules are not yet on the
table. If imports were module parameters, one could pass in patched
imports to unchanged importers, without having to assign to the
module table (fewer side-effects).
Module syntax alternatives:
module x at "foo.js"
module x = "foo.js"
module "foo.js" as x
module x at "foo.js"
module x from "foo.js"
As I've said before, this uses "from" inconsistently -- it muddles the
difference between binding a name to an external module (module
x from "foo.js") and binding a name to a specific export of an external
module (import x from "foo.js").
"from" on its own doesn't do much, it is a modifier; "module" and
"import" are the operative words. "module x from source" indicates a
non-inline module, to be fetched from source, "import x from module"
indicates a non-inline declaration, imported from module.
Since module declarations are just declarations, one might also consider
'import m from "foo.js"', but that wouldn't make a syntactical distinction
for non-inline module declarations.
Claus
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
