domenic at domenicdenicola.com (2014-02-04T15:56:29.020Z)
Le 27/01/2014 06:45, Brendan Eich a écrit :
> 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
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions_and_function_scope/Strict_mode/Transitioning_to_strict_mode?redirectlocale=en-US&redirectslug=JavaScript%2FReference%2FFunctions_and_function_scope%2FStrict_mode%2FTransitioning_to_strict_mode
(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');
if(es6modulesSupported){
[].forEach.call(scripts, function(s){ loader.load(s.textContent) });
}
else{
[].forEach.call(scripts, 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.
[1]: http://www.youtube.com/watch?feature=player_detailpage&v=li4Y0E_x8zE#t=1537
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 https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions_and_function_scope/Strict_mode/Transitioning_to_strict_mode?redirectlocale=en-US&redirectslug=JavaScript%2FReference%2FFunctions_and_function_scope%2FStrict_mode%2FTransitioning_to_strict_mode (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'); if(es6modulesSupported){ [].forEach.call(scripts, function(s){ loader.load(s.textContent) }); } else{ [].forEach.call(scripts, 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. David [1] http://www.youtube.com/watch?feature=player_detailpage&v=li4Y0E_x8zE#t=1537