5 ms·

IMO pagination is garbage UX, any sane GUI tookit can render more then 100 items on screen. Imagine you text editor or spreeadsheet viewer would have a limit o

IMO pagination is garbage UX, any sane GUI tookit can render more then 100 items on screen. Imagine you text editor or spreeadsheet viewer would have a limit of 100 rows. Sane GUIs don't create all this rows widgets from the start but use smarter techniques. From what I seen this technique is called now "windowing" but I knew it before by the name of "render item recycling"

danShumway 7y ago
> any sane GUI tookit can render more then 100 items on screen Sure, but it's uncommon that I want more than 100 items on a screen in a webapp. Infinite scroll is not an antipattern, but it is something that people should be a little bit cautious of. Users like context and clear anchors -- I like to be able to hit a back/forward button and know where I'll end up. I also like pages to load quickly and not make a ton of background requests on mobile connections, so if I can have an initial page load under a few megabytes at max, and can wait for the user to request data before loading it -- that's sometimes an attractive proposition. Multiple search engines used to experiment with infinite scrolling and virtual rows, and as far as I know, most of the big ones went back to pagination, and I think it's because sometimes pagination is genuinely better UX, particularly when you're scrolling through a long list of blog posts or search results. Of course you can put thousands of elements in the DOM, and you can implement virtual scrolling if you need tens of thousands or millions. But the DOM tree is ultimately meant to be a human-traversable interface, and a <ul> element with several thousand <li>s beneath it is arguably not very traversable. There are no hard rules here and there are a lot of caveats to what I'm about to say -- but I now bias towards avoiding DOM trees that are so big that I couldn't stick the current tree in a text editor and mostly consume its content textually, and that includes on dynamic web apps. The current state I'm displaying to the user should be small enough that the user can wrap their head around it. The fact that React is so slow that you basically need to at least occasionally think about how you're rendering state is a separate conversation.
- TeMPOraL 7y ago
  > Sure, but it's uncommon that I want more than 100 items on a screen in a webapp. Infinite scroll is not an antipattern, but it is something that people should be a little bit cautious of. Having ~100-200 items, I'd damn love to have them all on the screen. It seems like the best option out of the trio of render all, pagination or infinite scroll. Pagination is faster than infinite scroll, infinite scroll is more convenient than pagination, but both make it hard to reliably display data in sequence (as the whole data set isn't loaded immediately anymore) - and more importantly, both break search. However bad and bare-bones searching is in the browser, it's still better than search reimplementations in web apps, because the latter aren't any more sophisticated, and also have limited scope. That's just my opinion, and a point of annoyance with modern SPAs. Most of the time when I have to scroll a lot, or traverse a bunch of pages, all I really want is to be able to CTRL+F for the thing I'm looking for without changing the state of the application.
- simion314 7y ago
  Not all lists have thumbnail with images, it could be a taqble with pure text, I think that doing a single request and grabbing 1000 rows of text and have it instantly accessible is much better then paginating it and doing the Next Page and loading screen etc. I am not talking about infinite data here, but data that fits in one single request, that also fits in RAM but does not fit all at once as rendered DOM elements, so the fix is that the GUI widget for this table is smart and instead of rendering 1000 tables will not do that, will render just the visible part and the a few rows above and under the viewport, when you scroll the data in the table cels is changed and no new DOM elements are created. This should be soemthing that the developer should not think about, in this sane GUI toolkits you just do something like widget.dataProvider =myData; Edit: Also for the case of youtube videos, you don't load "download" the thumbnails, those are just string, a sane toolkit will not load all those thumbnails until you bring them into view. I hate YT implementation, you get 3 rows of video then you scroll wait 2 seconds for next 3 rows to load, scroll again, wait again 2 seconds. You could have loaded the strings for all the videos, then lazy load the thumbnails when needed and skip the step of fetch me the next page of string after the strings arrive now fetch the images for those strings.
- deckard1 7y ago
  > it's uncommon that I want more than 100 items I believe the discussion is GUI items, not what you might consider data items. Look at this current Hacker News page. Each comment, depending on how fine-grained you're counting, looks to have about 5-6 or more GUI components. In your browser viewport you may see a dozen comments. GUI components add up quickly. These are also only the components in view. React, however, is rendering the entire page. Easily hundreds of React components.
  - danShumway 7y ago
    But depending on how they're styled and what animations you're using, React can easily handle rendering out 1000 DOM nodes. To be clear, I don't want to act like it's not a real concern, I've been in situations where the number of DOM elements I was rendering out with React ended up being a performance concern. It's a real thing. Heck, I've been in situations where React's insistence on computing the virtual DOM was a performance problem. One of the downsides of component-based architecture is that it's very easy to get into situations where you're completely pointlessly duplicating effort parsing data multiple times and passing it around between components and mapping it to new lists of data. It's a major weakness for systems like React that encourage you to loosely couple all of your components, even components that are inherently very related to each other. But I think people are underestimating what that component/DOM limit is, even for browsers like IE 11. If you have 100 items on screen, and it's causing the browser to slow down, you'd better be doing something at least somewhat complicated with those elements. You'd better be sticking some SVG charts in there or something. Otherwise I'm going to (perhaps uncharitably) accuse you of overcomplicating your DOM and inserting a bunch of nodes that don't need to exist. If someone wants to try and implement HN in React, they shouldn't be using 5-6 separate React components for a single comment, that's... I don't know how to parse that kind of architecture. I don't want to be dismissive about it, and different people have different approaches to programming -- but I feel pretty strongly that kind of granularity is over-engineering.
    - simion314 7y ago
      Not OC but from my experience because you have some nested DIVs and spans and some other node elements for each data item when you first load your data you get a big hang/freeze because the browsers are still slow at creating this elements, this is a browser issue I think, because most of the time you want to have a big list of similar items there should not be such a giant work of creating and computing similar DOM elements but I assume because of how complex css engine is you get this giant freeze.
renke1 7y ago
Sometimes also called a virtualized list (react-virtualized is a popular implementation). Perfectly fine if keeping a lot items in memory isn't a problem (it rarely is). Of course fetching a lot of data from a backend can be a problem.
nothis 7y ago
>IMO pagination is garbage UX, any sane GUI tookit can render more then 100 items on screen. Well, I guess that's the web in 2020 in a nutshell, lol. What would you do with a list of 100,000 items? Just slowly scroll them out, one by one while your scroll gets faster and faster? At one point, are you just a billion pixels down? What does "scrolling up" even mean down there? Or do we just limit all lists to 1000 items, period?
- simion314 7y ago
  It depends on the application, should we limit text editors to 1000 lines? Should you limit the files in a folder to some number because the ListWidget has a limit of 1000 ? No, the solution is too use our brain and realize that you can open giant log files in a text editor , you can have a list with many items in, this problem were solved already the issue is that HTML was designed for documents not applications and the built-in lists or tables are not optimized at all, where a List widget or DataGrid Widget in other toolkits were optimized. I am not expecting a developer to put some hard work to fix this in his app, browsers or frameworks should do this, I dislike the idea that pagination is good UX as an excuse for "pagination is the cheap solution"

danShumway 7y ago

> any sane GUI tookit can render more then 100 items on screen Sure, but it's uncommon that I want more than 100 items on a screen in a webapp. Infinite scroll is not an antipattern, but it is something that people should be a little bit cautious of. Users like context and clear anchors -- I like to be able to hit a back/forward button and know where I'll end up. I also like pages to load quickly and not make a ton of background requests on mobile connections, so if I can have an initial page load under a few megabytes at max, and can wait for the user to request data before loading it -- that's sometimes an attractive proposition. Multiple search engines used to experiment with infinite scrolling and virtual rows, and as far as I know, most of the big ones went back to pagination, and I think it's because sometimes pagination is genuinely better UX, particularly when you're scrolling through a long list of blog posts or search results. Of course you can put thousands of elements in the DOM, and you can implement virtual scrolling if you need tens of thousands or millions. But the DOM tree is ultimately meant to be a human-traversable interface, and a <ul> element with several thousand <li>s beneath it is arguably not very traversable. There are no hard rules here and there are a lot of caveats to what I'm about to say -- but I now bias towards avoiding DOM trees that are so big that I couldn't stick the current tree in a text editor and mostly consume its content textually, and that includes on dynamic web apps. The current state I'm displaying to the user should be small enough that the user can wrap their head around it. The fact that React is so slow that you basically need to at least occasionally think about how you're rendering state is a separate conversation.

TeMPOraL 7y ago
> Sure, but it's uncommon that I want more than 100 items on a screen in a webapp. Infinite scroll is not an antipattern, but it is something that people should be a little bit cautious of. Having ~100-200 items, I'd damn love to have them all on the screen. It seems like the best option out of the trio of render all, pagination or infinite scroll. Pagination is faster than infinite scroll, infinite scroll is more convenient than pagination, but both make it hard to reliably display data in sequence (as the whole data set isn't loaded immediately anymore) - and more importantly, both break search. However bad and bare-bones searching is in the browser, it's still better than search reimplementations in web apps, because the latter aren't any more sophisticated, and also have limited scope. That's just my opinion, and a point of annoyance with modern SPAs. Most of the time when I have to scroll a lot, or traverse a bunch of pages, all I really want is to be able to CTRL+F for the thing I'm looking for without changing the state of the application.
simion314 7y ago
Not all lists have thumbnail with images, it could be a taqble with pure text, I think that doing a single request and grabbing 1000 rows of text and have it instantly accessible is much better then paginating it and doing the Next Page and loading screen etc. I am not talking about infinite data here, but data that fits in one single request, that also fits in RAM but does not fit all at once as rendered DOM elements, so the fix is that the GUI widget for this table is smart and instead of rendering 1000 tables will not do that, will render just the visible part and the a few rows above and under the viewport, when you scroll the data in the table cels is changed and no new DOM elements are created. This should be soemthing that the developer should not think about, in this sane GUI toolkits you just do something like widget.dataProvider =myData; Edit: Also for the case of youtube videos, you don't load "download" the thumbnails, those are just string, a sane toolkit will not load all those thumbnails until you bring them into view. I hate YT implementation, you get 3 rows of video then you scroll wait 2 seconds for next 3 rows to load, scroll again, wait again 2 seconds. You could have loaded the strings for all the videos, then lazy load the thumbnails when needed and skip the step of fetch me the next page of string after the strings arrive now fetch the images for those strings.
deckard1 7y ago
> it's uncommon that I want more than 100 items I believe the discussion is GUI items, not what you might consider data items. Look at this current Hacker News page. Each comment, depending on how fine-grained you're counting, looks to have about 5-6 or more GUI components. In your browser viewport you may see a dozen comments. GUI components add up quickly. These are also only the components in view. React, however, is rendering the entire page. Easily hundreds of React components.
- danShumway 7y ago
  But depending on how they're styled and what animations you're using, React can easily handle rendering out 1000 DOM nodes. To be clear, I don't want to act like it's not a real concern, I've been in situations where the number of DOM elements I was rendering out with React ended up being a performance concern. It's a real thing. Heck, I've been in situations where React's insistence on computing the virtual DOM was a performance problem. One of the downsides of component-based architecture is that it's very easy to get into situations where you're completely pointlessly duplicating effort parsing data multiple times and passing it around between components and mapping it to new lists of data. It's a major weakness for systems like React that encourage you to loosely couple all of your components, even components that are inherently very related to each other. But I think people are underestimating what that component/DOM limit is, even for browsers like IE 11. If you have 100 items on screen, and it's causing the browser to slow down, you'd better be doing something at least somewhat complicated with those elements. You'd better be sticking some SVG charts in there or something. Otherwise I'm going to (perhaps uncharitably) accuse you of overcomplicating your DOM and inserting a bunch of nodes that don't need to exist. If someone wants to try and implement HN in React, they shouldn't be using 5-6 separate React components for a single comment, that's... I don't know how to parse that kind of architecture. I don't want to be dismissive about it, and different people have different approaches to programming -- but I feel pretty strongly that kind of granularity is over-engineering.
  - simion314 7y ago
    Not OC but from my experience because you have some nested DIVs and spans and some other node elements for each data item when you first load your data you get a big hang/freeze because the browsers are still slow at creating this elements, this is a browser issue I think, because most of the time you want to have a big list of similar items there should not be such a giant work of creating and computing similar DOM elements but I assume because of how complex css engine is you get this giant freeze.

renke1 7y ago

Sometimes also called a virtualized list (react-virtualized is a popular implementation). Perfectly fine if keeping a lot items in memory isn't a problem (it rarely is). Of course fetching a lot of data from a backend can be a problem.

nothis 7y ago

>IMO pagination is garbage UX, any sane GUI tookit can render more then 100 items on screen. Well, I guess that's the web in 2020 in a nutshell, lol. What would you do with a list of 100,000 items? Just slowly scroll them out, one by one while your scroll gets faster and faster? At one point, are you just a billion pixels down? What does "scrolling up" even mean down there? Or do we just limit all lists to 1000 items, period?

simion314 7y ago
It depends on the application, should we limit text editors to 1000 lines? Should you limit the files in a folder to some number because the ListWidget has a limit of 1000 ? No, the solution is too use our brain and realize that you can open giant log files in a text editor , you can have a list with many items in, this problem were solved already the issue is that HTML was designed for documents not applications and the built-in lists or tables are not optimized at all, where a List widget or DataGrid Widget in other toolkits were optimized. I am not expecting a developer to put some hard work to fix this in his app, browsers or frameworks should do this, I dislike the idea that pagination is good UX as an excuse for "pagination is the cheap solution"