Integrating the Webs' dependency systems

Matthew Robb matthewwrobb at gmail.com
Tue May 27 15:12:16 PDT 2014


@Ian, It seems like the first real question is, based on what will
eventually be in the ES6 Spec for the Loader API, what is the System Loader
as it pertains to the web/browser environment and is there potentially a
need for a specification of it here (or at least outside of tc39).


- Matthew Robb


On Tue, May 27, 2014 at 3:04 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Fri, 23 May 2014, Garrett Smith wrote:
> >
> > And can we change "needs=" back to "depends="?
>
> I haven't gotten as far as figuring out what the API should look like, so
> it's probably too early to bikeshed specific attribute names. :-)
>
>
> > > The basic theme of <script needs=""> is making it possible for
> > > resources (probably more than just scripts) depend on each other and
> > > delay loads until they are needed. For example, being able to say
> > > "this script shouldn't download yet.
> >
> > Shouldn't download or shouldn't be evaluated?
>
> Both.
>
>
> > > When it is needed, though, it should also download and apply this
> > > style sheet,
> >
> > Stylesheets, too? :-)
>
> Anything, ideally.
>
>
> On Fri, 23 May 2014, Matthew Robb wrote:
> > On Fri, May 23, 2014 at 5:04 PM, Ian Hickson <ian at hixie.ch> wrote:
> > >
> > > 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.
> >
> > So my (albeit limited) understanding of ES6 Loader is that it is up to
> > the environment to create a relevant implementation. This has been
> > referred to as the System global loader. What I am proposing is that in
> > the browser, dependencies for things like modules, components,
> > templates, stylesheets, are all important for different reasons and in
> > each of those contexts.
> >
> > So the browser's System loader should have a method of loading any of
> > these common browser dependencies. The only thing left to decide is what
> > the exports of non-modules would be. For components it seems obvious by
> > default they would export their components by global name.
> >
> > document.register("x-foo", ...);
> > and
> > import { XFoo } from "path/to/component";
>
> Ah so the ES6 "import" statement can import anything, even things that
> aren't ES6 modules?
>
> It would certainly be cool if that was possible.
>
>
> > But you could go further and give components the ability to represent
> > modules in script explicitly. You might also want to export all linked
> > components from within a given component by default.
> >
> > <link rel="imports" href="x-foo-button.html"/>
> > <module>
> > import { XFooButton } from "x-foo-button.html";
> > </module>
> >
> > In the above case you would either implicitly or explicitly be able to do
> >
> > <module>
> > export XFooButton as "x-foo-button.html";
> > </module>
> >
> > I hope any of what I just typed is understandable, if not I will try to
> > put it in better words when I have more time.
>
> Well presumably we wouldn't want to require that people write script to
> add things to the dependency system, right? I mean, we presumably would
> want the markup to also do the "export" step implicitly.
>
>
> On Fri, 23 May 2014, Kevin Smith wrote:
> > >
> > > 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.)
> >
> > Do you think that, in principle, a resource of a given type should be
> > able to declaratively specify a dependency upon a resource of a
> > different type?
>
> I don't think this is a general principle, e.g. I don't think it makes
> much sense for us to extend the PNG spec to integrate with this.
>
> But there are certainly multiple parts of the platform that want to
> declare dependencies on and from different resource types.
>
>
> > So, for example, an ES module might hypothetically declare a dependency
> > upon a CSS stylesheet and vice versa?
>
> If that is something that ES wants to be able to declare, I would be happy
> for us to support it.
>
>
> > I think *the* critical attribute that such a dependency system must have
> > is a universal syntax and semantics for identifying resources, across
> > all resource types.  In other words, all resources must be identified by
> > URL/URI.
>
> I don't think a URL is the right way to identify everything. Many things
> in the Web platform that you could legitimately want to depend on don't
> have a URL. For example, a promise, or an inline <script> block, or an
> HTML <video> element (the latter in particular would have several URLs,
> the whole point would be to depend on the element so that things only
> happen once that element has figured out which file it wants to play and
> is ready to do so).
>
>
> On Tue, 27 May 2014, John Barton wrote:
> > On Fri, May 23, 2014 at 5:04 PM, Ian Hickson <ian at hixie.ch> wrote
> > >
> > > What/where would be the best place to define such a system,
> >
> > Github.
>
> I really meant which specification. As I see it we have four obvious
> places where we could concretely define the Web's dependency system:
>
>  - the ES spec
>  - the HTML spec
>  - the Fetch spec
>  - some new spec
>
> (HTML Imports will eventually become merged with the HTML spec, so I
> haven't listed that separately.)
>
> Putting it in ES would be fine by me (less work for me!). (I don't think
> it's a problem for HTML to depend on ES for something like this, even if
> not all browsers implement ES -- for example, the HTML spec already
> defines things in terms of the DOM and CSS specs, even for browsers that
> don't implement the DOM API or CSS. It just means the end-result should be
> as if the underlying spec was implemented, even if the rest of that
> underlying spec isn't implemented.)
>
> So, what should we do here? Do people agree that the model I described
> here is the model that covers everything we need here?:
>
>
> http://esdiscuss.org/topic/integrating-the-webs-dependency-systems#content-5
>
> What would be the best spec to put this in? How should we ensure that all
> the specs that are to use this actually do use this? What interfaces
> should we have between the specifications to do this?
>
>
> > > and how would we hook all the specs together to use it?
> >
> > Define a "System" object for ES6 that implements the ES6 Loader API and
> > extends it to dynamically load CSS and HTML.
>
> Can you elaborate on this? I don't really follow.
>
>
> On Tue, 27 May 2014, John Barton wrote:
> >
> > The most important problem to iron out with HTML Import + ES6 Loader is
> > the timing confusion. Both systems use a combination of asynchronous and
> > blocking-for-dependents loading.
>
> Right, that's why I think we should just have one processing model which
> both specs hook into. That way there'd only be one system using a
> combination of asynchronous and blocking-for-dependents loading.
>
>
> On Tue, 27 May 2014, Kris Kowal wrote:
> >
> > It would be lovely if HTML could be trained to resolve URL's through the
> > module system.
>
> By "HTML" here I presume you mean the underlying Fetch mechanism. Could
> you elaborate on exactly how this would work? Would this be in the layer
> before or after Service Workers?
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140527/a7b97bf4/attachment.html>


More information about the es-discuss mailing list