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

Re: [whatwg] Script preloading

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Thu, 29 Aug 2013 17:30:04 -0700
Message-ID: <CABZUbM3Vb8YN_gB=cn4cJu5jH5+Maxi2F-jEWgcmuveapfbFkQ@mail.gmail.com>
To: Nicholas Zakas <standards@nczconsulting.com>
Cc: Brian Kardell <bkardell@gmail.com>, whatwg@whatwg.org, Jonas Sicking <jonas@sicking.cc>, Ryosuke Niwa <rniwa@apple.com>
On 8/29/13, Nicholas Zakas <standards@nczconsulting.com> wrote:
> 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.
>

Ian mentioned the idea of exporting a module, and that idea requires
only a function expression to return an object. This requires the
parsing of one function -- the outermost function -- which can be
evaluated later.

Some examples of this include the "Russian Doll Pattern" (Cornford)
"Module Pattern" (Crockford), IIFE (?), and function rewriting (me).

For more on this, see Kangax' article:
http://kangax.github.io/nfe/

(Kangax seems to have gotten bored at conquering javascript these days).

> 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.
>
Dependency issues include problems from having to block for scripts,
document.write, fouc.

Problems arising with dependency stem give rise to the need of
deferring and executing scripts. The problem is that the program needs
to run a script during a certain condition. And if that condition is
not met, then the script resource isn't needed at all.

This could useful for a situation where there are a few different
components on a page, say each component requires 100k of script and
10k of CSS. But the user will probably only use one of those three
components and might very well use none at all. I have worked on pages
like that, with sidebars, pickers, and panels, and I wanted something
like this.

As Ryosuke pointed out, the idea is to declare the script in the page
and then use script to determine when it should load.

My previous post on building a dependency tree delves into the idea
that CSS and JS can be declared to depend on stuff being loaded.  That
feature makes it obvious as to why they're in the source code, to the
human reader.

Regards,
-- 
Garrett
Twitter: @xkit
personx.tumblr.com
Received on Friday, 30 August 2013 00:30:31 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:23 UTC