ES modules: syntax import vs preprocessing cs plugins

Sam Tobin-Hochstadt samth at
Thu Jul 5 15:30:24 PDT 2012

On Thu, Jul 5, 2012 at 6:13 PM, Claus Reinke <claus.reinke at> wrote:
>>> Similar to the dummy project sources, the nature of the loader
>>> is not important to the concerns expressed in my message (in
>>> the comments).
>> I disagree -- it's not possible to know what the requirements are, how
>> else they could be solved, what the current state-of-the-art is, and
>> how common this will be without further details.
> Well, I got useful answers (thanks!) without distractions by
> unnecessary details;-)
> But if you insist, consider the following scenario: adding a project
> dependency which is written in current node style (require/export; in a
> subset that can be translated into ES modules by using a translate hook).
> And doing so without rewriting the existing code,
> in either the dependency or the importer.

Ok, this will work fine using the multiple script tags approach you showed.

>>> Meanwhile, a third variant occurred to me: we might be
>>> able to make use of the staged loading to limit the impact
>>> of the rewrite, and to recover from asynchronous loading
>>> and dynamic usage back to synchronous loading and module
>>> syntax. ..
>> Yes, this should work fine.
> Okay, that solves part of the problem for client-side apps. We can
> use extended loaders without having to switch every import to callback
> style.
> Would this, in combination with the resolve hook, also allow
> to make dynamic decisions about which dependency to import
> (or rather, which code to return when a certain dependency is
> imported)? This seemed to be one of the features James was
> requesting.

Yes, in the code you showed, you were just writing JS code, so
obviously it could have conditionals in it.

>>> what is the equivalent mechanism server-side?
>> That's a choice that the designers of server-side JS frameworks can
>> make.  The boundary between script tags could be translated into the
>> boundary between files, or statements, or forms typed into the REPL,
>> or something else.
> This, however, I cannot support. Yes, there are decisions which
> tc39 needs to leave to the bodies standardizing the ES host
> environments. Nevertheless, it should be possible to write cross-platform ES
> code without reference to the host environment.

In so far as the ES spec makes no reference to files, script tags, or
REPLs, this would be a big step in tc39 taking over the responsibility
of designing other people's systems. For browsers, tc39 has most of
the vendors in the room, but that's not the case for other kinds of JS

If you have a suggestion for how this could work, I'm all ears, but so
far, this sounds unlikely.
sam th
samth at

More information about the es-discuss mailing list