Integrating the Webs' dependency systems

John Barton johnjbarton at google.com
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 gmail.com> 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 mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140529/353a20d1/attachment.html>


More information about the es-discuss mailing list