TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Faster than jQuery(document).ready() - Wait Until Exists

96 pointsby AltIvanalmost 14 years ago

12 comments

spjwebsteralmost 14 years ago
DOMNodeInserted is deprecated in the DOM Level 3 Events recommendation, along with all the other mutation events:<p><a href="http://www.w3.org/TR/DOM-Level-3-Events/#event-type-DOMNodeInserted" rel="nofollow">http://www.w3.org/TR/DOM-Level-3-Events/#event-type-DOMNodeI...</a><p>They have been deprecated because they perform poorly:<p>&#62; Firefox, for example, when it realizes that a mutation event has been turned on, instantly goes into an incredibly-slow code path where it has to fire events at every single DOM modification. This means that doing something like .innerHTML = "foo" where it wipes out 1000 elements would fire, at least 1000 + 1 events (1000 removal events, 1 addition event).<p><a href="http://lists.w3.org/Archives/Public/www-dom/2009AprJun/0072.html" rel="nofollow">http://lists.w3.org/Archives/Public/www-dom/2009AprJun/0072....</a><p>&#62; Mutation Events are widely acknowledged as “slow” in terms of the real performance degradation that occurs on websites that use them heavily for tracking changes to the DOM<p><a href="http://www.w3.org/2008/webapps/wiki/MutationReplacement" rel="nofollow">http://www.w3.org/2008/webapps/wiki/MutationReplacement</a>
评论 #2802023 未加载
cstuderalmost 14 years ago
You know how you can accelerate your page even further?<p>Don't use 1.49mb large GIF animations as background images...
评论 #2802214 未加载
评论 #2803193 未加载
评论 #2801980 未加载
评论 #2803014 未加载
mathiasalmost 14 years ago
Why are you comparing this to `jQuery(document).ready()`? Apples and oranges.<p>You say it’s faster, but fail to provide any numbers / a jsPerf test case. I’m sure it’s faster to execute `waituntilexists()` <i>initially</i>, but if you take into account it uses an 5ms interval in which it traverses the DOM for the same elements over and over again until they’re finally found, it seems it probably has a negative impact on performance overall.<p>What’s wrong with event delegation anyway?
评论 #2803715 未加载
tszmingalmost 14 years ago
The polling approach is already used in the YUI2' onAvailable method. <a href="http://yui.yahooapis.com/2.9.0/build/event/event.js" rel="nofollow">http://yui.yahooapis.com/2.9.0/build/event/event.js</a><p>But your code should be faster -because you are polling at the 5ms interval!
评论 #2802288 未加载
Jenchaalmost 14 years ago
"it's faster" - but where are the numbers?
评论 #2802262 未加载
NathanKPalmost 14 years ago
I like the idea and it does seem that it could reduce the time that your JavaScript code has to wait before it can run. However, in reality most real JavaScript front end code frameworks require not just one element but multiple elements, and nested elements. I would be hesitant to start running JavaScript just because one element was ready unless I was sure that other elements that my code referenced or manipulated were also ready. I'm sure it would be possible to make a version that allowed you to specify a list of elements to wait for before running code, but then that creates a nightmare for code maintenance, keeping track of the entire list of elements that your JavaScript requires. For me the jQuery(document).ready() method seems easier and more reliable.
biotalmost 14 years ago
Given that you're releasing this as open source, why not put it into a GitHub account instead of Pastebin?
valisystemalmost 14 years ago
Quick remarks :<p>* I could test it myself, but I expected to have in the article detailed information on the different possible states the document can have when my callback is called. The questions I know the answer when waiting for the whole document to be loaded : Is it half loaded ? What is the DOM state ? Is completely loaded ? If not, have the document JavaScript code been entirely ran ? and so on. This kind of question left unanswered often lead to hard bites.<p>* why using "itself" ? I would have used a "sensible default" : when no context is given, use the waited DOM object instead of an arbitrary value (document), and use something else when it is explicitly given. The "itself" thing should be left as an internal flag IMHO.
评论 #2803788 未加载
dmethvinalmost 14 years ago
Does someone have a really good example of where this would be useful? The description is basically, "When this element exists, do something" but what is the something you'd do? If it's styling, that should be done in CSS. If it's event handlers, that can be done with `.live()` or `.delegate()`.<p>I'd also like to see some benchmarks to back up the assertion that this is faster. The DOM modification events are generally accepted as slow and it seems like this is leaving a handler attached for the duration of the page's existence.
评论 #2802688 未加载
评论 #2803730 未加载
acangianoalmost 14 years ago
Something like this should be built-in in jQuery.<p>You can do $(document).ready(), why not, the admittedly syntax sugared, $("div#main").ready().
评论 #2803319 未加载
评论 #2802351 未加载
评论 #2803225 未加载
ck2almost 14 years ago
Very clever.<p>I'd like to know if there is any performance hit though, NodeInserted fires on basically on every single fraction of page creation.
评论 #2803801 未加载
dawjanalmost 14 years ago
This script is amazing i use for load cufon i try<p>/<i>Cufon.DOM.ready(function() {</i>/ /<i>$(window).load(function () {</i>/ /<i>$(document).ready(function() {</i>/ /<i>Cufon.DOM.ready(function() {</i>/<p>And now is 40% faster