Screw Hashbangs: Building the Ultimate Infinite Scroll
tumbledry.org
tumbledry.org
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".
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/
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.
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.
twttr.secrets.html5Routing = true;
twttr.router._changeUrlAndCallAction = function(p) {
return twttr.Router.prototype._changeUrlAndCallAction.call(this, p.replace("#!/", ""));
}
twttr.router._changeUrlAndCallAction(window.location.hash);
I quit.
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
Software engineering is a part of applied computer science. http://en.wikipedia.org/wiki/Computer_science
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"?
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.
...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.
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.
Horrible, horrible implementation.
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.
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
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.
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.
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.
I suppose this was all discussed to death around the rollout of NewTwitter, but it bears repeating.
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.
True story, degrees are a meaningless measure for skill or ability in a specific field.
Isn't that a massive, cataclysmic security risk?