Integrating the Webs' dependency systems
johnjbarton at google.com
Tue May 27 16:41:39 PDT 2014
On Tue, May 27, 2014 at 3:57 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Tue, 27 May 2014, John Barton wrote:
> > I think the Loader nicely isolates these particular functions: I don't
> > see any urgency in standardizing them. However the delegation of the
> > specification of System leaves us in the weird place of having
> > everything except the actually external API spec-ed. Web folks could
> > almost just say "Browsers shall have a window.System instance of
> > Loader". There is a missing part of the Loader spec essential for Web
> > and not very important for node: bundling for network transmission see
> > https://github.com/systemjs/systemjs.
> I don't understand this paragraph. What does it mean for us to not
> standardise Loader's functions?
It means that browsers implement them within the constraints already
imposed the rest of the (large and quite specific) Loader specification,
common sense, and feedback from users. Among the many important things to
solve in the module space, specing these functions ranks very low. (BTW the
Loader also has poorly specified compiler hooks that need work, but that
clearly is TC39 business).
> Is System something that we are expecting
> some non-ES spec, e.g. Fetch or HTML, to define?
TC39 members have more than once explained that they expect some non-ES
spec to define System.
> > But to your original question about non-JS loading: you can extend the
> > Loader class to add methods for CSS and HTML. These would be a cache in
> > front of xhr for the most part, hence my suggestion that implementation
> > (GitHub) is a good place to start. The next step, and one quite critical
> > to practice, is integration with bundling. Here practical expertise is
> > essential so again implementation would be a critical guide. There exist
> > solutions in the pre-ES6 space to consult as well.
> This seems to imply that to do anything with this mechanism, someone (the
> page author?) has to provide some script code.
I believe that such an extension of the ES6 Loader has a chance to provide
value to the community. I guess it won't solve all problems ;-)
> However, it's very much my
> goal to be able to address use cases that don't involve any script at all
> (and that work even when the browser has scripting disabled), for example,
> I'd like whatever solution we develop here to be able to handle
> prioritising the loading and applying of different style sheets and
> images, e.g. so that images that are not currently rendered aren't
> downloaded yet, even though they are mentioned later in the page. One
> could imagine having markup like:
> <link href="foo.css" rel=stylesheet load-policy=on-demand
> <img src="foo.png" alt="..." load-policy=on-demand
> ...where an <img> element is defined as being needed when it's rendered,
> and where the browser would therefore only fetch the image and its
> stylesheet when the image is scrolled into view.
> This would need to work without any script involved at all, but should the
> author later add script with its own dependencies, we would want all the
> script dependency stuff to use the same underlying system so that if the
> script needs foo-styles or the foo.png image, it would all work as one
> coherent whole.
I think that developers with sufficient background to master load policies
and dependency graphs will also be able to master a small script to achieve
a similar result. On the other hand, experienced developers would like to
avoid these kinds of complex declarative solutions if possible, since they
are difficult to debug and understand.
HTML Imports offers a middle ground: while it is declarative it is also
modular so the complexity can be divided and conquered. I don't think it
requires script so it is an alternative starting point. My uninformed
concern with HTML Imports lies in the limitations it imposes in order to
enforce performance goals.
Overall I think we should experiment with the tools we almost have before
we try to couple them together or develop another overlapping alternative.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss