$.ready() before closing body
This is not a real coding question, more of a real-world statement.
I have previously noted that DOMReady events are slow, very slow. So, I noticed while br
-
By triggering the event yourself, you are stating to your ready() handlers that your dom has been loaded BUT it may not have been! There is no short cutting the DOM ready event. If there is indeed a long wait time, then employ the amazing debugging tools of firebug, chrome, etc.... check your resources and their timing ques. It's all there in black and white and will indicate what is taking so long (the requests, the rendering, how many resources, etc.. )
讨论(0) -
Actually, placing a function call before
</body>tag makes it pointless to use jQuery'sready(). Just put native JS-wrapper function call that contains calls of all other functions that should be called on document ready.In general, it's a working (though somewhat littering HTML code and therefore unacceptable for perfectionists) alternative for situations when author does not need/want to use jQuery at all. In such situations though, I would prefer to use native
DOMContentLoadedevent handler that is supported by most of browsers including IE9+ (for IE8- we can usewindow.load()as an acceptable fallback).讨论(0) -
Any ideas why this is not discussed/recommended more frequently?
Placing JavaScript just before
</body>has been discussed a lot, and as you know it's recommended if you're looking for faster page loads. Manually triggering the jQueryreadyhandlers is in fact poorly discussed. Why? Well, I don't think there is one single objective answer to that, but I'll try to outline some possibilities here:Performance is not the main goal of jQuery (anthough it's definitely a concern), and performance freaks will usually look for lighter libraries for cross-browser DOM manipulation and event handling, or roll their own.
It's an extra step, and it doesn't look clean. jQuery tries to be clean and elegant, and recommending an extra step to initialize scripts doesn't sound like something that's gonna happen. They recommend binding to
ready, so recommending to force.ready()and ignoring the actual browser event looks "wrong". Whoever is concerned about that probably knows that initializing scripts right before</body>is faster.Optimizing
DOMContentLoadedsounds like a task for browser vendors. I'm not sure why it's slower, though, and maybe there's not much room for optimization – in my understanding, calling init scripts before</body>should always be the fastest way to initialize stuff (as it's executed immediately when parsing the container<script>tag, while browsers must finish parsing the whole file before triggeringDOMContentLoaded).
You probably remember that not so long ago it was common practice to have
<script>blocks scattered everywhere on the HTML. Then the Web Standards movement came, and recommended more sane and maintanable ways to do things. That included bootstraping scripts from a single place – initially,window.onload, which was then considered problematic for being slow, thenDOMContentLoadedand its emulations for IE8 and below. However, we still see spaghetti-HTML with scripts everywhere on a daily basis here on StackOverflow. So I'm not sure if recommending placing scripts before the end of the body is a good call today, because it may be interpreted as a license to add scripts anywhere within the body.Finally, if you're really concerned about loading your script fast, and your code does not manipulate the DOM, the fastest way to load it is to put it in the
<head>before any stylesheets. And I'm stating that just to say that there's no silver bullet, no optimal way to init scripts that is the fastest and most elegant in every scenario. I think that's why the community sticks with recommending something that looks sane and tends to create more maintainable code, instead of other better performing alternatives.讨论(0)
加载中...
- 热议问题