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? --Kyle
