On Thu, Mar 22, 2012 at 1:54 PM, Brendan Eich <[email protected]> wrote: > 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.
Some how we are not communicating. I'm talking about AJAX based systems. It's all about blocking computation on network. > > >> 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. and this is why require.js uses callbacks. We need a module solution that explicitly helps dynamically load source code, not one that forces ad-hoc solutions. We already have that. The module solution posted seems to have a top-notch solution for the static case but the dynamic case is buried in the loader. jjb > > /be _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
