There is no such thing as "DOM promises".
From: Kyle Simpson<>
Sent: ‎3/‎14/‎2014 20:35
Subject: Re: [whatwg] Promise-vending loaded() & ready() methods on various 

I'd also like to make the observation that putting <link rel=preload>.loaded() 
together with <script>.loaded(), and indeed needing a promise mechanism to wire 
it altogether, is a fair bit more complicated than the initial proposals for 
script preloading use-cases from the earlier threads over the last few years of 
this list.

For one, we're talking about twice as many DOM elements. For another, 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. I don't know if that's 
already a guarantee or if there are some browsers which are possibly going to 
land DOM promises before ES6 promises? If so, ES6 promises become the long 
pole, which isn't ideal.

Lastly, I'd observe that many of the arguments against the original/previous 
script preloading proposals were heavily weighted towards "we don't like script 
loaders, we want to make them obsolete, we need simple enough (declarative 
markup) mechanisms for that stuff so as to make script loaders pointless…"

At one point the conversation shifted towards ServiceWorker as being "the 
answer". When we explored the use cases, it was my impression there was still a 
fair amount of non-trivial code logic to perform these different loading cases 
with SW, which means for the general user to take advantage of such use-cases, 
they're almost certainly going to need some library to do it.

I can't imagine most end-users writing the previously-suggested ServiceWorker 
code, and I'm having a hard time believing that they'd alternatively be writing 
this newly suggested promises-based loading logic all over their pages. In 
either case, I think for many of the use-cases to be handled, most general 
users will need to use some script-loader lib.

So, if this .loaded() DOM promises thing isn't the silver bullet that gets us 
to "no script loader utopia", then I don't see why it's demonstrably better 
than the simpler earlier proposals.

Moreover, the earlier proposals relied on the browser having logic built-in to 
handle stuff like "download in parallel, execute serially", which made their 
interface (the surface area users needed to work with) much less than either 
the Promises here or the ServiceWorker before.

What you're implicitly suggesting with both sets of suggestions is, let's make 
the user do the more complicated logic to wire things together, instead of the 
browser doing it. Why?

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?


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?


Reply via email to