3 ms·
Yes, Unfortunately this is a common misconception, and is why the Google closure library intentionally leaves this feature out (so people don't use it): >>The
by mythz 15y ago
Yes, Unfortunately this is a common misconception, and is why the Google closure library intentionally leaves this feature out (so people don't use it):
>>The short story is that we don't want to wait for DOMContentReady (or worse the load event) since it leads to bad user experience. The UI is not responsive until all the DOM has been loaded from the network. So the preferred way is to use inline scripts as soon as possible.
>>By intentionally leaving out DOMContentReady wrappers we have been able to prevent Google Apps to use on this anti pattern.
-- https://groups.google.com/forum/#!topic/closure-library-discuss/G-7Ltdavy0E https://groups.google.com/forum/#!topic/closure-library-disc...
Also see:
http://encosia.com/dont-let-jquerys-document-ready-slow-you-down/ http://encosia.com/dont-let-jquerys-document-ready-slow-you-...
http://stackoverflow.com/questions/6026645/document-readyfunction-vs-script-at-the-bottom-of-page http://stackoverflow.com/questions/6026645/document-readyfun...
- MRSA 15y agoJust for clarification, I was looking through Mozilla Developer network. There is no documented DOMContentReady event. There is a DOMContentLoaded [1] event which is target at the document object. There is also a load [2] event fired at the window object. This is fired when the document is completely loaded. jQuery.ready will use DOMContentLoaded and load as a backup. [3] It is common for jQuery developers to shove their whole code base into the ready callback, which I imagine would slow a page down. [1] https://developer.mozilla.org/en/Gecko-Specific_DOM_Events https://developer.mozilla.org/en/Gecko-Specific_DOM_Events [2] https://developer.mozilla.org/en/DOM/window.onload https://developer.mozilla.org/en/DOM/window.onload [3] https://github.com/jquery/jquery/blob/master/src/core.js https://github.com/jquery/jquery/blob/master/src/core.js