• Log In
  • Sign Up
    • When Cake first launched publicly we used infinite scrolling for the feed, but we switched to traditional pagination because we felt it was a better experience overall.

      The problem with infinite scrolling is that it's easy to do it badly and incredibly hard to do well, for a million little reasons. Most websites do it very badly. Twitter is pretty good, but far from perfect. Facebook is...well, let's not talk about Facebook. 😬

      Cake still uses infinite scrolling in conversations because it has a lot of benefits there that (mostly) outweigh the drawbacks, but we stopped using it for feeds because it wasn't worth it there.

      Our infinite scrolling code is by far the most complex code in the codebase. I've personally spent probably hundreds of hours on that feature and I'm still not satisfied with it because there are so many tricky edge cases that can hurt the user experience more than helping it if we're not very careful.

      I have ideas and plans for improving it in such a way that it might become a good fit for feeds, but it will take a lot of time and effort. Right now I think our efforts are better spent elsewhere.

    • This is fascinating! I had no idea that scrolling was such a complex and code-intensive function.

      I’ve noticed how the mobile version of Google Search has “on page” loading of additional search results. Instead of page numbers and ⬅️➡️ buttons to click to load a new page, the mobile version has a “More Results?” button that adds new entries below the existing entries. I think I am more often clicking that More Results to get to page 2 and 3 than I was on the desktop.

      @cvdavis noticed a similar behavior with his junior high students last month.

    • This is fascinating! I had no idea that scrolling was such a complex and code-intensive function.

      Loading more data as the user scrolls (or when they click a "More Results" button) is the easy part! The hard parts are almost everything else. 😉

      Stuff like:

      - When the user scrolls through several pages of items, clicks a link to a different page, and then clicks the browser's back button, we need to take them back to exactly where they were in the list. Almost all websites get this wrong and just take you back to the first page as if you hadn't scrolled.

      - When someone clicks on a link to a specific post in a conversation, we need to scroll them directly to that post and also load several posts before and after it. But we shouldn't try to load all posts before it, because it might be post 500 in a very long conversation.

      - While loading posts before the post a user is looking at, we have to estimate the amount of space those posts will take up on the page so that the browser's scroll bar indicates roughly the right position even before they've been loaded. But we don't actually know how much space they'll take up yet because they haven't been loaded yet!

      - When we render posts before the post a user is looking at, the difference between our estimate of their size and their actual size could cause the post the user is looking at to jump up or down on the page, so we have to quickly adjust the scroll position to compensate so that the user hopefully doesn't notice any change. This is surprisingly difficult.

      - Search crawlers like Googlebot don't scroll like a human does when they visit a page to index it for a search engine, so we have to also support a non-infinite fallback mode to ensure that search bots can paginate by clicking links instead of scrolling. Otherwise they'd never see content beyond the first page.

      - As the user scrolls down, we also need to unrender (or hide) the content they've scrolled past in order to avoid using up too much memory as we add more items to the page at the bottom. So at any given time, we're only rendering the content the user can actually see as they scroll. But this breaks the browser's "Find in this page" functionality if the user wants to search for something on the page, because the browser can only search content that's actually rendered, and we aren't rendering content the user can't see.

      ...and many, many more. 😅