[oneplusone]

Just because people implement them poorly doesn't mean they are inherently bad. Scrolling is easier and more enjoyable than clicking. However, basic features like back/forward remembering your location is vital. And it is probably a good idea to provide some pagination tools even with infinite scrolling.

Discourse does a pretty good job of it. http://www.discourse.org/ or if you just want to try it http://discuss.emberjs.com/t/ember-cli-the-ramcat-way/7666/1...

[cjensen]

Browsers do not and should not have infinite memory. Each time an infiscroll website scrolls down, more memory is consumed. On my iPad1, that's a guaranteed insta-crash for Safari.

What is a crash on an iPad1 is a major slowdown on a netbook. In five years when web pages get even heavier, it'll be a crash on a netbook too.

[bduerst]

Couldn't you use a script to remove elements at the top of an infinite scroll page? Would that remove it from browser memory?

[pbhjpbhj]

This seems like the way to do it. You basically have the browser load in pages of content, keep x pages above the viewport, y pages below ready to scroll on to, then you're holding x+y pages. You remove pages when scrolled far enough past and add pages to keep y-1 pages in hand. The problem then is that a user might scroll through a lot of content and then choose to scroll back - eg if they're sampling for quality first and then selecting on a subsequent pass.

How do pdf viewers handle this wrt memory conservation. If you have a 1000 page pdf, scroll through a couple of hundred pages (using a infinite scroll type view), what does the viewer do with viewed content, it has to cache it somehow, right?

Maybe the infinite scroll needs to be more accomodated by the browsers rather than just not used. I know in certain circumstances (image search, reddit on mobile) that I find it useful.

[pas]

I think PDF viewers cache a low(er) resolution rasterized version of pages. And are simply much faster, because - as far as I know - PDF has rather precise position and dimension data already included, so there are no need for further passes (no reflows).

[dredmorbius]

Oddly enough, there's a way of providing this in a discrete fashion: "next page".

[bgwhn]

Some implementations do this, but then it breaks ctrl+f.

[scott_karana]

Not necessarily... just like how another poster mention's Tumblr's use of empty divs to keep the scrollbar position happy without sucking up resources, couldn't mixed-resource divs be replaced with text-only divs? Then search works fine, and memory still doesn't balloon (much).

Eg:

  <div>Cool meme: <embed>...</embed><img></img></div>

Goes to:

  <div>Cool meme:</div>

Even more work in implementation, admittedly. ;)

[ryanthejuggler]

Thingiverse does this: http://www.thingiverse.com/search/page:1?q=puppy&sa=

Notice that when you scroll, the page value changes, and when you scroll back up, the browser re-fetches the content.

[foota]

This is exactly what tumblr does, it has infinite scrolling on the dashboard and when elements go past the top of the page they get replaced with a div with width and height equal to the post they it is replacing.

[Y-bar]

Yes, removing elements from the DOM will allow browsers to free the memory.

Some site (Tumblr I think) did something like this a while ago where it would do something like this, it was very fluid:

1. When a new section has been appended to the bottom of the page…

2. Calculate the current height if the topmost div and save it explicitly as the div's height…

3. Then remove all content from that div.

4. And when another new section has been loaded and appended do the same thing, but with the second topmost and so on.

[ChristianBundy]

That's The Right Way™ of doing it.

[asdfdsafueu33]

There are plenty of scripts to only display the ones which are visible. They get hidden as they are scrolled off screen.

[pbreit]

They aren't inherently bad but they are inherently easy to misuse and implement poorly. Which actually does support restraint in deciding to use them.

One thing I see frequently which is preposterous is infinite scroll on pages that actually have a footer which is pretty much impossible to access.

[gcatalfamo]

YES! For sometime Facebook had it! I needed to access the FB's dev section and it was like a clicking contest. When they moved it to the right, I had already memorized the website.

[wlesieutre]

Pretty sure Facebook used to do that with the footer.

[joeframbach]

The workaround to get to the "developers" link was to mash the escape key while scrolling. Those were the days.

[cscharenberg]

I am really curious is there is data on "Scrolling is easier and more enjoyable than clicking". That seems like it requires evidence from trials on a variety of different types of webpages. I can imagine if you are browsing visual items like clothing, art, memes, etc the scrolling flow is great. However when reading long documents or forums it may be the opposite.

[acomms]

Agreed - nicely done