Harmony modules feedback

Sam Tobin-Hochstadt samth at ccs.neu.edu
Thu Jan 12 05:16:12 PST 2012


On Thu, Jan 12, 2012 at 1:40 AM, James Burke <jrburke at gmail.com> wrote:
> I did a blog post on AMD that also talks about harmony modules. In the
> "ECMAScript" section I talk about some of the questions I have about
> with harmony modules:
>
> http://tagneto.blogspot.com/2012/01/simplicity-and-javascript-modules.html

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
encapsulated here:
  "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.
-- 
sam th
samth at ccs.neu.edu


More information about the es-discuss mailing list