[whatwg] Preparing <script> for ES6 modules

Jonas Sicking jonas at sicking.cc
Thu Aug 30 08:45:58 PDT 2012


Hi All,

The current ES6 drafts have the ability to declaratively linking to
script modules. These modules live in external resources, i.e. they
are a separate script file. The intent is that these should be loaded
before the script is executed and so no blocking IO is required, even
though the syntax "looks" synchronous, i.e. doesn't have any
asynchronous callbacks or similar.

This is very similar to how the @import rules work in CSS.

You can read more about them at
http://calculist.org/blog/2012/03/29/synchronous-module-loading-in-es6/

This will work fine in HTML for plain <script src="..."> and <script>
appearing in the markup. The browser simply blocks the parser until
all dependent script modules have been loaded and then executes the
script like normal. However it's not currently possible to do
something like

<script defer>
import $ from "jquery.js";
$(...);
</script>

or

<script async>
import $ from "jquery.js";
$(...);
</script>

since the defer and async attributes are ignored for inline scripts.
This technically works, but means that you can't take advantage of the
performance advantages that defer and async provides, unless you also
break out your script into an external file which cause an additional
resource load.

We could define that async and defer only has effect on inline scripts
if these scripts contain references to external modules. However that
means making their behavior a lot more inconsistent and error prone.
Especially if contents of the script element contains server-side
generated code which may or may not include module references.

So I propose that we make defer and async consistently apply in inline
scripts. The defer attribute used to apply to inline scripts in the
firefox and IE implementations. It no longer does in Firefox, but I
haven't tried in IE. However this still seems to lessen the risk of
webcompat regressions significantly. The async attribute is new enough
that I wouldn't be worried that there is a lot of content out there
that would be affected by this change.

Let me know what you think.

/ Jonas


More information about the whatwg mailing list