Screw Hashbangs: Building the Ultimate Infinite Scroll

http://tumbledry.org/2011/05/12/screw_hashbangs_building

by hung • 15 years ago

214 48 15 years ago

Entlin3• 15 years ago

This breaks the back-button for me, despite the author claiming otherwise.

Steps to replicate: 1. Visit article 2. Click on logo to go to the home page 3. Scroll down until more content gets loaded 4. Click back button

Expected behaviour: Get moved back to the article page Encountered behaviour: Still at front page, scrolled to the middle.

Using Safari 5.0.5, OS X 10.6.7

hung• 15 years ago

I noticed that on Chrome in Snow Leopard, too. Guess it needs a little more tweaking!

windsurfer• 15 years ago

This seems like intended behavior. You back button is not broken. Clicking back brings you back to the previous page... that page just happens to seem to be part of the current page.

For you, it would seem best to remove the previous page content when adding the new content. That way pressing "back" will be super fast, page loading will be fast, and the web will still be happy.

Entlin3• 15 years ago

Well then that's bad intended behaviour. The back button should reverse the loading of a new page after clicking a link. It should not interfere with scrolling at all.

amadeus• 15 years ago

It's interesting that there is no mention of BFCache anywhere in this article. This is one of those fantastic features that (although unfortunately not supported in Chrome) allows for very simple infinite scroll and use of the back button.

Unfortunately this guy's script takes it a little too far for browsers that DO support bfcache and unfortunately breaks functionality a bit, or at least makes it confusing, despite it being intended functionality or not.

cheez• 15 years ago

This guy is not in computer science and knows more than me about this stuff.

I quit.

zachrose• 15 years ago

None of this is really "computer science" though, right?

guynamedloren• 15 years ago

So what is it?

unicornporn• 15 years ago

And he has "noindex, nofollow" for his site. Kind of humble tumbledryer.

ZoFreX4• 15 years ago

Humble and ensuring I won't be able to find this page again in 2 weeks :(

jpeterson• 15 years ago

What?

redthrowaway2• 15 years ago

I'm curious as to why large content websites (gawkmedia) are moving towards hashbangs, as they completely destroy any ability to share a link to an article, which one would think is a fairly big traffic driver for these sites. Maybe gawkmedia's implementation is just broken, but it's a trend I've seen in several places now, with nothing good coming from it.

pohl2• 15 years ago

they completely destroy any ability to share a link to an article

In what way do they do this? If implemented correctly, the URL fragment will uniquely identify the piece of content just the same as if the information were placed to the left of the hash.

Perhaps you don't trust that it will be implemented correctly, but I think we crossed that bridge long ago with the invention of script-generated server-side content. Servlets, perl scripts, php scripts, etc. have been breaking links to content for quite a while now.

Would you also say that cgi-bin scripts "completely destroy any ability to share a link"?

redthrowaway2• 15 years ago

They seem to have fixed it now, but for months on end any link to an article with a hashbang in the URL would instead bring you to the frontpage of any gawkmedia site. The way they fixed it? Ditch the hashbang.

Incompetence anywhere will break things, but when the only clear case in favour of hashbangs (that I've heard of) is infinite scrolling, it's time to look at better ways of doing it. You would hope that Google would have finally figured out by now that they should be making urls prettier, not googlier.

voidfiles2• 15 years ago

If implemented correctly using the hash bang method can increase the amount of articles people read per visit. For every article a user reads they also get more advertising. It's a clear win for gawker if people read more content.

Faster because each article the browser has to load after the first one is smaller then a whole page load.

Unfortunately, gawker failed at the technical implementation in spectacular fashion. Though, they do seem to be turning the ship around.

benologist• 15 years ago

If your site is designed correctly the non-content crud isn't a massive burden for the user to download it's just some small portion of a gzipped total, and assets are cached after the first view.

SoftwareMaven2• 15 years ago

I don't go to gawker sites because they aren't worth turning on javascript for, and their sites are broken without javascript.

Horrible, horrible implementation.

c4urself• 15 years ago

for someone studying for another major: he writes _really_ well about front-end dev

citricsquid• 15 years ago

I don't understand why anybody should be surprised about this.

True story, degrees are a meaningless measure for skill or ability in a specific field.

mortenjorck• 15 years ago

We’ve spent years trying to clean up our URLs and make them semantic by managing mod_rewrite, readable slugs, and date formatting. Now, we take a step backward, forcing the average internet user to learn another obscure set of symbols that make URLs harder for them to parse.

I suppose this was all discussed to death around the rollout of NewTwitter, but it bears repeating.

spc476• 15 years ago

Very neat. I implemented a similar structure for my blog (described here: http://boston.conman.org/about/technical.html) but never thought of connecting it to an infinite scroll.

mark242• 15 years ago

The correct title for this article should be: "Screw IE: Building the Ultimate Infinite Scroll for Webkit/Moz".

I would love to drop hashbangs and use pushState. I really would. However, IE is 50% of my site's audience, and maintaining two fairly disparate codebases to support pushState doesn't make a whole lot of sense, priority-wise.

Ruudjah• 15 years ago

I hate infinite scroll. It delutes the hints of m scrollbar height to know how much info is given.

aperiodic• 15 years ago

I agree. It makes web browsing a Sisyphean task, and I always feel on-edge when I'm reading such a page.

awj• 15 years ago

Pretty sure his regex is off, or at least sensitive to breaking from someone monkeying with the url. Something like /pages/01-/ will match and possibly end up triggering "fetch a page range" logic on null data.

Instead he probably wants:

/pages?/([0-9]+)(?:-([0-9]*))?/?/$

The ?: part is to ignore the capture on that -, which is only really being used to group the dash and the numbers together and make the whole group optional. The other nice part is now you have either one piece of match data (the first number) or two (first and second number) so it's both "more correct" and more programmer-friendly.

Would love to know if there's a better way to ignore capture on a group that's only there to make something conditional.

verisimilitude2• 15 years ago

After 2 years of reading Hacker News, I'm happy to finally have been able to contribute something to the discussion here.

To those who hate infinite scroll: I totally understand. I just wanted to try my hand at making a better version.

There's been some concern about my use of window.onpopstate to "un-add" the nodes infinite scroll added instead of just leaving the entire page for the referring page. I hadn't thought about the potential to essentially trap people on the page as they use the back button to navigate through the history stack their scrolling added. I really didn't mean to screw things up for people! I might want to remove that "feature".

brown9-2• 15 years ago

I thought this was very well-written, thank you.

ZoFreX4• 15 years ago

Really nicely done, works wonderfully. Pity updating the address bar doesn't work in many browsers yet. One request: Could you try experimenting with deleting old pages when you scroll really far? Infinite scrolling takes a pretty heavy toll on my netbook.

thomasfl• 15 years ago

That's just great. Alex has managed to find a way to use window.onpostate to hijack the back button.

tlrobinson• 15 years ago

This post motivated me to figure out how to hack pushState support into NewTwitter:

    twttr.secrets.html5Routing = true;
    twttr.router._changeUrlAndCallAction = function(p) {
        return twttr.Router.prototype._changeUrlAndCallAction.call(this, p.replace("#!/", ""));
    }
    twttr.router._changeUrlAndCallAction(window.location.hash);

Turns out they already have pushState() support... but it uses fragment URLs. This code just enables it, and wraps one of the functions to strip the "#!/".

https://gist.github.com/996381

phoboslab• 15 years ago

Losing the hashbang and instead using history.pushState() to update the URL won't solve the problems that infinite scroll introduced.

Also, the idea of using a page range (e.g. /pages/1-3/) will only preserve which "pages" were loaded when you pass on the URL. It does not state which "page" you actually want to link to. This solves a problem that no one had - I don't care how many pages you had loaded in your browser when you pass me a link.

Here's a slightly different approach to infinite scroll that, imho, works reasonably well: (NSFW) http://www.pr0gramm.com/

ZoFreX4• 15 years ago

I think you have different problems with infinite scrolling to the one the author has solved. For the end user, almost all infinite scrolling implementations break the back button completely, and those that don't have horrid usability issues - this is the first one I've seen that just works.

The page you linked to doesn't avoid this issue entirely - when you click back your browser will initially load just the first page and use Javascript to load the content you were looking at last.

I'd never considered the issue of passing on a link, but there is no reason the author's implementation couldn't also add a # to the URL to indicate that in addition to their current method, solving both problems. So for example, if you scrolled to page 3, and then back up to 2, and wanted to share that state with me the url would be /pages/1-3/#page2 or similar.

mikey_p• 15 years ago

If that's your concern, than you should provide fragments (as they are intended to use) within the list of 30 posts i.e:

http://example.com/pages/1-3#2011-05-12-screw_hashbangs_buil...

Otherwise your argument doesn't make much sense, linking to a list of 10 blog posts instead of 30 still doesn't show the user which specific post you wanted to link to out of a list of posts. Infinite scroll neither makes this problem worse nor better.

majmun• 15 years ago

article doesn't explain well what is the issue here with infinite srolls ? i get it that poor search engines will have difficult time crawling website with infinite scroll, but why do we care ? why will user care?

dgudkov• 15 years ago

Is there a viable alternative to hashbangs for indexing content of a heavy one-page AJAX-application (not just sexy AJAXy website)? We have rather complex AJAX app for web charts with embedded comments and hashbangs help visitors jump from SERP directly to comments shown in charts, created dynamically by Javascript. I'm pretty sure that between hashbangless urls and ease of use visitors choose latter.

qntm3• 15 years ago

I notice that this infinite scroll technique uses some sort of Javascript technique to update the contents of the address bar without redirecting the user to another page.

Isn't that a massive, cataclysmic security risk?

qntm3• 15 years ago

In answer to my own question, it seems that you can't modify the hostname using this method, only the query.

X-Istence• 15 years ago

It's using pushState which is part of the HTML 5 spec ...

qntm3• 15 years ago

I was thinking of the possibility of phishing by starting with a fake site and altering the URL to that of, e.g., a bank. But anyway, it seems not to be an issue.

Screw Hashbangs: Building the Ultimate Infinite Scroll

Related Stories