Hey Shawn, that's interesting. I was just thinking about a similar solution with a JS widget we're creating for our users to embed on their websites.
I have an improvement suggestion. If the client supplies their own condition, like in your example waiting for a specific element to be loaded, what about (optionally) disabling the check once onload happens?
As it is, a rogue condition check could run indefinitely.
I envisioned using it both for on-ready and for processes that might occur after page load. Sometimes widgets don't have callbacks, or for a long running template being shoved into the dom or some other such situation.
I could add a fourth (optional) boolean parameter -- stopOnReady; false ends on pageLoad, true on pageReady, and null stops on condition === true.
As to a long running check; 1.) the reason I use interval, as opposed to timeout, is that if the number of client events get heavy it will delay invoking the condition function [1]. 2.) a getElementById is native and trivial (in other words -- just don't do anything crazy in the condition function).
----
[1]: http://blog.shawndumas.com/wait-until