Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google’s suggestion for a better infinite scroll?

scrollsample.appspot.com

Post reply on HN
Print view View original

161–168 of 168 posts

Re: Google’s suggestion for a better infinite scroll?

#161

Post by invisible »

smoyer wrote: post #62
jakub_g wrote: post #59

I would feel kind of okay with infinite scroll if it wasn't creating memory problems. Especially on image-heavy (tumblr) / DOM-heavy (facebook) pages. If I browsed the web in 90s mode (one window, one page opened) that would maybe work, but when I have dozens of tabs opened, youtube playing in background and I start browsing an endless memory-hungry page, my laptop (3 GB RAM) starts dying. Another issue is the one me…

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.

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.

Re: Google’s suggestion for a better infinite scroll?

#162

Post by feralmoan »

btbuildem wrote: post #78
jakub_g wrote: post #59

I would feel kind of okay with infinite scroll if it wasn't creating memory problems. Especially on image-heavy (tumblr) / DOM-heavy (facebook) pages. If I browsed the web in 90s mode (one window, one page opened) that would maybe work, but when I have dozens of tabs opened, youtube playing in background and I start browsing an endless memory-hungry page, my laptop (3 GB RAM) starts dying. Another issue is the one me…

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

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

Re: Google’s suggestion for a better infinite scroll?

#163

Post by bassclef »

_greim_ wrote: post #108
smoyer wrote: post #62

Earlier quoted context omitted.

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.

Wave was so awesome and so bad at the same time. We had hundreds of people sharing phish music in a wave and the performance got so bad to unusable

Re: Google’s suggestion for a better infinite scroll?

#164

Post by DonPellegrino »

_greim_ wrote: post #108
smoyer wrote: post #62

Earlier quoted context omitted.

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.

Re: Google’s suggestion for a better infinite scroll?

#166

Post by fiatjaf »

bhrgunatha wrote: post #96
fiatjaf wrote: post #80

Earlier quoted context omitted.

This reminds me of Gabriel García Marquez's novel _The Autumn of the Patriarch_, which has no paragraphs and infinitely long sentences.

That's a great analogy - hwo did you find reading that book? I love his other books, but Autumn of the Patriarch took a LOT of mental effort.

I've only read Chronicle of a Death Foretold and Memories of My Melancholy Whores from him, I started The Autumn of the Patriarch, but I couldn't bear it and gave up the book early.

Re: Google’s suggestion for a better infinite scroll?

#167

Post by Ryel »

Infinite scroll is about making it as seamless as possible for the user to get new information.

How many times do you go on a paginated page, get to page 5 and say "okay, after page 6 I'm done." Then you either leave or continue on that process...

Infinite scrolling takes away your perspective of exactly how much content you're consuming and how much time you may be wasting. It is only until youre done and you attempt to scroll back up that you realize how much time youve spent.

My side-project now is very much like Tumblr/Pinterest and I found this post interesting because for awhile ive been trying to find the best middle-ground between infinite scrolling and some form of incremental, pagination-styled display of content.

Honestly I'm stumped but for right now my best solution is to load about 20 items, lazy load another 30, and use pagination for the rest. Although I've been thinking about just displaying an infinite scroll toggle switch on the bottom of the viewport after the user reaches the end of the initial item list.

Re: Google’s suggestion for a better infinite scroll?

#168

Post by cben »

_frog wrote: post #143
smoyer wrote: post #62

Earlier quoted context omitted.

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.

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 th…

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.
Post reply on HN