detecting JS language mode for tools

David Bruant bruant.d at
Mon Jan 27 02:07:20 PST 2014

Le 27/01/2014 06:45, Brendan Eich a écrit :
> Kevin Smith wrote:
>>         Is a new attribute necessary? What about using @type?
>>     Old browsers will ignore unknown types, losing the two-way
>>     fallback option.
>> Two-way fallback?  Why is that important?  Since modules are 
>> implicitly strict, there is little intersection between scripts and 
>> modules.
> One can write strict code that runs fine in old browsers!
Yes. For transition from non-strict to strict and advice on writing 
strictness-neutral code, there is
(reviews welcome)

> Why do we want inline module-bodied elements in HTML? That's the topic 
> here.
Indeed. I'm wondering why we need inline <script> for modules.  
Historically [1], the good practice regarding inline <script> was to put 
them either in <head> or before </body> (the rest of the scripts can 
load after DOMContentLoaded/load or on demand).
I imagine modules are intended to be reusable, "stateless", 
timing-independent pieces of code. If, for perf reasons, we do need JS 
to be in the page alongside the HTML, we don't need it to run right away.

I feel that without too much work, we can have best of all worlds.
Module code could be sent along the HTML inlined, but with an 
unrecognized @type (and a class like "module"), so that it runs in 
neither old or new browsers. At a time decided by the author, the author 
can do:

     var scripts = document.querySelectorAll('script.module');
         [], function(s){ 
loader.load(s.textContent) });
         [], function(s){ (1, eval)(s.textContent)) };

(I'm not sure about the edges, but you get the idea)

We get the network perf benefits of sending the modules over the wire. 
The only way it differs with inline scripts is the scheduling, but I 
wonder how often it'll be important to load modules before DOMContentLoaded.



More information about the es-discuss mailing list