3 ms·
Some comments suggest this is as a result of A/B testing, which may be part of the story today, but as someone who built websites that had to deal with returnin
by jqcoffey 5y ago
Some comments suggest this is as a result of A/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.
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.
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/B tested the arrangement and found that it was happily optimal.
- nitwit005 5y agoSimilar issue with smartphones. They used to basically crash when faced with a large table. I assume the low end devices will still struggle.