It will not block, modules are async by nature. what make you think this proposal implies blocking?
Sent from my iPhone
> On Dec 20, 2014, at 1:04 PM, John Barton <johnjbarton at google.com> wrote:
>
>
>
>> On Fri, Dec 19, 2014 at 8:55 PM, caridy <caridy at gmail.com> wrote:
>> inline...
>>
>> > On Dec 19, 2014, at 3:21 PM, James Burke <jrburke at gmail.com> wrote:
>> >...
>> > * How does dynamic loading work in a web worker? In general, how does
>> > dynamic loading work when there is no DOM.
>>
>> think about this as nodejs without NPM and core modules, where we can only do `require(‘./path/to/something.js’)` and `require(‘/full/path/to/something/else.js’)`, and we can evolve from there. The web worker is definitely in our radar, we just don’t have a solution for it without the loader implementation (same for realms).
>
> This seems to imply that module loading would be a blocking, synchronous call. Such a change would have huge implications, just as the previous Loader's async dynamic API did in reverse. Either way I hope there will be some public debate on that issue so we come away believing the best choice was made.
>
> jjb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141220/5a33dd22/attachment-0001.html>
d at domenic.me (2015-01-05T21:08:55.959Z)
It will not block, modules are async by nature. what make you think this proposal implies blocking?
