domenic at domenicdenicola.com (2014-02-04T16:00:12.341Z)
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.
> 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