Modules: compile time linking (was Re: Modules feedback, proposal)

Claus Reinke 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
ES6 modules.

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.

Claus

 


More information about the es-discuss mailing list