Google's Wave used (and reused) a fixed number of DOM elements that were filled by fly-weights containing the data to be shown on that page. While the scroll bar showed the appropriate position in the thread, there was a limited amount of data for the items above and below the visible set, and an even more limited number of DOM elements that could be filled with data.
Wave didn't strike me as the most performant of client-side webapps, but certainly may have been ahead of its time in terms of what it was trying to do. I wonder if browsers could make this sort of thing easier, or even automatic. Querying the positions relative to viewport of elements on scroll is expensive, even using throttling.
My friends and I were heavy Wave users back in college. It was simply the best tool available by combining chat, Google docs and forums into a single tool. It was slow at first, but after the first 6 months of improvements it became progressively very responsive.
That's actually very interesting. The UIKit framework that powers most iOS apps uses a similar approach in its collection and table view classes, which is one of the reasons that scrolling managed to be so smooth even on the limited hardware of the original iPhone.
Ember.js similarly has Ember.ListView[1] which was the first implementation of that idea I'd seen on the web. I had no idea that Google Wave had beaten them to the punch by so many years.
Native frameworks have historically drawn on demand, with a bit blit for the unchanged scrolled bit and as little drawing as possible into the newly exposed area - with or without double buffering, depending. And this on hardware far, far less powerful than the original iPhone.
That's interesting. So whenever I scrolled a lot down, and wanted to scroll to the beginning, the related data was re-fetched? Or it was stored in the data model, but just not displayed in the DOM?
I think the message tree was stored in its entirety assuming it wasn't too big. But each of these messages was significantly smaller than the memory footprint of the DOM element in which they would have been displayed. The efficiency of putting new content into a DOM element at the bottom of the list (below the visible content) and reordering it within the parent (so it was at the top was significantly faster than deleting that bottom DOM element and adding a new child element at the top.
Give me a few minutes and I might be able to find the Google I/O talk where this was described ... Wave used GWT to generate its Javascript but it's a great technique for browser-based clients regardless of how you end up with your Javascript.
The method of "recycling" DOM elements is described in minutes 20-25 of this video: https://www.youtube.com/watch?v=T_CLzgEL7FA. I can't find the reference, but I also remember hearing that they used some preloading to make other operations on the screen react much faster (e.g. loading the first 25 messages for each wave headline in the list).
I mean, this is just like how Apple implements its NSTableView. You have a datasource and you implement the table's data source delegates. NSTableView itself takes care of the whole reusing views thing.
Is it? I was going to add it to the list, but the Adapter that manages the data actually generates (and caches) a View for each element. Is there something I'm not understanding?
Yep it is. The Adapter will generate and cache a view for each item - but once the view moves off the screen, the adapter will reclaim/recycle that view, and the next item to request a view will be given the recycled view. In effect it is identical to the ios or flash list model.
It's basically a common pattern when it comes to UI for the lists, I remember MFC had it like a hundred years ago and I bet they weren't the 1st to do it this way.
We do this at Grooveshark for song rows. Pretty fast but it could definitely use some optimizations by the browser since we still have to hit the DOM a lot to update the divs.
