Integrating the Webs' dependency systems

Kevin Smith zenparsing at
Wed May 28 21:06:43 PDT 2014

> Ok. I'm not really sure how to extend the ES6 module system in a way that
> won't stomp on this working group. How do I (at the spec level) tell the
> ES6 module system that it should not evaluate a particular module until
> some non-script resource, e.g. a style sheet, is available? It seems like
> it needs a closer integration with load records than the APIs would
> enable. For example, would we be able to hook the CSS @import loading
> mechanism into load records? How about marking a load as low-priority, is
> that something we can do with load records?

So, what we currently have is ES6 defining a dependency loading framework
and a requirement that the host environment satisfy the contract
represented by that framework.

An alternative might be to assume that host environment defines a loading
framework available through some global, promise-returning primatives, and
defining ES module loading in terms of those primatives.  I think this
would entail moving much of the loader pipeline into HTML, and allowing the
ES spec to focus specifically on linkage.

My intuition says that this would be a better overall design, since it
would bring all resource loading concerns under a common subsystem using a
common resource model.

Are you thinking along these same general lines?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list