Well said. Couldn't agree more. I was blown away last night as well.

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

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.

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.

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-...

Nice job. Thanks for building on it and sharing your work.

That's basically the same as turning global variables on in your php.ini file -- convenient, but not safe. Major security implications arise when you give people the ability to set any local variables they want. For example, what would happen if they set $i = 50, or worse, figured out that you use the variables $user_id and a boolean called $logged_in? Attackers could sign in as anyone they wanted just by passing in the various GET variables. I guess you could try and sanitize the variable names later, but it's always easier to stop bad data at the door than allowing it in and being continually being suspicious of it.

In other words, I know it's temping, but don't do it. It's not good practice.

I was planning on leaving you anonymous. You were the person who chose to reveal your identity.

So.... he's hired??

The resume was legit and the guy actually responded. I've updated the post with his response.