After 2 years of reading Hacker News, I'm happy to finally have been able to contribute something to the discussion here.<p>To those who hate infinite scroll: I totally understand. I just wanted to try my hand at making a better version.<p>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".
Losing the hashbang and instead using history.pushState() to update the URL won't solve the problems that infinite scroll introduced.<p>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.<p>Here's a slightly different approach to infinite scroll that, imho, works reasonably well: (NSFW) <a href="http://www.pr0gramm.com/" rel="nofollow">http://www.pr0gramm.com/</a>
This post motivated me to figure out how to hack pushState support into NewTwitter:<p><pre><code> twttr.secrets.html5Routing = true;
twttr.router._changeUrlAndCallAction = function(p) {
return twttr.Router.prototype._changeUrlAndCallAction.call(this, p.replace("#!/", ""));
}
twttr.router._changeUrlAndCallAction(window.location.hash);
</code></pre>
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 "#!/".<p><a href="https://gist.github.com/996381" rel="nofollow">https://gist.github.com/996381</a>
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.
This breaks the back-button for me, despite the author claiming otherwise.<p>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<p>Expected behaviour: Get moved back to the article page
Encountered behaviour: Still at front page, scrolled to the middle.<p>Using Safari 5.0.5, OS X 10.6.7
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.<p>Instead he probably wants:<p>/pages?/([0-9]+)(?:-([0-9]*))?/?/$<p>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.<p>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.
<i>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><p>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".<p>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.
Very neat. I implemented a similar structure for my blog (described here: <a href="http://boston.conman.org/about/technical.html" rel="nofollow">http://boston.conman.org/about/technical.html</a>) but never thought of connecting it to an infinite scroll.
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.<p>Isn't that a massive, cataclysmic security risk?
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?