ES modules: syntax import vs preprocessing cs plugins

Claus Reinke claus.reinke at
Thu Jul 5 15:13:19 PDT 2012

>> 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.

>> 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

It is still more complex than I'd like (I was hoping for something
like requirejs.config [*], with added loader configuration), but at 
least this works.


It would be useful to have examples of *adding* loader-based
dependencies to a project which already has other imports, on 
the wiki page. Please feel free to reuse the three examples if
you like.

>> 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 other words, I would like to see an in-ES solution to the issue
of using module loaders without dropping out of synchronous
loading and module syntax. 

Then the host environment bodies could provide additional,
simpler ways to use this in-ES functionality.

If a project has to be rewritten when taking it out of client-side
host environment, then a big part of the advantage of having
an ES standard module system is gone.

Thanks for engaging in these discussions. I think they are
important to find and smooth out the rough edges of the
ES modules spec.


More information about the es-discuss mailing list