[whatwg] Script preloading

Thu Aug 29 08:37:58 PDT 2013

When Kyle and I originally started pushing for a way to preload JavaScript
many moons ago, the intent was very simple: to allow the downloading of
JavaScript and execution of JavaScript to be separate. The idea being that
you should be able to preload scripts that you'll need later without
incurring the cost of parsing and execution at that point in time. There
are many examples of people doing this, the most famous being the Gmail
mobile approach of loading JavaScript in comments and then pulling that
code out and eval()ing it.

I still feel very strongly that this pattern is a necessary evolution of
how we should be able to load scripts into web pages. I just want a flag
that says "don't execute this now" and a method to say "okay, execute this
now". Allowing that flag to be set both in HTML and JavaScript is ideal.

The question of dependency management is, in my mind, a separate issue and
one that doesn't belong in this layer of the web platform. HTML isn't the
right spot for a dependency tree to be defined for scripts (or anything
else). To me, that is a problem to be solved within the ECMAScript world
much the way CSS has @import available from within CSS code.

I think the use cases other than the initial one (preload/execute later)
are best relegated to script loaders and are very tied to a current way of
thinking about loading JavaScript. I'd rather provide a simple, low-level
piece of functionality that make the job of script loaders easier by
providing a reliable API and then let the dependency management use cases
be addressed outside of HTML.

Other random thoughts:

* "whenneeded" is a very strange name for that attribute. It doesn't really
tell me anything, as opposed to "preload", "noexecute", or "future". How do
I know when it will be needed?

* I like execute() as the way to run the script in question.

-N

On Thu, Aug 29, 2013 at 5:58 AM, Brian Kardell <bkardell at gmail.com> wrote:

> On Aug 29, 2013 1:21 AM, "Jonas Sicking" <jonas at sicking.cc> wrote:
> >
> > Hi Ryosuke,
> >
> > Based on the feedback here, it doesn't sound like you are a huge fan
> > of the original proposal in this thread.
> >
> > At this point, has any implementation come out in support of the
> > proposal in this thread as a preferred solution over
> > noexecute/execute()?
> >
> > The strongest support I've seen in this thread, though I very well
> > could have missed some, is "it's better than status quo".
> >
> > Is that the case?
> >
> > / Jonas
> >
> > On Wed, Aug 28, 2013 at 7:43 PM, Ryosuke Niwa <rniwa at apple.com> wrote:
> > > On Jul 13, 2013, at 5:55 AM, Andy Davies <dajdavies at gmail.com> wrote:
> > >
> > >> On 12 July 2013 01:25, Bruno Racineux <bruno at hexanet.net> wrote:
> > >>
> > >>> On browser preloading:
> > >>>
> > >>> There seems to an inherent conflict between 'indiscriminate'
> Pre-parsers/
> > >>> PreloadScanner and "responsive design" for mobile. Responsive designs
> > >>> mostly implies that everything needed for a full screen desktop is
> > >>> provided in markup to all devices.
> > >>>
> > >>>
> > >> The pre-loader is a tradeoff, it's aiming to increase network
> utilisation
> > >> by speculatively downloading resources it can discover.
> > >>
> > >> Some of the resources downloaded may be not be used but with good
> design
> > >> and mobile first approaches hopefully this number can be minimised.
> > >>
> > >> Even if some unused resources get downloaded how much it matter?
> > >
> > > It matters a lot when you only have GSM wireless connection, and barely
> loading anything at all.
> > >
> > >> By starting the downloads earlier, connections will be opened sooner,
> and
> > >> the TCP congestion window to grow sooner. Of course this has to be
> balanced
> > >> against visitors who might be paying to download those unused bytes,
> and
> > >> whether the unused resources are blocking something on the critical
> path
> > >> from being downloaded (believe some preloaders can re-prioritise
> resources
> > >> if they need them before the preloader has downloaded them)
> > >
> > > Exactly.  I'd to make sure whatever API we come up gives enough
> flexibility for the UAs to decide whether a given resource needs to be
> loaded immediatley.
> > >
> > >
> > >
> > > On Jul 12, 2013, at 11:56 AM, Kyle Simpson <getify at gmail.com> wrote:
> > >
> > >> My scope (as it always has been) put simply: I want (for all the
> reasons here and before) to have a "silver bullet" in script loading, which
> lets me load any number of scripts in parallel, and to the extent that is
> reasonable, be fully in control of what order they run in, if at all,
> responding to conditions AS THE SCRIPTS EXECUTE, not merely as they might
> have existed at the time of initial request. I want such a facility because
> I want to continue to have LABjs be a best-in-class fully-capable script
> loader that sets the standard for best-practice on-demand script loading.
> > >
> > >
> > > Because of the different network conditions and constraints various
> devices have, I'm wary of any solution that gives the full control over
> when each script is loaded.  While I'm sure large corporations with lots of
> resources will get this right, I don't want to provide a preloading API
> that's hard to use for ordinary Web developers.
> > >
> > >
> > > On Jul 15, 2013, at 7:55 AM, Kornel Lesiński <kornel at geekhood.net>
> wrote:
> > >
> > >> There's a very high overlap between module dependencies and <script
> dependencies> proposal. I think at very least it would be useful to define
> <script dependencies> in terms of ES6 modules, or even abandon markup
> solution to avoid duplicating features.
> > >>
> > >> ES6 modules however do not solve the performance problem. In fact they
> would benefit from UA having a list of all dependencies up front (otherwise
> file's dependencies can only be discovered after that file is loaded, which
> costs as many RTTs as the height of the dependency tree).
> > >>
> > >> So I think that eventually ES6 modules + link[rel=subresource] could
> be the answer. The <link> would expose URLs to (pre)load for performance,
> but modules would handle actual loading/execution for flexibility and
> reliability.
> > >
> > >
> > > Yes, we should definitely consider how this preloading API works with
> ES6 modules.
> > >
> > >
> > >
> > > On Jul 22, 2013, at 3:22 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> > >
> > >> Having the load event anytime we are done with a network request also
> > >> seems beneficial. Rather than having most APIs use "load" whereas this
> > >> would use "preload".
> > >>
> > >> Generally speaking "load" means "loaded and processed". The
> > >> 'noexecute' flag would change what the "and processed" piece includes.
> > >
> > > I don't think it'll be confusing if the script had noexecute.  We can
> even call it noautoexecute if we wanted.
> > >
> > >> But I'm fine either way here. The same question and risk of confusion
> > >> seems to exist with the "whenneeded" attribute. In general
> > >> "whenneeded" seems very similar to "noexecute", but with a little bit
> > >> more stuff done automatically, for better or worse.
> > >
> > > I like the simplicity of noexecute and excute().  However, I'm a little
> worried that it doesn't provide any information as to how important a given
> script is.  So Web browsers have no choice but to request all scripts
> immediately.
> > >
> > > I'd like to eventually provide APIs that allow authors to codify which
> scripts are "vital" so that Web browsers can properly prioritize each
> script request.
> > >
> > > Implementation wise, noexecute/execute() will be extremely easy to
> implement in WebKit.
> > >
> > >> I.e. something like:
> > >>
> > >> <script src="script1.js" id="s1">
> > >> <script src="script2.js" dependencies="s1">
> > >>
> > >> would run correctly in downlevel browsers, but would force the scripts
> > >> to be blocking.
> > >>
> > >> <script src="script1.js" id="s1" async>
> > >> <script src="script2.js" async dependencies="s1">
> > >>
> > >> would give you performant non-blocking behavior in downlevel browsers,
> > >> but at the expense of the scripts not always running in scripts in the
> > >> right order.
> > >
> > > Use defer instead?
> > >
> > > - R. Niwa
> > >
>
> I didn't get to it until this morning, but several folks on twitter have
> made the same general point I would toss in so let's move it here:
>
> "@slicknet: @Hixie @paul_irish this proposal conflates preloading with
> dependency management. I would ignore the latter (as I did originally)."
>
> "@paul_irish: @slicknet @Hixie I feel similarly. Adding HTML semantics for
> dep mgmt duplicates the work of AMD/CJS and ES6 modules.
> #writingemailishard :)"
>
> "@_JamesMGreene: @paul_irish @slicknet @Hixie Agreed, adding script
> dependency management in HTML would be complicated, messy, and verbose."
>
> Me: what they said.
>

-- 
________________________________________
Nicholas C. Zakas
http://www.nczonline.net
@slicknet