On 15 March 2014 00:35, Kyle Simpson <get...@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>.