Thanks for writing this -- we appreciate the feedback. [As an aside,
Dave and I still plan to address your point that module instance
objects need to be usable as functions.]
As to your current post, I think the fundamental disagreement is all
"ES harmony may be able to do something a bit different,
but the basic mechanisms will be the same: get a handle
on a piece of code via a string ID and export a value."
First, there are two things you might mean by "piece of code". One is
"the source code for a library/script", which is necessarily
identified by a URL on the Web (perhaps by a filename in other
contexts, like Node). That stays as a string in every design. The
other is "a library that I know I have available", and that we're not
using strings for. Instead, you refer to modules by name, just like
variables are referred to by name in JS.
Second, we don't want to just stop with "export a value". By allowing
the module system to know something ahead of time about what names a
module exports, and therefore what names another module imports, we
enable everything from errors when a variable is mistyped to
cross-module inlining by the VM. Static information about modules is
also crucial to other, long-term, desires that at least some of us
have, like macros.
Third, the "basic mechanisms" available for existing JS module systems
require the use of callbacks and the event loop for loading external
modules. By building the system into the language, we can not only
make life easier for programmers, we statically expose the
dependencies to the browser, enabling prefetching -- here, the basic
mechanisms don't have to be the same.
es-discuss mailing list