detecting JS language mode for tools

Brendan Eich brendan at mozilla.com
Mon Jan 27 12:55:25 PST 2014


> David Herman <mailto:dherman at mozilla.com>
> January 27, 2014 at 12:03 PM
>
> OK, sorry I jumped in the middle of things missing some context. In 
> fact, I think what we've been planning on proposing is not too far -- 
> I think -- from what you're talking about. The plan is *not* a module 
> attribute (that was a think-o on my part, and maybe some 
> misinformation that crept into this discussion earlier?) but 
> type="module". That way on old browsers it's ignored and you can add 
> shims to load it. Shims can be made future-proof via feature 
> detection, so type="module" can obtain new semantics.

The shims word suggests that old-browser-targeted script must DOM-scrape 
the script type=module text and interpret it with Esprima or similar. 
This may not perform well enough compared to an AOT compiler, which is 
another option. Just weighing these.

> Moreover, the type="module" should not actually mean "execute right 
> now and block everything else," but rather "executing asynchronously 
> once all my module dependencies are loaded and linked."

The detail I mentioned 1:1 of type= requiring IANA media types suggests 
something other than "module". Detail? Not to standardistas (Hi, Bjoern!).

Whatever the bootstrap inline script compatibility story, I agree having 
an inline bootstrap module-script is desirable.

/be
> Does that make more sense? I realize part of the issue here is there 
> isn't a concrete plan or proposal that's been spelled out, it's just 
> been informal discussions. That's on us, the modules champions, to put 
> forward a proposal for web (i.e. non-Ecma) standardization ASAP. 
> Yehuda's going to be in town for TC39 this week, so he and I will sit 
> down and do an informal write-up so people can see the plan more 
> clearly, while we work on a fuller proposal for standardization.
>
> Dave
>
>
> David Bruant <mailto:bruant.d at gmail.com>
> January 27, 2014 at 10:58 AM
> Le 27/01/2014 19:41, David Herman a écrit :
>> On Jan 27, 2014, at 2:07 AM, David Bruant <bruant.d at gmail.com> wrote:
>>
>>> Indeed. I'm wondering why we need inline <script> for modules.
>> Because people write inline scripts all the time. It's unacceptably 
>> inconvenient not to be able to bootstrap your app with inline code. 
>> It also allows you to control for when the scripts resource is there, 
>> in particular to be sure that necessary bootstrapping/kernel code has 
>> loaded before you need to do some wiring up of your app.
> Agreed. Note that I didn't suggest to stop writing inline scripts and 
> proposed an alternative to script at module that can work today.
> Granted, it's somewhat hacky, but I think it can work during the 
> period during which there'll be both ES6 and non-ES6 browsers to support.
>
> I was sloppy in my phrasing. What we don't need is the current inline 
> script "execute right now and block everything else" semantics, 
> specifically for modules which order of execution shouldn't block things.
>
>> But it's not even worth overthinking. It's so obviously, obscenely 
>> anti-usable not to be able to write
>>
>> <script module>
>>      import $ from "jquery";
>>      import go from "myapp";
>>      $(go);
>> </script>
>>
>> inline that I'm surprised this is even a discussion.
> If the snippet is only targetting ES6 browser, it can work without the 
> module attribute (I think?). This snippet doesn't work on non-ES6 
> browsers, though.
>
> I feel two different problems are being discussed in this thread? One 
> about inline modules, one about compatibility, (both a bit away from 
> the original topic ;-)). I was on the compatibility track.
>
> David
>
> David Herman <mailto:dherman at mozilla.com>
> January 27, 2014 at 10:41 AM
>
> Because people write inline scripts all the time. It's unacceptably 
> inconvenient not to be able to bootstrap your app with inline code. It 
> also allows you to control for when the scripts resource is there, in 
> particular to be sure that necessary bootstrapping/kernel code has 
> loaded before you need to do some wiring up of your app.
>
> But it's not even worth overthinking. It's so obviously, obscenely 
> anti-usable not to be able to write
>
> <script module>
> import $ from "jquery";
> import go from "myapp";
> $(go);
> </script>
>
> inline that I'm surprised this is even a discussion.
>
> Dave
>
>
> David Bruant <mailto:bruant.d at gmail.com>
> January 27, 2014 at 2:07 AM
> 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 
>
>
> Brendan Eich <mailto:brendan at mozilla.com>
> January 26, 2014 at 9:45 PM
>
>
> One can write strict code that runs fine in old browsers!
>
> Why do we want inline module-bodied elements in HTML? That's the topic 
> here. There is no issue for out-of-line module-bodied elements, 
> AFAICT. Once you focus on inline bodies, you face harsh adoption 
> barriers without enabling works-in-old-and-new coding.
>
> /be


More information about the es-discuss mailing list