It's good to know that this situation will lead to improvements in jQuery.<p>However, I'm disappointed in how twitter, or more accurately, Dustin Diaz handled this situation. They identified some performance issues. Narrowed it down to a jQuery version but just left it there.<p>jQuery is open source so they could have done some investigating on their own and tried to narrow down what changed in that selector. Especially since this change was blogged about (as mentioned by John).<p>Not to mention various people helped out twitter by finding some pretty obvious flaws and made suggestions. Twitter has a lot of resources and I'm assuming a lot of talented Javascript engineers. This is a situation where they could have used their resources to contribute to an open source project instead of the other way around.
I use a generic version of the waiting-for-pause trick:<p><pre><code> // execute callback only after a pause in user input; the function returned
// can be used to handle an event type that tightly repeats (such as typing
// or scrolling events); it will execute the callback only if the given timout
// period has passed since the last time the same event fired
function createOnPause(callback, timeout, _this) {
return function(e) {
var _that = this;
if (arguments.callee.timer)
clearTimeout(arguments.callee.timer);
arguments.callee.timer = setTimeout(function() {
callback.call(_this || _that, e);
}, timeout);
}
}
</code></pre>
Use it like this:<p><pre><code> document.addEventListener('scroll', createOnPause(function(e) {
// do something interesting here
}, 1500, this), false);
</code></pre>
Edit: Oops! The version in the article runs some code if any scroll event occurred since it last fired, but this one doesn't execute the callback until the user stops scrolling for some amount of time. Anyway, maybe it's still useful for some folks.
jQuery makes things almost too easy. As a result it gives confidence and power to a lot of people to write code that despite all sillines will still work. A professional JS developer would've debounced the scroll events and cached the selector results.
This sort of thing is one reason I hate websites which use a lot of Javascript when they don't need to. Another reason is that it breaks expectations of how websites should work.
>since scrolling itself didn't change the DOM<p>Scrolling did indirectly change the DOM as you load more tweets when you scroll. But the point here is that the actual scrolling is not changing the DOM, the append is, and that's probably when you should update your query cache.
What in the world. I expected something interesting, but this is some major fail by twitter. Not caching selectors just boggles my mind. How can a million dollar web company do this?