Le 27/01/2014 19:41, David Herman a écrit :
On Jan 27, 2014, at 2:07 AM, David Bruant <bruan...@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@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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
