5 ms·

It also breaks the find button. The item you wanted to search might get unloaded, or not loaded yet, in some bizarre attempt at optimization when the javascrip

It also breaks the find button. The item you wanted to search might get unloaded, or not loaded yet, in some bizarre attempt at optimization when the javascript library resposible is an order of magnitude larger than the actual content anyway. My phone has gigabytes of memory. If you want to present five hundred items in a web shop, just list them and do not bother with any type of pagination, invisible or otherwise.

spookthesunset 4y ago
Gigabytes of memory yes but there is load time and render time too. And rendering a 120mb payload of items and their thumbnails before I can even view the top of the page seems… not the best user experience. I don’t think there is an easy answer here. All options have some trade offs.
- xorcist 4y ago
  That is not how browsers work. The browser will render the viewport immediately, long before the page has loaded. It will also load the visible thumbnails first, unless made impossible by complicated markup of course. Otherwise surfing the web on dialup in 1996 would have been intolerable.
- _cd 4y ago
  Typically when I serialize data for #index endpoints I return much slimmer payloads than I do in #show endpoints. I recognize that 120mb was an extreme, but you should be able to serialize lists of 500+ items into well under 1mb, with enough data to render your list view thumbnails/links. I always thought the infinite scroll pattern was designed for analytics purposes. So that you can track user engagement. Not because technology constraints necessitated it or that it was a good user experience.
  - NLPlatypus 4y ago
    Just have JS track where the user is?
- shadowgovt 4y ago
  Sooner or later you have to unload content or the browser crashes. There's an upper limit to how many DOM elements browsers can handle, even with modern optimizations.
- jandrese 4y ago
  Deferring rendering of the images seems like an easy enough thing to do if your alternative is infinite scrolling. Pre-load the text and layout but leave the images and video until they're close to the viewport.
Tagbert 4y ago
It also breaks the “back” button. If you click on an item after significant scrolling, view the item, then click back, where are you? almost never where you were. Usually just at the top of the list.
- adhesive_wombat 4y ago
  Jira goes one better. Issues in some lists are paginated into 50s. Change to "page 2", use the back button and you'll be back on the page you were on before looking at the list, because the URL hasn't changed. Go forward again and you're back at the first page. Argh!
  - bartread 4y ago
    Gah! Breaking basic navigation functionality, along with the clipboard, on page search functionality (i.e., basic application and OS level stuff), keyboard navigation, and common keyboard shortcuts and mouse/touch gestures, are amongst the absolute cardinal sins of web applications. These ought to be acceptance criteria for every single "story" implemented that impacts the client-side. Does anybody do it? Well, some, but very few.
- awinter-py 4y ago
  yeah the nielsen article calls this 'pogo sticking'
- notriddle 4y ago
  The back button problem is fixable. Discourse (which you’ll see on discuss.python.org and users.rust-lang.org) uses the history API to keep track of your location. You can create a URL that points at any individual post, and the page will appear “pre-scrolled” to it, so you can not only use the back button to return to your location in the infinite scroll, you can even bookmark your location in the infinite scroll. The scroll bar and find function can be mitigated, but not as elegantly. The real problem is that, when you load a page in the middle, it’s easy to scroll down, but scrolling UP is glitchy. That one can’t be fixed. https://meta.discourse.org/t/scroll-jank-when-scrolling-up/108381 https://meta.discourse.org/t/scroll-jank-when-scrolling-up/1...
dylan604 4y ago
the lack of not being able to find something not yet loaded or recently unloaded is infuriating to me. I file shitty pagination systems with no Show All in the same category.
- spookthesunset 4y ago
  The “find” thing is something I hadn’t considered. Yes it’s annoying when you cant search content “below the fold”
r3trohack3r 4y ago
I do think it depends. I love infinite scrolling for random content. There is no “position” so to speak. And there is no concept of “find” since you don’t know what you’re looking for. “Back” continues to work as long as your browser cached the previous page state. Sometimes you really do want to simulate an infinite list of 4,000,000 entries! An example: https://wikiscroll.blankenship.io https://wikiscroll.blankenship.io
bmicraft 4y ago
I find spotify is really bad with unloading ui, to the point where you have to stop and wait to see song titles if you are scrolling even moderately fast
bastawhiz 4y ago
In fairness, without unloading, it will be slow. Really slow. I never added unloading to a long list in my app, and for lists with thousands of items, Chrome will take seconds to paint on my MBP if you do any vigorous scrolling. It's not about memory use, it's about practical browser performance.
spicybright 4y ago
Idk if this would be better or worse, but there should be a "find on page" js API. Like how the history api is used for SPA's.

spookthesunset 4y ago

Gigabytes of memory yes but there is load time and render time too. And rendering a 120mb payload of items and their thumbnails before I can even view the top of the page seems… not the best user experience. I don’t think there is an easy answer here. All options have some trade offs.

xorcist 4y ago
That is not how browsers work. The browser will render the viewport immediately, long before the page has loaded. It will also load the visible thumbnails first, unless made impossible by complicated markup of course. Otherwise surfing the web on dialup in 1996 would have been intolerable.
_cd 4y ago
Typically when I serialize data for #index endpoints I return much slimmer payloads than I do in #show endpoints. I recognize that 120mb was an extreme, but you should be able to serialize lists of 500+ items into well under 1mb, with enough data to render your list view thumbnails/links. I always thought the infinite scroll pattern was designed for analytics purposes. So that you can track user engagement. Not because technology constraints necessitated it or that it was a good user experience.
- NLPlatypus 4y ago
  Just have JS track where the user is?
shadowgovt 4y ago
Sooner or later you have to unload content or the browser crashes. There's an upper limit to how many DOM elements browsers can handle, even with modern optimizations.
jandrese 4y ago
Deferring rendering of the images seems like an easy enough thing to do if your alternative is infinite scrolling. Pre-load the text and layout but leave the images and video until they're close to the viewport.

Tagbert 4y ago

It also breaks the “back” button. If you click on an item after significant scrolling, view the item, then click back, where are you? almost never where you were. Usually just at the top of the list.

adhesive_wombat 4y ago
Jira goes one better. Issues in some lists are paginated into 50s. Change to "page 2", use the back button and you'll be back on the page you were on before looking at the list, because the URL hasn't changed. Go forward again and you're back at the first page. Argh!
- bartread 4y ago
  Gah! Breaking basic navigation functionality, along with the clipboard, on page search functionality (i.e., basic application and OS level stuff), keyboard navigation, and common keyboard shortcuts and mouse/touch gestures, are amongst the absolute cardinal sins of web applications. These ought to be acceptance criteria for every single "story" implemented that impacts the client-side. Does anybody do it? Well, some, but very few.
awinter-py 4y ago
yeah the nielsen article calls this 'pogo sticking'
notriddle 4y ago
The back button problem is fixable. Discourse (which you’ll see on discuss.python.org and users.rust-lang.org) uses the history API to keep track of your location. You can create a URL that points at any individual post, and the page will appear “pre-scrolled” to it, so you can not only use the back button to return to your location in the infinite scroll, you can even bookmark your location in the infinite scroll. The scroll bar and find function can be mitigated, but not as elegantly. The real problem is that, when you load a page in the middle, it’s easy to scroll down, but scrolling UP is glitchy. That one can’t be fixed. https://meta.discourse.org/t/scroll-jank-when-scrolling-up/108381 https://meta.discourse.org/t/scroll-jank-when-scrolling-up/1...

dylan604 4y ago

the lack of not being able to find something not yet loaded or recently unloaded is infuriating to me. I file shitty pagination systems with no Show All in the same category.

spookthesunset 4y ago
The “find” thing is something I hadn’t considered. Yes it’s annoying when you cant search content “below the fold”

r3trohack3r 4y ago

I do think it depends. I love infinite scrolling for random content. There is no “position” so to speak. And there is no concept of “find” since you don’t know what you’re looking for. “Back” continues to work as long as your browser cached the previous page state. Sometimes you really do want to simulate an infinite list of 4,000,000 entries! An example: https://wikiscroll.blankenship.io https://wikiscroll.blankenship.io

bmicraft 4y ago

I find spotify is really bad with unloading ui, to the point where you have to stop and wait to see song titles if you are scrolling even moderately fast

bastawhiz 4y ago

In fairness, without unloading, it will be slow. Really slow. I never added unloading to a long list in my app, and for lists with thousands of items, Chrome will take seconds to paint on my MBP if you do any vigorous scrolling. It's not about memory use, it's about practical browser performance.

spicybright 4y ago

Idk if this would be better or worse, but there should be a "find on page" js API. Like how the history api is used for SPA's.