TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Ask HN: Why are developers so stingy with “rows per page”?

72 点作者 quiffledwerg超过 3 年前
Why the heck am I usually allowed only 20 or 50 or maybe 100 rows per page with whatever I’m looking at?<p>Is there some sort of shortage of CPU time?<p>Why not all me to see 500 or 1000 rows per page so I can scroll through the things you’re trying to sell me without needing to press “next” every 5 seconds?<p>Developers please, there’s no shortage of “rows”. Give us more.

22 条评论

dusted超过 3 年前
As a non-designer developer, I&#x27;m going to say this is dictated by UX designers and has no technical merit. My preference trends towards &quot;put about 10k rows into the browser and let the user use ctrl+f to find what they&#x27;re looking for&quot; which is probably also wrong for all sorts of reasons.<p>Only thing worse than pagination is infinite scrolling.
评论 #29341577 未加载
评论 #29342646 未加载
评论 #29343513 未加载
评论 #29345872 未加载
评论 #29342114 未加载
评论 #29344565 未加载
评论 #29352557 未加载
评论 #29341675 未加载
DavidPP超过 3 年前
From a UX, perspective, Nielsen Group is a good reference: <a href="https:&#x2F;&#x2F;www.nngroup.com&#x2F;articles&#x2F;infinite-scrolling&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.nngroup.com&#x2F;articles&#x2F;infinite-scrolling&#x2F;</a><p>For your question specifically, the following explain it well I think:<p><i>..locating a previously found item on an extremely long page is inefficient, especially if that item is placed many scrolling segments down. It’s much easier for people to remember that the item is on page 3 than it is to gauge where the item is positioned on an extremely long page.</i>
评论 #29343715 未加载
评论 #29345769 未加载
评论 #29346798 未加载
评论 #29346850 未加载
评论 #29361901 未加载
muzani超过 3 年前
In my experience, it&#x27;s the query time. Maybe it <i>should</i> be faster, but practically, with all the tech debt that goes into these things, it&#x27;s not. I&#x27;ve actually experimented with different sizes for a social media app (meaning it queries total reacts, shares, etc) and 15 was close to optimal.<p>Latency is not an issue, and neither is displaying complex information. You can pull and display 400 dummy items no problem.<p>Loading time for the first &quot;page&quot; is extra valuable - you&#x27;d want that in 200 ms or so ideally. So one trick is load 3 items, then 30 or so.<p>Also you have to look at actual cost. Perhaps loading an extra 15 queries on the home screen costs $0.0004, but when you have 1m daily active home page uses, that&#x27;s an extra $400 per day. In unoptimized pieces of code, the cost could well be 20x higher.<p>If you have a very high average user value like Jira, that&#x27;s fine. But for say, a free manga site or something like imdb, you want to shave off costs wherever possible.
评论 #29347055 未加载
al2o3cr超过 3 年前
Because there&#x27;s no point in loading 500 rows from the database if 90% (made-up stat) of people don&#x27;t read past the first 10.
评论 #29346045 未加载
jqcoffey超过 3 年前
Some comments suggest this is as a result of A&#x2F;B testing, which may be part of the story today, but as someone who built websites that had to deal with returning large resultsets from time immemorial (i.e. pre-dot com bubble), it absolutely started because Netscape would simply blow up rendering tables larger than N rows (where N ain’t very large) and because partial rendering didn’t work very well with table based layout. The former meant you could crash a viewer’s browser while the latter meant anything more than say 20 rows would take eons to load over a dialup modem.<p>This all changed with the advent of infinite scrolling enabled via the whole ajax revolution, but this was (is still? I haven’t written front end code in a decade or so) difficult to get right.<p>In sum, this happened because of technical difficulties on the front end side (browser limitations or code complexity), and probably just stuck as convention. Perhaps some nice analyst then A&#x2F;B tested the arrangement and found that it was happily optimal.
评论 #29343640 未加载
leros超过 3 年前
There is a psychological aspect too. Show people 10 results and they&#x27;ll actually look at them. Show people 100 results and they&#x27;ll not only quickly scroll through them but also skip the top results, which is counterproductive.<p>The big sites have definitely AB tested changing the results per page and have stuck with 10 for some user metric driven reason.
Raed667超过 3 年前
- Query time: Developers are very squeamish about how long SQL queries take<p>- Payload size: 1000 rows makes the payload huge which adds even more latency<p>- Frontend performance: More modest machines will struggle to render very large dynamic tables of rich content.
评论 #29346294 未加载
评论 #29342773 未加载
评论 #29344808 未加载
评论 #29341493 未加载
rasz超过 3 年前
Because Tables with many rows are SLOW.<p>I have one with 6K rows, 300ms to insert into page on paper (console.time(1); console.timeEnd(1)), but in reality browser freezes for 3 seconds (1.8s style, 900ms layout, 300ms update tree). Freezing goes away with position: absolute, but it still takes 3 seconds to show up after .appendChild. I tried replacing Table with Flex divs, even worse speed.
评论 #29350102 未加载
评论 #29357725 未加载
评论 #29349219 未加载
cblconfederate超过 3 年前
My bank does that. Want to print your monthly transactions? There you go. Oh no, it&#x27;s just the first 10 rows with infinite scroll. Scroll, again and again and again, just so you can print to pdf.<p>The worst i ve seen is in Bluehost&#x27;s domain management pages. An unsorted list of domains with infinite scroll where you have to scroll, scroll and scroll hoping that your domain will be in the next block that pops up (because, of course they keep all your long abandoned domains in the list). And they do it again in their DNS Zone file editor. It will only show you the first 10 or so lines of each section, so naturally you think lines are missing and try to re-enter them. The comparison with the plain old CPanel interface is mind boggling. I have complained, they don&#x27;t listen<p>Progress!<p>I wonder how i can start a campaign to legally ban infinite scrolling
nickjj超过 3 年前
I like the idea of geared pagination <a href="https:&#x2F;&#x2F;github.com&#x2F;basecamp&#x2F;geared_pagination" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;basecamp&#x2F;geared_pagination</a> which is another gem out of Basecamp.<p>Their philosophy is to show less initially but as you start paging through additional pages it&#x27;ll show more results per page until you hit a maximum amount. For example you could get 25 results on page 1, 50 on page 2, 100 on page 3, etc..<p>It&#x27;s a happy medium. Keep your initial result minimal and focused but if a user wants more then keep giving them more in an efficient way (less clicking).
AlchemistCamp超过 3 年前
It&#x27;s interesting to see this. I feel the same way, hate card-based layouts and generally want more information density (i.e., HN or old Reddit) as opposed to what&#x27;s often done now.<p>I intentionally put <i>all</i> of my Elixir screencasts on a single page without much whitespace on Alchemist Camp (<a href="https:&#x2F;&#x2F;alchemist.camp&#x2F;episodes" rel="nofollow">https:&#x2F;&#x2F;alchemist.camp&#x2F;episodes</a>). I can&#x27;t think of a single employer who would have been cool with that design choice, but I frequently get emails and comments from people thanking me for it.
alex_c超过 3 年前
I&#x27;m positive this is usually due to convention, not a conscious design decision. In other words: websites give 20&#x2F;50&#x2F;100 row pagination options because other websites give 20&#x2F;50&#x2F;100 row pagination options.<p>There is no meaningful implementation difference between providing 20&#x2F;50&#x2F;100 options and 20&#x2F;50&#x2F;100&#x2F;500 options, with 20 as the default in either case.<p>I would be very surprised if this decision is even discussed for more than 1 minute on most projects, let alone if any user research is done. But I&#x27;m happy to be proved wrong!
评论 #29342653 未加载
brundolf超过 3 年前
On the web it can definitely become a performance constraint, unfortunately. Frameworks can fold under even this number of rows if you&#x27;re, for example, re-rendering your entire VDOM tree on every keystroke in an input field. This part can be optimized around fairly easily if you know how, but then the next barrier is number of DOM nodes (specifically, the layout calculations that may have to be done on them when even something seemingly unrelated on the page changes). Depending on the complexity of your rows and what else may be going on on the page, you&#x27;re probably still confined to the triple-digits if you want smooth performance.<p>Source: I spend a couple years wrestling constantly with these sorts of problems in a React-based toolset we were developing.<p>One strategy I&#x27;ve used before to improve the user experience and help people miss Ctrl+F less is to load the full data set into <i>memory</i>, even if only a small slice of it is actually rendered at a time, and then do all paging&#x2F;searching&#x2F;sorting&#x2F;filtering client-side. JavaScript has no issue handling six digits of items this way, and it keeps things really snappy.
评论 #29347384 未加载
wodenokoto超过 3 年前
If there is a shortage of cpu time, then please use pagination instead of dynamically loaded infinite scrolling.<p>I hate how so many websites manages to break the back button.
Gravityloss超过 3 年前
Yes, search facilities on pages are usually not great, it&#x27;s easier to show the raw data and use browser search...
fiedzia超过 3 年前
1000 products could mean 1000 images to show and 1000 templates to render and that may kill your browser (definitely true on a phone), and significant slowdown even on a desktop&#x2F;laptop. The solution is simply to load more data as you scroll. This should be fast enough for you not to even notice it.
landryraccoon超过 3 年前
CPU time is cheap, human attention is not.<p>I would not assume most users want a lot of choices. Perhaps choosing from a list of 5-10 options is much less intimidating than choosing from 100. If someone clicks next page, then maybe the calculus changes.
tryauuum超过 3 年前
(I am not a real lawyer) but I think it&#x27;s just little more complex to program. CPU time issues don&#x27;t matter much, we can design around that.<p>If we pull, say, 1000 rows in the foreground, you have to keep in mind when designing UI that you have to wait for data. E.g. you have to design some sort of indication that data is not yet 100% loaded if user tries to search something in page.<p>Another point is that (maybe, I have no experience in UI design) that users favor fast loading page, even if it only has 10 rows..
评论 #29342562 未加载
schwartzworld超过 3 年前
A good search ui should allow you to specify number of hits, imo. But 1000 would present technical problems. I&#x27;m most experienced with React and it would be difficult to render that many rows of anything in a useful way.<p>Additionally, depending on how your backend is designed and your choice of ORM, sometimes requests can be slow. In those cases it probably makes sense to design a UI that encourages users to rely on search and filter controls vs giving them a large list.
评论 #29347063 未加载
DwnVoteHoneyPot超过 3 年前
If there is advertising revenue involved, then the pagination is all about hits. Each page load is an opportunity to serve more ads.
gitgud超过 3 年前
Depends what you&#x27;re displaying, js frameworks can struggle to show 1000&#x27;s of rows smoothly, especially if a row is displaying computed data.<p>So, a lot of the time, developers will just limit the page size, in order to guarantee performance on majority of devices...
codingclaws超过 3 年前
It&#x27;s mainly out of respect for the user&#x27;s bandwidth. For example, if they&#x27;re on a 2GB phone plan, then 500 records could drain a significant % their monthly allotment.