There's an interesting article on Ajaxian today that discusses part of this:
http://ajaxian.com/archives/labjs-simple-abstract…

I think it would be really hard. I've just been coding in php and was trying to think of some way to make it work like __call, __get, __set, etc. I'll have to try it out and see what I can come up with.

Is there a way to track it back to know exactly which function caused the error? It feels like it would be really hard to isolate errors from JS not being loaded from anything else that could happen.

Yes this is true. My main concern with 3rd party scripts is that the end of the first script might not be the end of the necessary JS. Often remote scripts will then load multiple other objects/scripts that may be necessary for the code to function properly. And since it's a remote script, even if this isn't the case today, it could be tomorrow 😉 It's a safe bet if it's your own JS though that you know when the last bit of JS you need is and can insert it there. You can even include it as a conditional paramater in the script request if you don't want it to load all the time. Like:
http://mydomain.com/js/script.js?callback=true

Or something similar, which can then be setup to only include the function call when that parameter is set.

I like your suggestion of calling dequeue_actions() sooner. It might get tricky if you are including multiple javascript files in a non-blocking fashion. If you're loading them via standard <script> tags it would be simple to add an inline <script>dequeue_actions()</script> right after your includes even if they're on different domains.

A more complicated version could easily take an array of scripts to be lazy-loaded and then watch the onload/onreadystatechange for each of them & only call dequeue_actions() once they were all done. I found some code that would be a great start for anyone interested in taking that on: http://www.nczonline.net/blog/2009/06/23/loading-…

Thanks for re-posting this. That's a good point about people on slow connections — although I would argue they're like IE6 users, they're already pretty used to having a crappy experience on the web. 🙂

When it comes to website performance, it's usually the perceived speed that matters. You can have something downloading for a minute behind the scenes and it's okay as long as the site still *feels* fast.

What about just throwing up a loading indicator when something is added to the queue? That way you acknowledge the users' action but still keep the perception that the page loaded in 2 seconds… even if we're still a few seconds away from being truly done.

another solution would be to have javascript links disabled and/or invisible at load time and then write a function that enables them all – but this might be slow for a page with lots of links. better direction would be to disable the css block(s) where the javascript stuff is. it could also display a loading graphic while things are disabled. this would be more seamless but slower for the impatient user.

[reposted from facebook]

One thing you might consider to get a slight bit of extra performance is adding the dequeue_actions(); call to the end of the javascript you're loading (assuming you control the script and it's not loaded from a third party). This will allow the js to execute as soon as the necessary javascript is loaded instead of waiting for the onload event (which on a heavy page could be noticeably later).