W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2013

Re: [whatwg] Media aware JS loading

From: Paul Kinlan <paulkinlan@google.com>
Date: Sat, 25 May 2013 22:19:49 +0100
Message-ID: <CADGdg3Ahi2=EdRc2dU2fjhM_KrnJaoBWwieLwOVjmq2B_i_OKA@mail.gmail.com>
To: Yoav Weiss <yoav@yoav.ws>
Cc: whatwg@whatwg.org, David Bruant <bruant.d@gmail.com>
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 21:20:20 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 25 May 2013 21:20:22 UTC