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".
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.
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/
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.
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.
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 "#!/".
It could be nice to have a non-snark explanation to avoid confusion.
The infinite page method given is programming technique. It is neither computer science nor software engineering in the way that a technique for holding a hammer is neither part of architecture nor mechanical engineering.
"[Software Engineering] is a 'systematic approach to the analysis, design, assessment, implementation, test, maintenance and reengineering of software, that is, the application of engineering to software.'"
http://en.wikipedia.org/wiki/Software_engineering
I think you read too much into the response. It didn't seem snarky to me. Sure, your explanation gave very helpful details, but I don't think the GP was being obnoxious.
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.
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"?
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.
Oops, I think I misread you. I thought you were talking about how hashbangs break the sharability of links, but you were really speaking about how Gawkmedia broke it. I'm not terribly familiar with their site.
...when the only clear case in favour of hashbangs (that I've heard of) is infinite scrolling
That's the first time I've heard them associated with infinite scrolling, but perhaps I've missed something.
The hash-bang idea is just about making ajax-y navigation URLs crawlable by spiders.
It's just an extension of the standard hash (without the bang) where the "url fragment" (everything after the hash) is used in AJAX applications to preserve the user's ability to bookmark and use the back & forth button on their browser.
I was confused by this Gawker issue for a long time, because no Gawker links at all worked for me whichever computer I was on, so I couldn't understand why people were submitting links to Reddit, or how Gawker were still getting any readers at all.
Someone pointed out to me that when I hit the url, I was being redirected to e.g. uk.kotaku.com and the issue appeared to be unaffecting American users, which goes some way to explaining away my confusion.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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".