Integrating the Webs' dependency systems

Ian Hickson ian at
Fri May 23 17:04:24 PDT 2014

On Fri, 23 May 2014, Matthew Robb wrote:
> I think this is a great discussion and it would be cool if it could get 
> mirrored to the other working groups (specifically esdiscuss).

Assuming you mean this thread, it is. :-) (If you meant the HTML spec 
discussion regarding needs="" and company, that's more about HTML than 
scripting specifically, which is why it's happening on the WHATWG list.)

> It would be great if WebComponents used the Loader and thus you could 
> easily import a component into an es6 module and you could build a 
> component that is entirely an es6 module that simply exports it's 
> relevent bits. This would require something like <link rel="imports" 
> type="module"> but I almost.
> I'd love to be able to import css from an es6 module or import a 
> template etc.

Could you elaborate on what it would mean for a module to import a 
template or style sheet? I'm not super-familiar with ES6 modules yet so 
I'm not sure exactly how this would manifest syntactically.

Abstractly, as far as I can tell, we can imagine the superset of the 
dependency parts of ES6 modules, HTML imports, and HTML in general as 
described by a model where some central processor has a list of items, 
along with a mechanism for adding new items to the list, and each item:

 - has some means of identification so it can be deduped if it is added to 
   the list multiple times
 - has the ability to fetch its contents if not already available
 - has the ability to be executed or applied
 - has a list of other items that it depends on
 - has a list of promises that it must wait for before being applied
 - has a current state, probably one of: idle, downloading, waiting for 
   dependencies, ready, applying/executing, loaded, error
 - has some sort of execution policy, probably one of: block scripts until 
   run, run asap, run when needed (i.e. when its ability to be executed is 
   invoked); maybe some more esoteric policies like running only once 
   anything that depends on it is about to be run itself
 - has some sort of download policy, e.g.: download asap, download once 
   the "asap" things are downloaded, download only when needed, download 
   when needed but can be precached if there is free available bandwidth.

So for example, a style sheet imported by <link> today would be identified 
by its URL, fetching its contents would use the "Fetch" specification 
(e.g. fetching over HTTP), applying it would mean adding it to the style 
sheet set of the current Document, it wouldn't depend on anything 
initially but if any @imports were found while it was being parsed then 
those would probably be dependencies, and it would have the policies of 
"run asap" and "download asap". (Once we have this model in place, it 
might make sense to add a feature to HTML to control these policies for 
each resource in the list; e.g., for <link rel=stylesheet>, an attribute.)

Similarly, an ES6 module would presumably map to this as follows: the 
identifier would be the module name, the ability to fetch the contents 
would be defined by the Loader (if I understand the spec right), what it 
depends on would be based on the "import" statements, and it would 
presumably have the policies of "run asap" and "download asap".

A <script src defer> element found during parsing could, in this model, be 
described as an item that is waiting for the promise that describes the 
Document being parsed, and it would probably have the policies of "run 
asap" and "download once the 'asap' things are downloaded".

One could also imagine having <img whenneeded ...>, an image that would be 
represented in this system as an item identified by the HTMLImageElement 
object, which can be told to download via some method e.g. img.fetch(), 
and whose policies would be "run when needed", "download when needed but 
can be precached".

A script could then tell the system to add this <img> element / 
HTMLImageElement object as one of the dependencies for a script it was 
injecting, so that that script doesn't run until the image is downloaded. 
(Doing this, assuming the script is then told to run immediately, would be 
another way of telling the image it was needed. That's one reason to have 
the dependency system be abstract like this: it lets different parts of 
the platform participate by just exposing a generic interface, so that Web 
authors think we designed this all as one coherent whole.)

Does all that make sense? Did I miss some feature or behaviour that ES6 
modules have that can't be described in the above?

What/where would be the best place to define such a system, and how would 
we hook all the specs together to use it?

Ian Hickson               U+1047E                )\._.,--....,'``.    fL       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

More information about the es-discuss mailing list