We have discussed the issue somewhat at length with the WHATWG loader spec with calls. We agree that having diverging async/sync properties is problematic if a feature is present in both Node and the browser.
* the consensus is `System.import` returns a `Promise`, which means the execution of the load can always be done during the promise job queue. * Loader hooks for fetch/transformation/execution are left unspecified in terms of async/sync * * this delegates the branching logic from the Loader spec to the Loader implementation and creators of Loader hooks, metadata can be provided to feature detect what kind of Loader it is * using co-routines/non-typical JS can be avoided and any potential compatibility problems with VMs can be avoided as well. * * also avoids some VM limitations about only being able to materialize objects on the VM thread * new syntax is the branching for breaking changes * * opt-in of ES6 modules changes the loading order for modules for Node, but execution order can be kept consistent with what an async loader would perform * * circular bindings are an error (not circular dependencies) * `System.import` is still able to use `require` in node and preserve blocking nature some modules expect/require. * there is some inconsistency currently about when user `Promises` resolve *during* code loading, these should be looked into more A decent amount of information is not fleshed out in the spec / is discussed via email, so I would suggest moving to issues on the WHATWG Loader's github: https://github.com/whatwg/loader Until Loader is in a decent enough shape that both Node and WHATWG give it a thumbs up, I would wait. On Wed, Aug 19, 2015 at 3:38 AM, Isiah Meadows <isiahmead...@gmail.com> wrote: > There are ways for syncing promises for Node compatibility, although they > all lie in C++ land. Similar has already been done with Node callbacks. > > https://www.npmjs.com/package/sync > > (You could also spawn a thread, block for a message, and join it with the > promise result from a C++ callback from a thenable.) > > On Tue, Aug 18, 2015, 18:06 Bradley Meck <bradley.m...@gmail.com> wrote: > >> The problem is timing; WHATWG uses promises, which Node cannot use due to >> existing code bases on npm + potential mixing w/ `require`. This causes >> time discrepancies and would mean different actions depending on how >> exactly hooks are specced out. Node does not want to prevent async loading >> on the browser, and the WHATWG loader does not want to cause breakage in >> Node. >> >> On Tue, Aug 18, 2015 at 4:56 PM, Jason Orendorff < >> jason.orendo...@gmail.com> wrote: >> >>> On Tue, Aug 18, 2015 at 12:45 PM, Bradley Meck <bradley.m...@gmail.com> >>> wrote: >>> > This would assume they can support the transformation hooks to do >>> things >>> > like load coffeescript etc. right now, which is the main contention >>> point. >>> >>> It is a perfectly ordinary occurrence in software to ship some >>> capability at one point, and ways of customizing that capability >>> later. >>> >>> -j >>> >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
