On Mon, Aug 18, 2014 at 2:00 PM, Ian Hickson <i...@hixie.ch> wrote:
> On Mon, 18 Aug 2014, John Barton wrote:
> > On Mon, Aug 18, 2014 at 10:43 AM, Ian Hickson <i...@hixie.ch> wrote:
> > > On Fri, 15 Aug 2014, John Barton wrote:
> > > > On Fri, Aug 15, 2014 at 3:41 PM, Ian Hickson <i...@hixie.ch> wrote:
> > > > > On Fri, 15 Aug 2014, John Barton wrote:
> > > > > >
> > > > > > The ES Loader does not maintain a dependency tree. It maintains
> > > > > > a table of names->modules.
> > > > >
> > > > > Maybe I'm misunderstanding the ES6 loader spec. What's the Load
> > > > > Record [[Dependencies]] list?
> > > >
> > > > The dependencies for the Load. Once the load is complete the record
> > > > is not needed.
> > >
> > > How about if the dependencies are changed during the load? For
> > > example:
> > >
> > > <script id=a src="a.js" load-policy=when-needed></script>
> >
> > This seems like an unfortunate design choice....
>
> Can you elaborate? What would a better design be?
The current System.import + Loader mechanism.
> I'm certainly not
> married to this approach. Fundamentally, though, if the problem is how to
> mark HTML elements as "load on demand" with a dependency tree, I don't see
> many options beyond putting things in HTML attributes or elements. (I use
> scripts in the example above, but the problem applies equally to images or
> other non-script features, and the use cases for them apply even with
> scripting disabled.
The problems are not equal but rather have significant unique aspects.
> For example, marking images as "load on demand" so
> that they don't load until the user scrolls down, with some images needing
> particular style sheets that are also to not load until you scroll down to
> the relevant image.)
>
Why should I have to mark images? The page should load the images needed
for the visible area. (But I'm unsure if this is even technically feasible
since images below the fold could affect layout above the fold).
>
>
> > > <script id=b src="b.js" load-policy=when-needed></script>
> > > <script id=c needs="a"> ... </script>
> > > <script>
> > > // at this point, the script with id=c is blocked waiting for a.js
> to
> > > // load. Let's change its dependencies:
> > > document.scripts.c.needs = 'b';
> >
> > ...which leads to exotic quirks like this.
>
> Well, the DOM is mutable. If we hook something into the DOM, we have to
> define what happens when it mutates.
>
There is no reason to make this case work great. It's much more important
to make the simple cases work well.
>
> > > // now the script needs to trigger b.js to load
> > > // a.js' load can be deprioritised (or canceled, if network is at a
> > > // premium), and no longer blocks the script from loading
> > > </script>
> >
> > System.import already supports dynamic loading with runtime dependency
> > selection. If you have a problem with it let's discuss that before
> > redesigning it.
>
> I'm not sure I follow. Can you elaborate?
Your examples use script. I just don't think now that we should use the
same solution for HTML. We should analyze the HTML requirements and design
a solution. If the result is similar to script then we can reuse.
If we do want to follow the pattern of the script loader, we would extract
'static' dependencies by parsing and use script for dynamic dependencies.
We would not mix them.
In parsing for static dependencies we need not start from the assumption of
extra declarations. These extra declarations added to ES6 are really about
convenient abbreviations. For example,
import {Foo} from 'src/baz/Foo';
var foo = new Foo();
is just a much nicer syntax than
var foo = new {src/baz/Foo}.Foo(); // illegal
or whatever. But in the case of image tags we already know exactly which
image the HTML depends upon. All we have to do is not load it until we need
it to render the page. (Again I'm assuming a magical solution to the
rendering part, which is needed in any dependency loading solution).
> How would you use
> System.import() to mark e.g. an image as dependent on a style sheet when
> scripting is disabled?
Once we understand how these dependencies arise we can look for ways to
extract the dependency information and determine whether explicit
dependency declaration is needed.
> Or indeed even when scripting is enabled, how would
> you use it to mark one non-loaded script as dependent on another
> non-loaded script such that when you later ask for the former, the latter
> loads automatically?
>
import './latter';
It's a solved problem for scripts.
If you ask about images, then you will have to explain what it means for an
image to be dependent upon an image. Surely there are legitimate non-script
dependencies but we can't just treat everything like script and vice versa.
Discussing HTML dependency loading and ES dependency loading together makes
a lot of sense -- up to a point. But requiring specs and implementations to
converge does not seem good to me now.
jjb
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
