bradley.meck at gmail.com
Wed Aug 19 13:09:03 UTC 2015
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
* * 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 <isiahmeadows at gmail.com>
> There are ways for syncing promises for Node compatibility, although they
> all lie in C++ land. Similar has already been done with Node callbacks.
> (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.meck at 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
>> On Tue, Aug 18, 2015 at 4:56 PM, Jason Orendorff <
>> jason.orendorff at gmail.com> wrote:
>>> On Tue, Aug 18, 2015 at 12:45 PM, Bradley Meck <bradley.meck at gmail.com>
>>> > This would assume they can support the transformation hooks to do
>>> > like load coffeescript etc. right now, which is the main contention
>>> It is a perfectly ordinary occurrence in software to ship some
>>> capability at one point, and ways of customizing that capability
>> es-discuss mailing list
>> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss