Hacker News Reader

Comment by cjensen | Hacker News Reader

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.

View on HN

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

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

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. ;)

That's The Right Way™ of doing it.

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.

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).

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.

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.

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.

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

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

Reply on news.ycombinator.com