Modules: compile time linking (was Re: Modules feedback, proposal)
claus.reinke at talk21.com
Tue Apr 3 07:34:22 PDT 2012
> Libraries will need to work in old world browsers for a few years.
> Possible solutions:
> a) Ask libraries to provide a lib.es-next.js version of themselves in
> addition to the old world version, so that compile time linking with
> new "module/import" syntax can be used.
> b) Have a way for the library to do a runtime type check, and opt-in
> to the call.
> c) Something else?
How about these two translation-based options (I'll use mod.current
as a placeholder for whichever current module workaround is in use,
be it CommonJS, NodeJS, AMD, RequireJS, or other script loaders)
1. implement mod.current in terms of ES6 constructs
2. implement ES6 modules in terms of mod.current
For the current phase of spec development, 1 is the more interesting,
as it would show whether ES6 modules are sufficient as a basis
for implementing currently used module patterns. Any gaps pointed
out by such an effort could still influence the ES6 modules spec.
However, such translators might tempt developers to stick with
their old mod.current code, knowing that it will run on ES6.
Longer term, 2 is more desirable, as it would allow to retire/phase
out the variety of mod.current efforts. Once ES6 modules are
stable, programmers could start experimenting with them, giving
feedback on the useability of the spec. The various mod.current
implementations (via translation from ES6 modules) could
serve as polyfills for ES implementations that do not yet support
Note that, while it may be possible to map parts of mod.current
to static ES6 modules, it is likely that some static-looking forms
in mod.current will map to dynamic ES6 modules. Also, when
mapping ES6 modules to mod.current, one will be hard-pressed
to emulate the static checks, but as a polyfill, then remaining
functionality will still be useful.
More information about the es-discuss