5 June 2014 TC39 Meeting Notes

David Bruant bruant.d at gmail.com
Sat Jun 14 05:32:10 PDT 2014

Le 12/06/2014 16:43, Domenic Denicola a écrit :
> Also, David: <module>s are not named; you cannot import them. Check 
> out 
> https://github.com/dherman/web-modules/blob/master/module-tag/explainer.md
Thanks, that's the context I was missing.

I'm uncomfortable with the "async" part of the proposal as currently 
(under?)specified. Sharing my thought process.

Async loading prevents the rendering blocking problem, but creates 
another problem.
async loading isn't an end in and of itself. As far as I'm concerned, I 
never use script at async for app initialization code (which is the target 
of the <script type="module"> proposal) because it offers no guarantee 
on whether the script will be executed before or after the HTML is fully 
I'm a big fan of script at defer though, because I have a clear idea of 
loading order (which will be covered by modules, so unimportant for the 
topic at hand) as well as when the script will be executed (when the 
HTML is fully parsed and DOM is complete, but before the 
DOMContentLoaded event)

I'm extremely interested in how other devs use the @async attribute in 
practice. In the context of an application, scripts that have no 
temporal dependency with other scripts loaded in the same document are 
rare beasts.

Back to <script type="module">, I'm not sold on arbitrary "async" 
loading if it forces me to add this boilerplate:
     // assuming function loadApp(){}
     if(document.readyState === "loading")
         document.addEventListener('DOMContentLoaded', loadApp)

A @defer semantics for <script type="module"> might make more sense and 
not force all devs to add the above boilerplate to make sure their code 
loading is robust to the laws of physics.
If people want to execute scripts before the HTML is fully parsed they 
can just use regular <script>.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140614/afac146f/attachment.html>

More information about the es-discuss mailing list