Re: [whatwg] Deferring javascript download and execution until after onload

Further evidence that the current state of the web is not friendly with respect to how browsers default to treating script loading/parsing/executing.

https://www.facebook.com/notes/facebook-engineering/under-the-hood-the-javascript-sdk-truly-asynchronous-loading/10151176218703920

The efforts that Facebook and Meebo are going to, to get around the blocking behavior of loading/parsing/execution of JavaScript, are astounding. This is just another example of the crazy hacks web apps go to so they can optimize this script loading process in the overall web performance picture. Talented development teams like Facebook and Meebo wouldn't be doing these crazy hacks if there wasn't a real need for the effects they achieve.

From where I stand, this is more solid evidence that we actually DO need more fine-grained control over a script load, so that the Facebook/Meebo technique wouldn't be needed. Instead, you could simply load whatever you wanted asynchronously in the background, in whatever order, and at whatever time, then choose when you want each preloaded script to be executed. In that way, they get to prevent side-effects on the DOMready/onload of a page without all these crazy hacks.

As I have been doing for 2 years now, I once again implore the decision makers of the web platform to recognize the validity and utility of this feature request. Let us preload scripts by separating (in some way) the download from the parse/execution phase. IE has had this simple feature for more than a decade, since IE4. That the web platform and other browsers haven't seen the value of this yet is dismaying.



--Kyle

Received on Saturday, 8 December 2012 20:37:03 UTC