Re: [whatwg] Media aware JS loading

Some Comments inline.

I will preface this with I feel this problem needs to be solved mire
elegantly but we got a good solution in place without the need for the
script to be in the DOM before onload.

Our base scripts in the HTML were consistent across all form factors (so we
got the parser benefits), and then we had a one time pass that would work
out the scripts that needed to be loaded based on the media query tests.
Then when orientation events happened or other actions that would have
meant other MQ rules passed, we no longer cared because the ui and
experience had already loaded.

P

On 25 May 2013 23:15, "Yoav Weiss" <yoav@yoav.ws> wrote:
>
> 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?

No. For a couple of reasons, 1 without dependencies means no access to
global state. 2, media queries have no logical OR which means if you want
one script to match multiple media queries (such as one that would match
tablet and one that would match tv) you need to declare script blocks
multiple times.

> * Can't the media dependant scripts "clean out" the scripts that already
ran and are no longer relevant for current form factor?

I don't know how you isolate the script so much so that it has no side
effects. You might clean out the script but it might have attached itself
to the Dom in event listeners or the global scope.

> * Do you have any opinions on re-running scripts upon media change? (such
as orientation change)

Same as above.

>
>
> 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 Sunday, 26 May 2013 07:38:01 UTC