> > > 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 [email protected] https://mail.mozilla.org/listinfo/es-discuss
