9 ms·

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 brow

• smoyer 13y ago
  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.
  • jakub_g 13y ago
    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?
    • smoyer 13y ago
      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 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).
      • keehun 13y ago
        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.
        • yincrash 13y ago
          Android's ListView also is built around view recycling. But these are both situations where the framework supports the recycling.
          • smoyer 13y ago
            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?
            • RyanZAG 13y ago
              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.
              • smoyer 13y ago
                Cool ... I knew I was passed back a "convertView" sometimes but didn't realize it was recycling them.
        • calinet6 13y ago
          Adobe Flex had the same model and it worked quite well (despite the framework's other flaws).
        • kackontent 13y ago
          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.
    • ivanca 13y ago
      Stored in the data model; the memory issue is a rendering one (not a hard drive capacity one)
  • _greim_ 13y ago
    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.
    • bassclef 13y ago
      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
    • DonPellegrino 13y ago
      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.
  • agumonkey 13y ago
    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.
  • _frog 13y ago
    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 https://github.com/emberjs/list-view
    • barrkel 13y ago
      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.
    • cben 13y ago
      CodeMirror does it on the web since version 2, somewhen in 2011. http://marijnhaverbeke.nl/blog/a-pathological-scrolling-model.html 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.
  • dalore 13y ago
    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.
  • invisible 13y ago
    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.
• bduerst 13y ago
  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.
  • EGreg 13y ago
    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.
    • Encosia 13y ago
      You can use the touchmove event to do things while mobile safari scrolls.
      • EGreg 13y ago
        Really? http://stackoverflow.com/questions/10482227/javascript-dom-changes-in-touchmove-delayed-until-scroll-ends-on-mobile-safari/10856671#10856671 http://stackoverflow.com/questions/10482227/javascript-dom-c...
        • Encosia 13y ago
          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?
    • mikaraento 13y ago
      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.
• solve 13y ago
  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..
  • Already__Taken 13y ago
    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.
    • Filligree 13y ago
      Which it actually does. Look at the URL.
  • chc 13y ago
    Isn't that sort of what the OP is attempting to solve? It's paginated but still scrolls infinitely.
    • dclara 13y ago
      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.
  • User8712 13y ago
    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.
• btbuildem 13y ago
  When you're loading more elements at the bottom - drop the equivalent count of elements from the top of the list. Problem solved.
  • dclara 13y ago
    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.
  • feralmoan 13y ago
    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
• navs 13y ago
  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.
  • Grue3 13y ago
    There is a paginated mode in the settings, which is a total godsend. I dread the day when Yahoo decides to remove it.