Re: [whatwg] Media aware JS loading

Thanks for sharing your experience, Paul.
A few questions:
* Do you think that under the conditions I mentioned in the initial post
("media" works only on async scripts without dependencies, since running
order can be pretty much anything), things would have been better in your
case?
* Can't the media dependant scripts "clean out" the scripts that already
ran and are no longer relevant for current form factor?
* Do you have any opinions on re-running scripts upon media change? (such
as orientation change)


On Sat, May 25, 2013 at 11:19 PM, Paul Kinlan <paulkinlan@google.com> wrote:

> We developed formfactorjs for exactly this type of case (
> github.com/paulkinlan/formfactor) about 2 years ago.
>
> The use case we had was that we had one app that had to respond
> differently based on the form factor type, so a TV would load js that was
> specific to just the TV (ie loading remote controller logic) and a tablet
> would loads js that responded to finger based touch gestures and a phone
> type media query would load js for thumb based gestures.
>
> We got to the point where were talking about trying to have media queries
> on script element to save us from this library we created, however we
> quickly found that things like orientation changes would mean that there is
> a high degree of chance that the developer would have scripts that would
> need to be loaded at some undeterminable time in the future that would
> clash with the scripts that had already been loaded and ruin the state in
> our app (such as scripts sectioned by min-width queries).
>
> We didn't find any reasonable solution for this issue other than force a
> reload of the page :/
>
> P
> On 25 May 2013 21:25, "Yoav Weiss" <yoav@yoav.ws> wrote:
>
>> >
>> > How bad is the current situation with JS-based loaders? I would expect a
>> > JS-based loader and the couple of feature-detection tests to be rather
>> > small as well as heavily cachable, so not that awful for performance.
>> >
>>
>> JS based loaders have several drawbacks:
>> * JS files are not discovered by the preloader, which means the browsers
>> can't prioirtize their download appropriately.
>> * They require JS inlining, which will become significantly harder with
>> CSP
>> (JS nonces make it possible, but it'd require server side logic)
>> * Arguably, attributes make authoring easier, which may mean authors are
>> more likely to avoid useless JS downloads.
>>
>>
>> > I'm not sure I understand your point about preloading scripts parsing.
>> Do
>> > you want them to be preparsed (which costs in battery as you mention) or
>> > not preparsed (which will result in longer time when actually needing
>> the
>> > script)?
>>
>>
>> I was referring to HTML parsing (so the discvery of JS resources in HTML),
>> not the parsing/execution of the JS resources themselves.
>>
>>  How much time can be expected to be gained from such a feature given the
>> > state-of-the-art JS loaders?
>> >
>> > Overall, what is the expected gain between a JS-based loader and a
>> > declarative media-aware loader? 1ms? 100ms?
>> >
>> > While the expected gain may vary per site, I'd estimate that it's
>> probably
>> in the area of hundreds of ms for most sites. A recent study by Google
>> (addressing this specific issue) showed that the PreloadScanner gives ~20%
>> improvement https://plus.google.com/+PaulIrish/posts/WcsqfSFZAfR
>>
>

Received on Saturday, 25 May 2013 22:15:40 UTC