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 about.
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.
Nope.
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.
/be _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
