True fact. That's just due to scrolling fast enough to get outside the buffer before the throttled scroll event fires -- if you want, you can turn the scroll throttle down to make sure that doesn't happen, at the expense of doing slightly more computation while scrolling. For Wish Lists, we optimize for people browsing through the feeds, which is generally not super fast. :)
In order to calculate the size of each ListItem you add it to the dom briefly when its appended to the ListView. This seems to be a fast operation since you do it hundreds of times yet the page is loading quickly. Is there a trick there that is avoiding having to calculate a ton of layout, or is that just not a big concern compared to other work the browser is doing?
Just one trick, although I use it in both the on and off demos to keep everything fair: I'm adding elements in smaller batches of 70 rows per tick of execution (arbitrary number), and then using a setTimeout to wait a few milliseconds before adding more. The demo loads a tooon of elements upfront -- much more than an ordinary site would -- and Firefox would sometimes complain if I loaded 400 rows of pugs at a single time. Chrome, of course, had no complaints, and IE was surprisingly fine as well.
"...but because there are fewer elements in the DOM tree, relayouts are cheaper as well"
If I understand, this also applies? When I add the 400th (or whatever) ListItem it does trigger a layout when its added to the dom (to calculate its dimensions) but its much faster due to only having the currently viewable ListItems contained in the ListView?
