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.

[1]: https://github.com/emberjs/list-view

CodeMirror does it on the web since version 2, somewhen in 2011. http://marijnhaverbeke.nl/blog/a-pathological-scrolling-mode... is the most recent explanation. I'd be surprised if there weren't earlier implementations of the idea.

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.

Android's ListView also is built around view recycling. But these are both situations where the framework supports the recycling.

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.

Cool ... I knew I was passed back a "convertView" sometimes but didn't realize it was recycling them.

Adobe Flex had the same model and it worked quite well (despite the framework's other flaws).

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.

Stored in the data model; the memory issue is a rendering one (not a hard drive capacity one)

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.

Adobe's Actionscript did the same thing with their lists. Each list item was reused when it scrolled off the top/bottom with different data.

And I thought my DOMbuffer idea would be new. Did you investigate yourself or did Google publish some technical papers about Wave ?

ps: reminds me of Google Maps tiles.

I also wonder about "memory problems", but of the soft kind. I like to consuming "pages" of content at a time, spread between many tabs. Usually I read to the bottom of a "page", and then switch tabs. When I come back to that tab, I'm ready to go to the next page.

But with infinite scrolling, I feel like I'd be re-reading content to find my exact spot I left off..

Agreed.

Remember the old printers, and how the paper had holes on the sides, and was just one continuous sheet? Imagine if magazines were printed that way, so you didn't flip pages, but instead you just kept folding back a part of the endless paper and reading on.

That's how I feel with infinite scroll. I like flipping magazine pages like I enjoy clicking links. I don't know what it is exactly, it just feels more natural, and organized.

There are exceptions though. If I'm using an iPhone, endlessly scrolling through my inbox, or song list (with the ability to tap to a particular letter), works incredibly well. Then again, touch screens in general feel great with infinite scroll. It's a tricky situation, and really depends on the device and content.

Isn't that sort of what the OP is attempting to solve? It's paginated but still scrolls infinitely.

I guess not, although the page number is shown for you to see which page you are on, but you may forget where you were after you visit a particular link. It's improved to resolve the memory issue, I think. So when you browsed to page 10 and want to get back to page 3, it will reload for you seamlessly, rather than let the browser to keep all the pages in memory.

I agree the parent post, I'd like to keep where I was when I open each link in a new tab. Then the infinite scroll just helps to eliminate the click of the next page.

That's a problem that can be solved by paginating the data and using the history api to push the page state on the stack while the UI seamlessly loads the pages together.

Which it actually does. Look at the URL.

I feel with tumblr it's the combination of gifs and infinite scroll that makes it crap out. It's a far nicer experience appending /mobile/ to a tumblr url.

There is a paginated mode in the settings, which is a total godsend. I dread the day when Yahoo decides to remove it.

When you're loading more elements at the bottom - drop the equivalent count of elements from the top of the list. Problem solved.

The memory issue is solved, but the browser and CPU are so busy because when you want to get back to page 3 from page 10, page 3 has to be reloaded.

grid virtualization for the web has been around for a long while with things like slickgrid/extjs (google docs is a great example), maybe there's a good open source project opportunity in writing a virtualized+paginated+history friendly infinite scroll

I've thought about this before - where you have a 2D array of images with infinite scroll in all directions.

You need to track the scroll position, and kill the elements that are scrolling away as you create the new elements in the direction you are scrolling - with the entire purpose of creating enough cached images so that it is seamless to the user.

The problem is that the scroll position changes back when you kill the old elements, so you need to keep a running tally of the matrix somewhere to track the user's position.

You could solve a lot of problems with position: absolute and javascript, which you assume is on.

A bigger problem is that mobile safari doesn't let you execute js during scroll. One way around that is by hsing iScroll which fakes scrolling using CSS.

That's right: a) you don't get scroll events until the scroll has finished, b) you do get touch events that drive the scroll (but nothing during the inertial part), c) the appearance of the page is not updated until the scroll has finished.

You can get around this by using programmatic scrolling (e.g., iScroll, zynga-scroller) but you'll never get quite as nice scrolling as with the native behaviour.

You can use the touchmove event to do things while mobile safari scrolls.

Really?

http://stackoverflow.com/questions/10482227/javascript-dom-c...

Looking back at the code that I was thinking of, it looks like I was using requestAnimationFrame to do the actual DOM manipulation (based on a variable that was updated in touchmove). Maybe Mobile Safari still allows DOM manipulation during those animation frame callbacks, even if touchmove is happening?

I suppose that’s the way most maps operate: loads map tiles and anchors current viewport properties in URL. Difference is that there is no 'real scroll position with real scrollbar'.