March 29 meeting notes

David Herman dherman at mozilla.com
Fri Mar 30 19:29:43 PDT 2012


On Mar 30, 2012, at 7:42 AM, Claus Reinke wrote:

>> DaveH's presentation about module loaders
> 
> Shouldn't any newly designed async loading APIs support promises?

No, for the very simple reason that promises have not been standardized and won't be in ES6.

> For ES proposals, promises seem to be burried in the concurrency
> strawman.

It's not being considered for ES6.

>> DaveH: Imperative module replacement example:
>> @websockets exists as version 1.  An implementation wants to improve it to v2:
>> import "@websockets" as ws;
>> System.set("@websockets", polyfills(ws));
> 
> That looks a bit like fiddling with Object.prototype for polyfills. Is that
> the recommended approach, and how does it interact with the static
> aspects of modules?

It Just Works. :) JS is a multi-staged language. One stage can modify the module table, and then later scripts will be compiled in the context of that new module table. The module itself is immutable.

> Wouldn't it be more honest to use conditional
> loading, falling back to dynamic module handling?

You can certainly do that too. But the idea of polyfills is that client code (including third-party libraries you may be using that you don't want to or can't change) should be able to be written to recent versions of a standard API, and the polyfill makes sure to back-fill any gaps in older environments.

>> Module syntax alternatives:
>> module x at "foo.js"
>> module x = "foo.js"
>> module "foo.js" as x
>> module x at "foo.js"
> 
> module x from "foo.js"

As I've said before, this uses "from" inconsistently -- it muddles the difference between binding a name to an external module (module x from "foo.js") and binding a name to a specific export of an external module (import x from "foo.js").

Dave



More information about the es-discuss mailing list