On Tue, Aug 19, 2014 at 4:25 PM, Ian Hickson <i...@hixie.ch> wrote:
> On Mon, 18 Aug 2014, John Barton wrote:
> > >
> > > (For example, a graphical game might need some sprite assets to be
> > > loaded before it can start up. So its <script> might be marked as
> > > depending on an <img> element that loads that image. Or the script
> > > contents might have an import statement that refers to that image.)
> >
> > Supporting this case seems straight-forward and can be done entirely by
> > the browser Loader implementation using hooks.
>
> That is my hope, yes.
>
>
> > The reverse case, where a img depends on a script, is not a use case.
>
> Why not? What if the image has an onmouseover handler that calls an API
> function defined in a module, for instance?
>
Then the page depends on the onmouseover handler code and it has a
dependency on the module. Images are leaf nodes in the dependency tree.
>
> > > > > 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.
> > >
> > > The key part of my question was "non-loaded". The "import" bit is in
> > > the script. The script isn't loaded yet, so we can't rely on it.
> >
> > <script>
> > System.import('./former').then((former) => {
> > // do stuff with former, knowing './former' imported './latter'.
> > });
> > </script>
>
> This results in multiple RTTs.
If you don't want multiple round trips, import from a "bundle". Then the
first fetch gets all of the modules needed by ./former.
Also, this doesn't wait until former is
> needed before loading it.
>
But the mechanisms for knowing "need" are not available to any one at this
point. The problem is we don't know when to trigger the load, not what is
in the load.
I think you are imagining a magical trigger that does not exist. This
magical trigger would know "we are moving below the fold now". If we had
that trigger we could delay the load of all of the modules below the fold.
But we don't have that trigger, so there is no reason to delay sending all
of the modules for the page.
This is a critical issue. Excluding JS what means do we have for expressing
"needed"? As far as I know the list is ["Parsed"]. That is, if the resource
is needed by the page we know that when the page is parsed. When we parse
a tag that specifies a resource load, we can block or not, but we have to
load it because there is no other future trigger to cause the load at
another time. If we had such a trigger then we could make use of it to
improve loading.
There are JS events that we can handle to control loading. JS can load a
bundle of modules given the root request. We might be able to express some
of these declaratively and that might lead to new requirements on the JS
Loader. This approach gives us the context we need to judge tradeoffs. But
we are a long way from such need at this point: we don't have the triggers
nor a standard for bundling.
>
> > Here we are expressing the dependency of the HTML file on the non-loaded
> > file './former' and it depends on the non-loaded file './latter'.
>
> But you don't know that it depends on ./latter until you've fetched
> ./former, by which time it's too late.
>
Maybe I mis-interpreted your scenario. Sounds like you want 'bundle' or
package loading. That subject should be part of the ES spec in my opinion
but so far we can only do ad-hoc implementations. I'm unsure why you seem
to be against this solution to your use case.
jjb
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
