[whatwg] Proposal for separating script downloads and execution

[Alexandre Morgaut]

Hi Ian,

Thank you for all the time you're spent reading this thread.

My understanding right now is that:

- if we want a script to be downloaded without blocking the UI, we should use "async"
- implementors shouldn't block the UI while parsing the JS (but it should  still respect the order of execution when required)

You pointed about a lack of use cases, so here an humble use case in which I might have been interested by having an execute() method. I tried to fix it using "async".

 “Use case":

Some script are not "required" to be executed until a user action like a "click", so that's great if their loading, parsing, and execution doesn't block.  For progressive enhancement, I like to run first only what is mainly required.
But once the user does this kind of more specific action, the event handler may not work as a the script providing the required behavior might not be yet executed.

Try to resolve this:

- I consider scripts providing such behaviors as named modules
- when such user action happens
        - I fix a setTimeout() with a handler showing a "processing" feed back to the UI if the action takes to much time, as I would if I need to fetch data
        - instead of invoking my specific behavior, I add its invocation in a named callbacks list which will be looked by the "module" having the same name at the end of its initialization
                - Note: the callback will cancel the setTimeout or remove the "processing" feedback

So I can already do this without new vendor implementation. It just add more asynchronous code in my app to handle
But, to be honest, my first intuition was:
- change the "async" attribute value of the script element to false to block the script execution of the "click" (or any other) event handler until the required script as been executed
        -> it could prevent the requirement of handling asynchronous code via callback lists, but I'm not sure how much it is acceptable


I'll check in our team for other potentials uses cases and look how much "async" could already solve these.

Regards







Alexandre Morgaut
Product Manager

4D SAS
60, rue d'Alsace
92110 Clichy
France

Standard : +33 1 40 87 92 00
Email :    Alexandre.Morgaut at 4d.com
Web :      www.4D.com