Re: [whatwg] Preloading and deferred loading of scripts and other resources
On Tue, Oct 7, 2014 at 6:50 PM, Ilya Grigorik wrote: > On Thu, Sep 11, 2014 at 7:55 PM, Ryosuke Niwa wrote: > > > On Sep 8, 2014, at 10:54 PM, Ilya Grigorik wrote: > > > > > On Mon, Sep 8, 2014 at 7:59 PM, Ian Hickson wrote: > > > > > >>> The platform is missing a lower-level primitive (declarative and > > >>> imperative) that is able to explain resource loading with the same > > >>> expressive power as requests initiated by the browser itself. > > >> > > >> That isn't a problem. > > > > > > I don't follow. To me that *is* the core problem that we should solve > > first > > > and ship as soon as possible: if we keep the surface area low, we can > > ship > > > it quickly and let developers experiment and move the platform forward. > > > Adding more layers of higher-level APIs only slows the deployment > > process. > > > > What problem(s) are those developers going to solve with such a low level > > API > > other than the use cases A through Z listed here? > Responding to Ryosuke (I wasn't on the list then), a low level API is exactly what's missing. IMO, the idea that browsers should provide convenient, high-level, spot solutions to some common problems is flawed. Instead, the browser should expose the lowest-level, most-capable APIs and let libraries sort out the convenience and common idioms. It's less work for browser vendors and empowers library authors and the developer community. I want to be able to fill a page with a thousand img tags and specify that they download in order of distance from the viewport. I want to be able to set priorities of XMLHttpRequests. I want to be able to set XHR priorities relative to image loads (that actually came up _today_ in profiling our application). I want to be able to deprioritize arbitrary resources after first paint. I want to adjust priorities as the application is being used. In short, I agree 100% with Ilya: Instead of hypothesizing about use cases, the web is better-served by exposing the primitive features of the web platform, which lets library authors and web developers decide for themselves how to take advantage of them. Cheers, Chad -- Chad Austin Technical Director, IMVU http://chadaustin.me
Re: [whatwg] Preloading and deferred loading of scripts and other resources
On Thu, Sep 11, 2014 at 7:55 PM, Ryosuke Niwa wrote: > On Sep 8, 2014, at 10:54 PM, Ilya Grigorik wrote: > > > On Mon, Sep 8, 2014 at 7:59 PM, Ian Hickson wrote: > > > >>> The platform is missing a lower-level primitive (declarative and > >>> imperative) that is able to explain resource loading with the same > >>> expressive power as requests initiated by the browser itself. > >> > >> That isn't a problem. > > > > I don't follow. To me that *is* the core problem that we should solve > first > > and ship as soon as possible: if we keep the surface area low, we can > ship > > it quickly and let developers experiment and move the platform forward. > > Adding more layers of higher-level APIs only slows the deployment > process. > > What problem(s) are those developers going to solve with such a low level > API > other than the use cases A through Z listed here? For one, its restricted to
Re: [whatwg] Preloading and deferred loading of scripts and other resources
On 8/23/14, Kyle Simpson wrote: >> Surely our goal should be to make script loaders unnecessary. > Complexity is best avoided, sure. > There's unquestionably a lot of folks on this thread for whom that is their > main concern. I think it's a mistake to assume that because they mostly seem > to be working as browser developers (which strongly influences their > perspective, I believe) that this is a universal goal. > OK. > 1. A "hand-authorable markup only" (aka "zero script loaders") approach is, > and always will be, limited. Limited to what? To the initial page load. > I'm not really interested in arguing the validity of that premise that one way or the other. > 2. There is, intuitively, some threshold of complexity of markup beyond > which most hand-authors will not go. > Lets not make the advertisement against the `needs` attribute proposal. And to be fair, that is really my 2009 "depends" Chain of Responsibility proposal, renamed. > They may author: > >
Re: [whatwg] Preloading and deferred loading of scripts and other resources
Different aspects of priority are expressed in some of Ian’s loadpolicy attributes (block, async, optimistic, low-priority). Currently web browsers use the type of loadable element to determine priority. In Ilya’s proposal this can be found in the “as” attribute in the case of LINK rel=preload. While it’s not ideal, this approach at least allows us to get agreement on preload without having to get agreement on a new comprehensive spec on request prioritization. I’m just agreeing that the current preload spec seems like a good first step and we should go ahead with it once issues are resolved if we can get agreement from implementors. Thanks, Peter On Sep 13, 2014, at 2:02 PM, Ryosuke Niwa wrote: > > On Sep 8, 2014, at 1:33 PM, Ian Hickson wrote: > >> >> I got some feedback on my last e-mail to the effect that having the >> proposal sandwiched between the rationale and the examples of how it would >> be used made it hard to find, so I'm reproducing the proposal here >> (slightly updated based on feedback): >> >> --- >> These "loadable" elements: >> >>
Re: [whatwg] Preloading and deferred loading of scripts and other resources
On Sep 8, 2014, at 1:33 PM, Ian Hickson wrote: > > I got some feedback on my last e-mail to the effect that having the > proposal sandwiched between the rationale and the examples of how it would > be used made it hard to find, so I'm reproducing the proposal here > (slightly updated based on feedback): > > --- > These "loadable" elements: > >
Re: [whatwg] Preloading and deferred loading of scripts and other resources
On Sep 8, 2014, at 10:54 PM, Ilya Grigorik wrote:
> On Mon, Sep 8, 2014 at 7:59 PM, Ian Hickson wrote:
>
>>> The platform is missing a lower-level primitive (declarative and
>>> imperative) that is able to explain resource loading with the same
>>> expressive power as requests initiated by the browser itself.
>>
>> That isn't a problem.
>>
>
> I don't follow. To me that *is* the core problem that we should solve first
> and ship as soon as possible: if we keep the surface area low, we can ship
> it quickly and let developers experiment and move the platform forward.
> Adding more layers of higher-level APIs only slows the deployment process.
What problem(s) are those developers going to solve with such a low level API
other than the use cases A through Z listed here?
> To be clear, I'm not against the core premise of unifying various import
> mechanisms, but to me that's a secondary goal -- good housekeeping, but not
> the problem that the actual web developers (not implementers) are actually
> up against today. And, at least personally, I think we should prioritize
> developer needs over implementers. That said, I don't think we're actually
> that far apart…
What are problems Web developers actually up against today?
Not having a low-level network API, on its own, isn’t a problem.
Please give us a concrete real world use case for which the proposed API
doesn’t work.
>>> and it also hides requests from the preload scanner, which is a
>>> deal-break for performance.
>>
>> That's why the proposal in this thread uses the existing import mechanisms
>> to define how the dependencies.
>>
>
> But restricts it to a subset of resource types. Granted, this is not an
> issue if you give me a generic way to load any resource, ala rel=preload.
Right.
>>> (2) We also need a declarative, content-type agnostic primitive to
>>> express resource loads, such that the preload scanner is able to pickup
>>> and processes these fetches on par with all other resources -- hence my
>>> rel=preload suggestion.
>>
>> I don't disagree that we need a way to declarative way to import
>> non-browser-native resources (like some text file the script uses for
>> storing game level data or something). But I don't think we need a
>> redundant mechanism to import resource types that already have existing
>> import mechanisms. That's not a "primitive", it's just a redundant
>> mechanism.
>>
>> I went into more detail on this very topic, considering a wide array of
>> options, in the big e-mail I sent recently:
>>
>>
>> http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Aug/0177.html
>
> It's only redundant insofar as XHR is a redundant mechanism for loading
> arbitrary resources. There are cases where fetching an image / stylesheet /
> etc, via XHR is both a reasonable and a required step -
> {pre,post}processing, and so on. Moving forward, I think the intent is to
> explain resource loading via Fetch. I'm asking for a declarative Fetch
> that's preloader friendly and has the same expressive capabilities.
I think rel=preload gives us a declarative preloader friendly syntax for Fetch.
>>> Note that I'm looking for declarative syntax that allows me to set
>>> arbitrary fetch priorities - e.g. upgrade my JSON payload to high
>>> priority because I need it to render content on the screen. This is the
>>> part that we *need* to solve.
>>
>> rel=preload with the proposal on this thread handles this fine, as far as
>> I can tell.
>>
>
> Yes, I think it's close! A few considerations to account for in the
> processing model, based on real-world use cases and feedback from the
> webperf group:
> - https://igrigorik.github.io/resource-hints/#preload
> - *https://igrigorik.github.io/resource-hints/#processing
> *
>
> All I'm arguing for here is that the MVP for giving web developers the
> power to start solving these problems is rel=preload. Everything else is a
> nice to have. As a result, I'd love to uncouple rel=preload from the
> rest... Once/if the other mechanisms are ready, rel=preload would just
> inherit them as part of coverage of . As I said earlier, I don't
> think we're that far apart.
Which values of loadpolicy content attribute are you proposing to support?
- R. Niwa
Re: [whatwg] Preloading and deferred loading of scripts and other resources
On Mon, Sep 8, 2014 at 7:59 PM, Ian Hickson wrote:
> > The platform is missing a lower-level primitive (declarative and
> > imperative) that is able to explain resource loading with the same
> > expressive power as requests initiated by the browser itself.
>
> That isn't a problem.
>
I don't follow. To me that *is* the core problem that we should solve first
and ship as soon as possible: if we keep the surface area low, we can ship
it quickly and let developers experiment and move the platform forward.
Adding more layers of higher-level APIs only slows the deployment process.
To be clear, I'm not against the core premise of unifying various import
mechanisms, but to me that's a secondary goal -- good housekeeping, but not
the problem that the actual web developers (not implementers) are actually
up against today. And, at least personally, I think we should prioritize
developer needs over implementers. That said, I don't think we're actually
that far apart...
> > XHR provides arbitrary resource loading, but it lacks the power to
> > express transport-layer options such as relative request priority
>
> That is fixed by exposing Request initialisation flags on XHR.
>
I've seen discussions about exposing this on Fetch, but not XHR. Granted,
one is not far from the other.
> > and dependencies,
>
> That's fixed by using the proposal in this thread.
>
We're talking about different "dependencies". I mean transport-layer
dependencies - i.e. if possible, ship bytes for resource A before bytes for
resource B. Again though, if we can express priorities, we should be able
to express (transport) dependencies via the same mechanism, so this is not
a big deal.
> > and it also hides requests from the preload scanner, which is a
> > deal-break for performance.
>
> That's why the proposal in this thread uses the existing import mechanisms
> to define how the dependencies.
>
But restricts it to a subset of resource types. Granted, this is not an
issue if you give me a generic way to load any resource, ala rel=preload.
> > (2) We also need a declarative, content-type agnostic primitive to
> > express resource loads, such that the preload scanner is able to pickup
> > and processes these fetches on par with all other resources -- hence my
> > rel=preload suggestion.
>
> I don't disagree that we need a way to declarative way to import
> non-browser-native resources (like some text file the script uses for
> storing game level data or something). But I don't think we need a
> redundant mechanism to import resource types that already have existing
> import mechanisms. That's not a "primitive", it's just a redundant
> mechanism.
>
> I went into more detail on this very topic, considering a wide array of
> options, in the big e-mail I sent recently:
>
>
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Aug/0177.html
It's only redundant insofar as XHR is a redundant mechanism for loading
arbitrary resources. There are cases where fetching an image / stylesheet /
etc, via XHR is both a reasonable and a required step -
{pre,post}processing, and so on. Moving forward, I think the intent is to
explain resource loading via Fetch. I'm asking for a declarative Fetch
that's preloader friendly and has the same expressive capabilities.
> > We can augment img, script, and other elements, with load-settings and
> > other flags, but that still doesn't cover all the necessary cases. For
> > example, how do I fetch a font file
>
>http://dev.w3.org/csswg/css-font-loading/
>
> ...which presumably would have loadSettings exposed.
>
Sadly, even that requires executing JavaScript and fails the preloader use
case.
> > or an arbitrary JSON payload with app-data, etc?
>
> XHR, or . I assume you're not expecting us to preparse
> the JSON file.
>
Right, no execution. Just fetch and nothing else: start the request, stick
into the appropriate cache(s) if applicable, and keep the payload inert.
> > Note that I'm looking for declarative syntax that allows me to set
> > arbitrary fetch priorities - e.g. upgrade my JSON payload to high
> > priority because I need it to render content on the screen. This is the
> > part that we *need* to solve.
>
> rel=preload with the proposal on this thread handles this fine, as far as
> I can tell.
>
Yes, I think it's close! A few considerations to account for in the
processing model, based on real-world use cases and feedback from the
webperf group:
- https://igrigorik.github.io/resource-hints/#preload
- *https://igrigorik.github.io/resource-hints/#processing
*
All I'm arguing for here is that the MVP for giving web developers the
power to start solving these problems is rel=preload. Everything else is a
nice to have. As a result, I'd love to uncouple rel=preload from the
rest... Once/if the other mechanisms are ready, rel=preload would just
inherit them as part of coverage of . As I said earlier, I don't
think we're that far ap
Re: [whatwg] Preloading and deferred loading of scripts and other resources
On Mon, 8 Sep 2014, Ilya Grigorik wrote: > > Better or worse is not the point. I think the current proposal fails to > address the larger underlying problem. If it did, then that would be "worse". > The platform is missing a lower-level primitive (declarative and > imperative) that is able to explain resource loading with the same > expressive power as requests initiated by the browser itself. That isn't a problem. > XHR provides arbitrary resource loading, but it lacks the power to > express transport-layer options such as relative request priority That is fixed by exposing Request initialisation flags on XHR. > and dependencies, That's fixed by using the proposal in this thread. > and it also hides requests from the preload scanner, which is a > deal-break for performance. That's why the proposal in this thread uses the existing import mechanisms to define how the dependencies. > (2) We also need a declarative, content-type agnostic primitive to > express resource loads, such that the preload scanner is able to pickup > and processes these fetches on par with all other resources -- hence my > rel=preload suggestion. I don't disagree that we need a way to declarative way to import non-browser-native resources (like some text file the script uses for storing game level data or something). But I don't think we need a redundant mechanism to import resource types that already have existing import mechanisms. That's not a "primitive", it's just a redundant mechanism. I went into more detail on this very topic, considering a wide array of options, in the big e-mail I sent recently: http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Aug/0177.html > We can augment img, script, and other elements, with load-settings and > other flags, but that still doesn't cover all the necessary cases. For > example, how do I fetch a font file http://dev.w3.org/csswg/css-font-loading/ ...which presumably would have loadSettings exposed. > or an arbitrary JSON payload with app-data, etc? XHR, or . I assume you're not expecting us to preparse the JSON file. > Note that I'm looking for declarative syntax that allows me to set > arbitrary fetch priorities - e.g. upgrade my JSON payload to high > priority because I need it to render content on the screen. This is the > part that we *need* to solve. rel=preload with the proposal on this thread handles this fine, as far as I can tell. > Once we have the low-level declarative+imperative primitives for loading > resources, we can build up all other loading and dependency patterns in > app-space. That people have to build them in app space is the bug I'm trying to fix here. > The loadpolicy/needs attributes are syntax sugar for select resource > types -- nice, but (IMO) not strictly necessary and not sufficient for > the more general case of content-types not covered by dedicated > elements. needs="" is actually very little more than syntactic sugar over ES6 module loader primitives, assuming that we can get the ES6 module loader to be augmented to address the needs of non-ES resources: http://esdiscuss.org/topic/es6-loader-proposed-changes -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Preloading and deferred loading of scripts and other resources
On Mon, Sep 8, 2014 at 1:33 PM, Ian Hickson wrote:
> > I really like your proposal for "as="... Concretely it could look
> something
> > like this:
> >
> > > href="/some/asset.css"
> > as="stylesheet"(used to initialize default priority, headers,
> > etc)
> > load-settings="{}" (JSON payload with custom headers, priority
> > [2], etc)
> > media= "..." (relevant media queries..)
> > probability=""([0.0-1.0] used for speculative fetches
> [3])
> > >
>
> I don't understand why this would be better than:
>
> loadsettings="..." media="...">
Better or worse is not the point. I think the current proposal fails to
address the larger underlying problem.
The platform is missing a lower-level primitive (declarative and
imperative) that is able to explain resource loading with the same
expressive power as requests initiated by the browser itself. XHR provides
arbitrary resource loading, but it lacks the power to express
transport-layer options such as relative request priority and dependencies,
and it also hides requests from the preload scanner, which is a deal-break
for performance. To address this, we need two things:
(1) Fetch API with "load-settings" addresses the imperative side of the
problem.
(2) We also need a declarative, content-type agnostic primitive to express
resource loads, such that the preload scanner is able to pickup and
processes these fetches on par with all other resources -- hence my
rel=preload suggestion [1].
We can augment img, script, and other elements, with load-settings and
other flags, but that still doesn't cover all the necessary cases. For
example, how do I fetch a font file, or an arbitrary JSON payload with
app-data, etc? Note that I'm looking for declarative syntax that allows me
to set arbitrary fetch priorities - e.g. upgrade my JSON payload to high
priority because I need it to render content on the screen. This is the
part that we *need* to solve.
Once we have the low-level declarative+imperative primitives for loading
resources, we can build up all other loading and dependency patterns in
app-space. The loadpolicy/needs attributes are syntax sugar for select
resource types -- nice, but (IMO) not strictly necessary and not sufficient
for the more general case of content-types not covered by dedicated
elements.
ig
[1] https://igrigorik.github.io/resource-hints/#preload
Re: [whatwg] Preloading and deferred loading of scripts and other resources
I got some feedback on my last e-mail to the effect that having the proposal sandwiched between the rationale and the examples of how it would be used made it hard to find, so I'm reproducing the proposal here (slightly updated based on feedback): --- These "loadable" elements: , ,