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