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@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
parsed.
I'm a big fan of script@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)
else
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>.
David
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
