Frankly, I'm surprised a casual comment on G+ is getting any traction whatsoever on HN.
If it is taking a while to fire, better to solve that problem than piss around with a half built page in my experience. I experimented at one point with js enhancing controls just after they were declared, it's honestly not worth the effort. He'll learn.
This smacks of the bootstrap semi-colon nonsense, we all tried semi-colonless once, it ends up a nightmare, but some mistakes the next generation need to figure out themselves.
Seconded. This can cause far more bugs and timing problems than it's worth. Find out what's taking so long to fire, and fix (or defer) that.
I'll take sane, library-agnostic script without event listeners for $500, Alex.
You should take a queue from Flickr. I took a look at how they handled this, and I think it's one the best I have seen so far.
The method there could actually be a small amount of code, and wouldn't require that you load jQuery before queuing events.
Use the source, Luke!
I guess the assumption here is that your script tags are placed at the end of the document - because if your scripts are placed in the <head> and they try to do things like getElementById (which does not "rely on CSS") before the DOM has been parsed, you'll definitely get an error.
The post is referring back to the old jquery advice of "put everything in $(document).ready".
This implementation naturally needed polling of the DOM, but YUI's always been pretty smart about clubbing polling events together, and not doing too much at the same time.
Combined with the fact that you only need to load the YUI bootstrap code up front and let everything else load asynchronously, this can significantly reduce download time.
Twitter is just going through a complete re-arch of their front end to stop loading via XHR and says they're getting a 5x speed improvement
I'm not sure about ready vs load, but that would make sense.
As for downloading CSS -- it won't prevent your JS from executing, but it'll block page rendering until all the stylesheets have been downloaded and parsed.
DOMContentLoaded, in all important browsers, does block to wait for CSS.
Manipulating the DOM before this event both increases the chance to make changes before first-paint (decreases "jigger" on page load) and gives you the chance to request more resources earlier.
I guess I never really noticed this because my scripts are always included so much later in the document than my CSS.
It most surely will, in at least Gecko and WebKit. Too many pages have JS that depends on all preceding stylesheets having been loaded.
We've linked page load times directly to lower sales funnel drop outs, I would warn against this for some people, as you will be blocking/delaying rendering of the DOM for code that is ultimately not impacting the UI
I have an improvement suggestion. If the client supplies their own condition, like in your example waiting for a specific element to be loaded, what about (optionally) disabling the check once onload happens?
As it is, a rogue condition check could run indefinitely.
I envisioned using it both for on-ready and for processes that might occur after page load. Sometimes widgets don't have callbacks, or for a long running template being shoved into the dom or some other such situation.
I could add a fourth (optional) boolean parameter -- stopOnReady; false ends on pageLoad, true on pageReady, and null stops on condition === true.
As to a long running check; 1.) the reason I use interval, as opposed to timeout, is that if the number of client events get heavy it will delay invoking the condition function . 2.) a getElementById is native and trivial (in other words -- just don't do anything crazy in the condition function).
Or, using jQuery, you could probably define a custom event on the <body>, that you trigger manually from the bottom of your <body>, and have your scripts in the <head> listen for that event. I've never actually tried this, though.