Integrating the Webs' dependency systems

John Barton johnjbarton at
Thu May 29 07:40:31 PDT 2014

My intuition is that any such plan would be vigorously opposed by the JS
community. Or perhaps vigorously ignored: browsers are falling behind
current technology and are no longer in a position to dictate what JS means.

On Wed, May 28, 2014 at 9:06 PM, Kevin Smith <zenparsing at> wrote:

>> 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?
> Kevin
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list