25715 2014-05-14 18:00:41 +0000 [imports]: Unify loading and dependency resolution model with ES6 modules 2015-07-06 08:18:13 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC All RESOLVED MOVED P2 normal --- 17842 20683 25378 25943 26546 1 dglazkov dglazkov dherman eoconnor erik.arvidsson ggaren gkrizsanits ian jdopazo mike public-webapps rniwa public-webapps-bugzilla oldest_to_newest 105982 0 dglazkov 2014-05-14 18:00:41 +0000 105989 1 dglazkov 2014-05-14 19:06:14 +0000 Will start digging into https://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-loader-state. It's nice and dense. Any help/guidance would be appreciated :) 106679 2 ian 2014-05-22 22:22:19 +0000 We should deal with this sooner rather than later because I'm about to add my own dependency system to HTML for <script needs> and so on. I _really_ don't want us to end up with three separate systems... 106682 3 ian 2014-05-22 22:57:38 +0000 I think what might make the most sense is for HTML to define the dependency fetching system, including things like delaying loads until something needs the dependency, precaching, deferring, etc, whether loads should block other scripts from executing, whether to early-execute or late-execute when there's a dependency chain, etc, and for the JS module system to just have hooks that HTML bootstraps into this system. (We're going to need to have hooks anyway for actually fetching things over HTTP.) In the case of modules in particular, having all this would allow us to hook modules into the dependency tree before actually fetching any files, so that they could be lazily loaded without requiring multiple round-trips to fetch all the dependencies once they _are_ needed. 111447 4 ian 2014-09-12 17:37:36 +0000 Reassigning to dglazkov since he's organising a summit or something for this. 121761 5 hayato 2015-07-06 08:18:13 +0000 Moved to https://github.com/w3c/webcomponents/issues/188