Don't wait for "DOM ready" for your app to start
Honestly, I don't like claims like this that are offered without any support. Why shouldn't I wait for the DOM to be ready? Am I losing performance? If so, where are the benchmarks?
Frankly, I'm surprised a casual comment on G+ is getting any traction whatsoever on HN.
At Mozilla, we were losing a few add-on download clicks because of the lag from putting the JavaScript at the bottom. So, we created a tiny bit of JS that recorded important events, which we loaded in the <head>. The queue re-fired off the events once the JavaScript loaded.
https://github.com/mozilla/zamboni/blob/master/media/js/impa...
"One should always start JS apps as early as possible and only delay operation until the "DOM is ready" that want to measure dimensions, etc. (Things relying on CSS)."
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.
This is one of the reasons YUI added the onAvailable method back in the day (2006 IIRC). See http://yuilibrary.com/yui/docs/api/classes/Event.html#method...
onAvailable lets you run a piece of JavaScript once all the nodes it requires are available. Our first iteration just checked for the existence of the node, but that turned out to be a problem if the node was large and had several sub-nodes. A second iteration checked that the node existed and had a nextSibling. This meant that the node had completed loading and parsing and the browser was now on to the next node.
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.
I only wish YUI 2 had a better syntax that might have made it more popular. You'll have to take the word of those of us who worked at Yahoo! at the time, it was a huge improvement over YUI 1, and YUI 3 is far more JavaScript like and far less Java like.
Google avoids waiting for dom ready in webapps like gmail, and their closure library [1] doesn't have the equivalent of jquery's $(document).ready() [2].
[1] https://developers.google.com/closure/library/ [2] https://groups.google.com/group/closure-library-discuss/brow...
jQuery popularized the idea of DOM ready (which is DOMContentLoaded to the browser). DOM ready was a big improvement from what we used to do which was waiting for the onload event to fire. It turns out the majority of the stuff we do in JavaScript touches the DOM in some way and you can't read or manipulate the DOM until it's ready. If you have code that doesn't touch the DOM, then sure, you don't have to wait, but those instances are pretty rare in the real world. The big thing to keep in mind is that both CSS and JS block the DOMContentLoaded event. The best thing you can do is keep the CSS and JS that blocks your rendering to a minimum. DOM ready is usually your "perceived performance" so it's best to get there as fast as you can. Instead of trying to get your JavaScript running before on ready, you'd be better off making sure you only have 1 CSS file in your head, that your JavaScript is at the bottom of the page and other standard WPO practices.
Some things you could do would include firing off XHR's and creating an unattached hierarchy of DOM nodes which could then be attached once the main DOM is ready. This could be neat.
undefined
I was under the impression that "DOM ready" did not wait for CSS, but that "load" did. In fact, i was also under the impression that CSS (loaded in the <head> at least) blocked any further processing until it's downloaded. Am I wrong?
"never wait for "DOM Ready" for an application to startup"
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
https://developers.google.com/speed/docs/best-practices/payl...
undefined
Is there a way to achieve the same effect while keeping scripts in the <head>? (Not saying that's the best idea, just wondering.)
undefined