3 ms·

Am I the only one feeling the author is speaking completely in his personal bubble? While he might find 3170-3179 not useful, there might be some people that d

Am I the only one feeling the author is speaking completely in his personal bubble? While he might find 3170-3179 not useful, there might be some people that does, and having it there barely affect anything else at all. Meanwhile his sql queries are assuming that businesses that build pagination use relational db exclusively. Highly scalable nosql db is a thing and if I were to bet most popular paginated calls would be built from such.

lukaseder 7y ago
This is not at all related to RDBMS. You would still prefer keyset pagination in a "highly scalable" nosql database. Meanwhile, I'll wait for that convincing example of where "some people" want to find 3170-3179 useful.
- adventured 7y ago
  The author is broadly arguing against this style: 1 2 3 ... 315 316 317 318 319 ... 50193 50194 That style is in fact extremely useful if you want to jump multiple pages ahead faster, or work backwards faster, rather than one at a time. And I'd argue that this: < Prev | 1 | 315 316 317 | 50194 | Next > with 3 or 5 results in the center, is the ideal form of that (can optionally drop the prev / next with strong left / right arrowing to compact it further). The example the author gives is intentionally bloated to amplify their point. If I'm on page 1, and want to get to page 13, having multiple numbers in the middle accelerates that process. I can skip to 13 much faster by jumping results rather than going one after another. This is a practical use case and it works well in reverse by enabling you to jump to the end of the results (page 50194) and work backwards quickly through multi-page jumping from the last result, which is great for many types of time-marked content.
  - lukaseder 7y ago
    > The author I am the author ;-) > That style is in fact extremely useful if you want to jump multiple pages ahead faster, or work backwards faster, rather than one at a time It is very easy to jump several pages using keyset pagination. That's just a UX thing to do.
- Aperocky 7y ago
  You’re right about the offset problem, I guess that could be optimized somewhat by caching, then again for google 90% of search likely won’t hit any db at all. Going to the next 10 isn’t as costly as sorting the next 1000. Which is likely why pagination are limited at that. It’s easy to not do offset and tokenize every single entry for a small amount of range and present it as the same kind of pagination.

lukaseder 7y ago

This is not at all related to RDBMS. You would still prefer keyset pagination in a "highly scalable" nosql database. Meanwhile, I'll wait for that convincing example of where "some people" want to find 3170-3179 useful.

adventured 7y ago
The author is broadly arguing against this style: 1 2 3 ... 315 316 317 318 319 ... 50193 50194 That style is in fact extremely useful if you want to jump multiple pages ahead faster, or work backwards faster, rather than one at a time. And I'd argue that this: < Prev | 1 | 315 316 317 | 50194 | Next > with 3 or 5 results in the center, is the ideal form of that (can optionally drop the prev / next with strong left / right arrowing to compact it further). The example the author gives is intentionally bloated to amplify their point. If I'm on page 1, and want to get to page 13, having multiple numbers in the middle accelerates that process. I can skip to 13 much faster by jumping results rather than going one after another. This is a practical use case and it works well in reverse by enabling you to jump to the end of the results (page 50194) and work backwards quickly through multi-page jumping from the last result, which is great for many types of time-marked content.
- lukaseder 7y ago
  > The author I am the author ;-) > That style is in fact extremely useful if you want to jump multiple pages ahead faster, or work backwards faster, rather than one at a time It is very easy to jump several pages using keyset pagination. That's just a UX thing to do.
Aperocky 7y ago
You’re right about the offset problem, I guess that could be optimized somewhat by caching, then again for google 90% of search likely won’t hit any db at all. Going to the next 10 isn’t as costly as sorting the next 1000. Which is likely why pagination are limited at that. It’s easy to not do offset and tokenize every single entry for a small amount of range and present it as the same kind of pagination.