Integrating the Webs' dependency systems
ian at hixie.ch
Fri May 23 17:04:24 PDT 2014
On Fri, 23 May 2014, Matthew Robb wrote:
> I think this is a great discussion and it would be cool if it could get
> mirrored to the other working groups (specifically esdiscuss).
Assuming you mean this thread, it is. :-) (If you meant the HTML spec
discussion regarding needs="" and company, that's more about HTML than
scripting specifically, which is why it's happening on the WHATWG list.)
> It would be great if WebComponents used the Loader and thus you could
> easily import a component into an es6 module and you could build a
> component that is entirely an es6 module that simply exports it's
> relevent bits. This would require something like <link rel="imports"
> type="module"> but I almost.
> I'd love to be able to import css from an es6 module or import a
> template etc.
Could you elaborate on what it would mean for a module to import a
template or style sheet? I'm not super-familiar with ES6 modules yet so
I'm not sure exactly how this would manifest syntactically.
Abstractly, as far as I can tell, we can imagine the superset of the
dependency parts of ES6 modules, HTML imports, and HTML in general as
described by a model where some central processor has a list of items,
along with a mechanism for adding new items to the list, and each item:
- has some means of identification so it can be deduped if it is added to
the list multiple times
- has the ability to fetch its contents if not already available
- has the ability to be executed or applied
- has a list of other items that it depends on
- has a list of promises that it must wait for before being applied
- has a current state, probably one of: idle, downloading, waiting for
dependencies, ready, applying/executing, loaded, error
- has some sort of execution policy, probably one of: block scripts until
run, run asap, run when needed (i.e. when its ability to be executed is
invoked); maybe some more esoteric policies like running only once
anything that depends on it is about to be run itself
- has some sort of download policy, e.g.: download asap, download once
the "asap" things are downloaded, download only when needed, download
when needed but can be precached if there is free available bandwidth.
So for example, a style sheet imported by <link> today would be identified
by its URL, fetching its contents would use the "Fetch" specification
(e.g. fetching over HTTP), applying it would mean adding it to the style
sheet set of the current Document, it wouldn't depend on anything
initially but if any @imports were found while it was being parsed then
those would probably be dependencies, and it would have the policies of
"run asap" and "download asap". (Once we have this model in place, it
might make sense to add a feature to HTML to control these policies for
each resource in the list; e.g., for <link rel=stylesheet>, an attribute.)
Similarly, an ES6 module would presumably map to this as follows: the
identifier would be the module name, the ability to fetch the contents
would be defined by the Loader (if I understand the spec right), what it
depends on would be based on the "import" statements, and it would
presumably have the policies of "run asap" and "download asap".
A <script src defer> element found during parsing could, in this model, be
described as an item that is waiting for the promise that describes the
Document being parsed, and it would probably have the policies of "run
asap" and "download once the 'asap' things are downloaded".
One could also imagine having <img whenneeded ...>, an image that would be
represented in this system as an item identified by the HTMLImageElement
object, which can be told to download via some method e.g. img.fetch(),
and whose policies would be "run when needed", "download when needed but
can be precached".
A script could then tell the system to add this <img> element /
HTMLImageElement object as one of the dependencies for a script it was
injecting, so that that script doesn't run until the image is downloaded.
(Doing this, assuming the script is then told to run immediately, would be
another way of telling the image it was needed. That's one reason to have
the dependency system be abstract like this: it lets different parts of
the platform participate by just exposing a generic interface, so that Web
authors think we designed this all as one coherent whole.)
Does all that make sense? Did I miss some feature or behaviour that ES6
modules have that can't be described in the above?
What/where would be the best place to define such a system, and how would
we hook all the specs together to use it?
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the es-discuss