If you don't wait for the DOM to load, it really can make it hard to alter parts of it, and it can cause odd problems that are hard to debug because it creates timing inconsistencies.<p>I'd much rather see a small DOM, so the ready event can fire quickly than do something like this.<p>For an extension I wrote which adds interface elements to the Facebook timeline, I needed a custom solution to monitor when parts of the dom were changing, since facebook implements infinite scroll. In this case I couldn't use mutation even if I wanted to because of the scoping of chrome extensions.<p>Since the facebook implementation does a lot of work to render infinite scroll quickly i needed something fast, and lightweight. for this i choose a pattern that locates new dom elements on an interval, appends a class, and then triggers a new event, which then looks for that class ( which is indexed by the browser ) and then does a foreach on each of those new elements only.<p>I found setting the interval to 100ms was a good fit on facebook, as it's generally the amount of time that a user will take to notice a change. I could have set it lower, to 50ms, 20ms, or even lower, but i found that it caused too much blocking. in many cases the DOM and javascript both need access to the threads and if you have intervals running on too small of an interval, like 5 seconds in this library you are likely going to block the dom from rendering quickly. also, it's unlikely that the browser will actually fire something at 5ms precision.<p>if you are going to follow a pattern like this i would advise you to use something in the 25ms+ range for your interval and also make sure that your interval script does not cause an invalidation on your browser elements. on a second async call you can then safely alter each element which should assure that you don't have any blocking behaviors.