simpler, sweeter syntax for modules

Brendan Eich brendan at
Thu Mar 22 13:54:58 PDT 2012

John J Barton wrote:
> Second, we need a solution for asynchronous loading with run-time
> selection. We use it now and as we move to much better network layers
> we will use it a lot more.

Of course. This is what the API is all 

> I don't really understand what you are saying above. Blocking the
> initial page rendering is not on anyone list of needs.  On the other
> hand blocking computation on network is not at all unthinkable, but
> rather it is the standard practice.


>   This should be a first class part
> of the module solution.

I don't know what you mean here. First class meaning modules reflect as 
objects? But that has nothing to do with blocking vs. non-blocking i/o. 
No blocking i/o apart from sync XHR (a botch to be killed) on the client 
side. Even sync filesystem (local storage) i/o causes jank.

This is why JS APIs have callbacks, generally, and closures help write 
callback-based non-blocking i/o multiplexors.


More information about the es-discuss mailing list