Do Anonymous Exports Solve the Backwards Compatibility Problem?
claus.reinke at talk21.com
Fri Dec 21 01:39:20 PST 2012
> * The module loader API exposes a "runtime" API that is not new
> syntax, just an API. From some earlier Module Loader API drafts, I
> thought it was something like System.get() to get a dependency,
> System.set() to set the value that will be used as the export.
> * Base libraries that need to live in current ES and ES.next worlds
> (jquery, underscore, backbone, etc…) would *not* use the ES.next
> module syntax, but feature detect the System API and call it to
> participate in an ES.next module scenario, similar to how a module
> today detects if it wants to register for node, AMD or browser
There is a slightly annoying mismatch here, though: ES6 modules
are *compile-time* constructs, so jquery et all cannot completely
integrate by using ES6 *runtime* APIs. If code depends on jquery,
jquery will need to be loaded explicitly, by hand, before the
dependency resolution for the caller starts (ie, a separate script
element), even if jquery starts to use System.set to register itself.
This wasn't an issue with ES5 module libraries, where everything
was runtime and nothing was checked - you could have dependencies
that registered themselves (or were registered by shims) on load.
One might be able to have a special-purpose loader, though,
which knows about jquery and handles it in its resolve/load
hooks, similar to config shim?
> * Modules using the ES.next module syntax will most likely be
> contained to "app logic" at first because not all browsers will have
> ES.next capabilities right away, and only apps that can restrict
> themselves to ES.next browsers will use the module syntax. Everything
> else will use the runtime API.
I'd prefer to use transpilers, mapping new syntax to runtime constructs
in old engines. That way, all newly-written code can use the same, new
syntax, but the compile-time checking advantages only come into play
when the transpilation step is removed, and ES6 engines are used.
We are now in the odd situation that there is a user base for ES6
modules in TypeScript, but since the ES6 module spec is still in progress,
TS has a mix of partially-implemented old spec and not-yet-implemented
The idea is to use modern module syntax, and transpile to AMD or
CommonJS or ES6, as needed. Currently, TS coders try out external
modules, find them cumbersome, and fall back to reference paths
and internal modules (which translates to includes+iifes), but that
is merely a result of the current spec and implementation state.
> For using ES5 libraries that do not call the ES Module Loader runtime
> API, a "shim" declarative config could be supported by the ES Module
> Loader API, similar to the one in use by AMD loaders:
> this allows the end developer to consume the old code in a modular
> fashion, and the parsing is done by the ES Module Loader, not userland
I'd very much like to see a config-shim-look-alike implemented in
terms of the updated ES6 modules spec, just to be sure it is possible.
This is important enough that it should be part of the ES6 modules
More information about the es-discuss