W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2014

Re: [whatwg] Promise-vending loaded() & ready() methods on various elements

From: Jake Archibald <jaffathecake@gmail.com>
Date: Sat, 15 Mar 2014 08:41:56 +0000
Message-ID: <CAJ5xic-roEHHPeafPNaHETzSxuCtRb6yxZJZVWnRg65ncm5mZg@mail.gmail.com>
To: Kyle Simpson <getify@gmail.com>
Cc: "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>
On 15 March 2014 00:35, Kyle Simpson <getify@gmail.com> wrote:

> there's a seemingly implicit requirement that we have to get both ES6
> promises and DOM promises to land for these suggested approaches to work.


ES6 promises are already in Chrome stable, they're on the route to stable
in Firefox. Promises will only be absent in browsers that have no intention
of being ES6 compliant.


> At one point the conversation shifted towards ServiceWorker as being "the
> answer".
>

It isn't. Network requests are still async in a ServiceWorker world. You
can use it to prepare caches and respond to requests with it, but if your
response strategy is "try cache, then network, then fallback" <link
rel=preload> can still give you a performance benefit by going through that
process sooner.


> Why isn't putting preloading into existing <script> elements (whether
> exposed by events or by promises) better than splitting it out into a
> separate element (<link rel=preload>) and requiring a third mechanism
> (promises) to wire them up?
>

Preloading is important for more than just scripts, making it a script-only
feature is restrictive. Preloading is useful for images, audio sprites,
initial JSON requests etc etc.

Is there any chance we could take a fresh look at the earlier proposals
> (putting both preloading and loading/exec into <script>), and perhaps
> freshen them up with promises instead of events?


Going back to the proposal in the OP, this isn't intended as the full
solution to the previous script loading thread(s). All new async/failure JS
& DOM APIs use promises, but our existing APIs need this love too. Not just
for scripts, but for stylesheets, images, xhr and mixing all those things
together with Promise.all.

<link rel=preload> is a separate effort, but I wanted to show the
flexibility you get with these components and add to the use-cases.

Yes, the script loading stuff can be revisited, but it's a separate effort
to these promise-vending methods & <link rel=preload>.
Received on Saturday, 15 March 2014 08:43:04 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:17 UTC