Re: Changing dependencies during the load process.
On Wed, 20 Aug 2014, John Barton wrote:
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.
Can you show me the markup for how you would like this to work? I'm not
sure I follow what your vision is here.
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.
That doesn't work; see the discussion in this e-mail:
https://mail.mozilla.org/pipermail/es-discuss/2014-August/038853.html
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.
Right. I'm trying to set up the groundwork to add such features to HTML.
I think you are imagining a magical trigger that does not exist.
That more or less summarises my job, yeah. :-)
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Changing dependencies during the load process.
On Wed, Aug 20, 2014 at 3:23 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 20 Aug 2014, John Barton wrote:
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.
Can you show me the markup for how you would like this to work? I'm not
sure I follow what your vision is here.
script
System.import('jquery').then(() = {
$(document).ready(() = {
$(img.a).hover(() = {
$(this).stop().animate({opacity: 0}, slow);
}, () = {
$(this).stop().animate({opacity: 1}, slow);
});
});
});
/script
Here the page depends upon a mouseover handler which depends upon jquery.
The handler and the page depend upon the image.
...
If you don't want multiple round trips, import from a bundle.
That doesn't work; see the discussion in this e-mail:
https://mail.mozilla.org/pipermail/es-discuss/2014-August/038853.html
So I answered on another thread.
jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Changing dependencies during the load process.
On Wed, 20 Aug 2014, John Barton wrote:
On Wed, Aug 20, 2014 at 3:23 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 20 Aug 2014, John Barton wrote:
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.
Can you show me the markup for how you would like this to work? I'm
not sure I follow what your vision is here.
script
System.import('jquery').then(() = {
$(document).ready(() = {
$(img.a).hover(() = {
$(this).stop().animate({opacity: 0}, slow);
}, () = {
$(this).stop().animate({opacity: 1}, slow);
});
});
});
/script
Here the page depends upon a mouseover handler which depends upon
jquery. The handler and the page depend upon the image.
This doesn't do what I was describing. I apologise for being unclear.
The idea is that the jQuery module in this world doesn't get loaded until
it is needed. When the user hovers over the image, then the jQuery module
is loaded and used, but until then, nothing needs jQuery so it's not
loaded. (Or replace jQuery with whatever it is that's special to this
image; the precise library doesn't matter.)
If you don't want multiple round trips, import from a bundle.
That doesn't work; see the discussion in this e-mail:
https://mail.mozilla.org/pipermail/es-discuss/2014-August/038853.html
So I answered on another thread.
Ah, looks like your e-mail got caught by my spam filters. I'll continue to
respond there.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Changing dependencies during the load process.
On Mon, 18 Aug 2014, John Barton wrote: 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. That's what I've been doing. My conclusion is that it's very similar, and just requires a few changes to the ES6 module loader design, those I've been describing. The alternative is that we end up with two very similar dependency systems which interact (because people want to have scripts depend on HTML features and vice versa). This does not seem like a win to me. But in the case of image tags we already know exactly which image the HTML depends upon. But other elements might depends on the img, and that we don't know. (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.) 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. 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. It seems really good to me, given the alternative. But I'll defer to the rest of the JS spec community to make that decision, since it requires changes to the ES6 spec if we're going to do it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Changing dependencies during the load process.
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?
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. Also, this doesn't wait until former is
needed before loading it.
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.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Changing dependencies during the load process.
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? 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. 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.) 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. // 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? How would you use System.import() to mark e.g. an image as dependent on a style sheet when scripting is disabled? 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? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Changing dependencies during the load process.
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
Re: Changing dependencies during the load process.
On Mon, Aug 18, 2014 at 5:32 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 18 Aug 2014, John Barton wrote:
...
But in the case of image tags we already know exactly which image the
HTML depends upon.
But other elements might depends on the img, and that we don't know.
(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.
The reverse case, where a img depends on a script, is not a use case.
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
Here we are expressing the dependency of the HTML file on the non-loaded
file './former' and it depends on the non-loaded file './loaded'.
jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
