ScriptInjector async /defer

[Oliver Krylow]

Are there any plans to support the 'async' and 'defer' attributes of the 'script' tag in ScriptInjector ?

Also, is it true that since the injected script in ScriptInjector is of type 'text/javascript' , browsers will hold the execution of the UI-Thread until that script is loaded because of a potential 'document.write()'?

If so, is the Code Splitting Feature of Gwt also affected by this, since it uses ScriptInjector internally?

Best regards, Oliver

[Thomas Broyer]

On Friday, September 13, 2013 11:33:49 AM UTC+2, Oliver Krylow wrote:

Are there any plans to support the 'async' and 'defer' attributes of the 'script' tag in ScriptInjector ?

There's no real reason to support them.

Script-inserted scripts always run async; the only reason to be able to set async (to false) is to enforce execution in insertion order.

As for 'defer', it only affects elements that are "parser inserted", not those inserted by scripts, so it's pointless to set it from GWT.

See https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script

That said, I'm not aware of any plan to add support for async.

Also, is it true that since the injected script in ScriptInjector is of type 'text/javascript' , browsers will hold the execution of the UI-Thread until that script is loaded because of a potential 'document.write()'?

No. Script-inserted scripts are always async.

BTW, the type of the script only affects whether the script will run or not, depending on whether or not it's understood by the browser.

 

If so, is the Code Splitting Feature of Gwt also affected by this, since it uses ScriptInjector internally?

N/A 

[Oliver Krylow]

Thank you for the clarification! 

I wasn't aware of the different handling of "script-inserted" scripts and I must admit I misunderstood the async /defer attributes. I was hoping to get on-demand parsing out of it; control over the point in time the browser starts parsing a previously downloaded script.

The idea is to test if we can get better perceived performance by loading scripts during the apps idle times, but defer parsing and executing it until user interaction necessitates it.

If my assumption is correct, one could more easily balance between startup time and perceived performance on low-bandwidth ,high-latency networks.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

[Thomas Broyer]

On Monday, September 16, 2013 9:39:41 AM UTC+2, Oliver Krylow wrote:

Thank you for the clarification! 

I wasn't aware of the different handling of "script-inserted" scripts and I must admit I misunderstood the async /defer attributes. I was hoping to get on-demand parsing out of it; control over the point in time the browser starts parsing a previously downloaded script.

You could download the script using an XMLHttpRequest (or RequestBuilder, or whatever) and then inject it with the ScriptInjector (either as text, or with the URL, using the pre-load request to warm the browser cache only).

With code splitting, you have com.google.gwt.core.client.prefetch already to support that exact use-case. You can also customize how fragments are loaded using a custom AsyncFragmentLoader.LoadingStrategy (you could, for example, embed the fragments in the HTML host page in a way that does not parse them and have the LoadingStrategy load them from here, see http://googlecode.blogspot.fr/2009/09/gmail-for-mobile-html5-series-reducing.html; or maybe load them to into/from HTML5 storage); note that this is an "impl" API though, so it can theoretically change between GWT releases (put differently, we don't guarantee any forward/backward compatibility for ".impl" APIs).