Static Module Resolution

Aymeric Vitte vitteaymeric at
Thu Jul 5 16:15:09 PDT 2012

> I don't understand your comment about `window` and `document`.  They
> are already globals in browser JS environments.
Please, take some time to read again my previous posts, I am refering to 
both server side's and browser's env, with 'window' and 'document' that 
are familiar as examples, but these could be 'mylocalvar1' and 
'mylocalvar2' in both (and in my server side examples 'window' and 
'document' are not supposed at all to be in fine globals)
> As for async, there are a variety of ways to make it easier
No, the only way to ease your life is to define a lot of things as 
globals which some people like myself might not want to do, same as var 
script_=document.createElement('script') callbacks, modules are 
reproducing the same

I don't know if you develop everyday async code handling multiple asyncs 
stuff but it becomes all the time very quickly a nightmare
> , but we
> are *not* going to add synchronous IO as part of the module system.
> The run-to-completion semantics of JS are non-negotiable.
Then the sync xhr is absurd ?

The "non-negotiable" word reminds me some famous vendor not implementing 
the sync xhr for obscure purposes (not blocking the app or something 
like this), I did not check since that time but I would bet they finally 
implemented it

It is really needed and looks so simple, do we have to live forever with 
the xhr limitations or can this simple thing be included ? (I understand 
it does not follow the global logic of modules/loaders but there might 
be a way)

Email :  avitte at
Web :
Webble :
Extract Widget Mobile :
BlimpMe! :

More information about the es-discuss mailing list