simpler, sweeter syntax for modules
brendan at mozilla.org
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
http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders 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