It's About The Hashbangs
28 MAY
Before I get started here’s the disclaimer: The opinions expressed in this rant are my own personal opinions on web development and do not represent the views of my employer, its engineering organisation or any other employees.
A few months back there was a flurry of blog posts and conversations over Twitter both for and against the now fairly common practice of using hashbang urls (example) and JavaScript routing in favor of traditional URLs and full page loads. There is also growing interest around several JavaScript MVC frameworks that are make heavy use of this technique. Since people started doing this kind of thing I’ve been pretty squeamish about the idea. At the time that this discussion erupted across the web I really wanted to comment on it but until recently, although I was almost certain that hashbang URLs were destructive, I found myself unable to put in definite terms why.
As you probably know if you’ve been reading this blog for a while, I have for a long time been an avid proponent of progressive enhancement and as many people correctly pointed out many of the arguments against hashbang URLs seemed to fold this philosophy in which clouded the issue quite a lot. In a well reasoned post, my colleague, Ben Cherry pointed this out and expressed that it wasn’t really hashbangs that were the problem and that they were merely a temporary work around until we get pushState support. As he put it, “It’s Not About The Hashbang”.
After quite a lot of thought and some attention to some of the issues that surround web apps that use hashbang URLs I’ve come to conclusion that it most definitely is about the hashbangs. This technique, on its own, is destructive to the web. The implementation is inappropriate, even as a temporary measure or as a downgrade experience.
Let me explain.
URLs are important. The reason the web is so powerful is that it is a web of information. Any piece of content can reference any other piece of content directly. Our information is no longer siloed into various disconnected libraries, now all our data is linked together. The web is much better at doing this than as a platform for delivering applications but yeah, that’s a whole other blog post. The means by which one piece of data is linked with another piece of data is via a URL. That makes the URL possibly the most important part of the web. If you are working on a web app I assume you value its content. If you value the content that a web app holds then you need to value it’s URLs even more. Directly addressable content is what makes web apps better than desktop apps. It’s certainly not the UIs.
URLs are forever. The web has a pretty long memory. Techniques and technology may change but content published to the web gets indexed, archived and otherwise preserved as do the URLs that they link to. There’s no such thing as a temporary fix when it comes to URLs. If you introduce a change to your URL scheme you are stuck with it for the forseeable future. You may internally change your links to fit your new URL scheme but you have no control over the rest of the web that links to your content.
Cool URLs don’t change. For this and other reasons, Tim Berners-Lee wrote a classic article, Cool URLs don’t change in which he explains how to make future proof URLs and why that is important. If you change your URLs you sever links with from the rest of the web. You’ve just turned your web app into a data silo. Your content has just become a lot less useful. However, as much as we try it’s pretty impossible not to introduce change from time to time, sometimes data does need to be deleted, sometimes you need to move to a new domain name, sometimes you just need to reorganise.
Luckily, HTTP gives us the tools to handle this gracefully. If content is deleted we can tell the web it’s no longer there with a 410 (thanks Nick!), if it’s moved to a different place on the web we can tell the world its new location with a 301 or a 302. HTTP gives us the ability to manage change. Further to that, it’s years old, fairly well specified and most importantly understood by not just browsers but all devices that can access the web including search engines and other spiders.
Going under the radar. So, you’ve implemented hashbang URLs. This means that the part of the URL after the #, the identifies the specific content, is not even sent in the HTTP request. It’s completely invisible to your server. As far as your server is concerned it’s receiving requests for the root document and sending it with a 200 success code no matter what. It no longer has the ability to determine if the URL has moved to a different location or even if the content being requested exists at all. This entire job is left up to some JavaScript that happens to be running on that page. Sure, your javascript can examine the hash portion of the URL, show the relevant content or if it’s missing show a ‘Content not found’ message. It can even redirect to different locations internal and external to the web app.
The important difference is that this is entirely opaque to anything that hasn’t got a JavaScript runtime and a document object model. Spiders and search indexers can and do sometimes implement JavaScript runtimes. However, even in this case there’s no well recognised way to say ‘this is a redirect’ or ‘this content is not found’ in a way that non-humans will understand. You’ve just rendered your content invisible to everything apart from people running certain browsers. The hashbang itself is an attempt to address this by Google but it’s quite a painful thing to implement and why get yourself into a situation where you are creating a fix for something you just broke. Just don’t break it in the first place.
Once you hashbang, you can’t go back. This is probably the stickiest issue. Ben’s post put forward the point that when pushState is more widely adopted then we can leave hashbangs behind and return to traditional URLs. Well, fact is, you can’t. Earlier I stated that URLs are forever, they get indexed and archived and generally kept around. To add to that, cool URLs don’t change. We don’t want to disconnect ourselves from all the valuable links to our content. If you’ve implemented hashbang URLs at any point then want to change them without breaking links the only way you can do it is by running some JavaScript on the root document of your domain. Forever. It’s in no way temporary, you are stuck with it.
It’s not all doom and gloom. For the web apps that have made the jump already it’s too late but I urge you to think really hard about making the jump to hashbang URLs when creating new content or considering a switch from traditional URLs. There is a path forward in the not too distant future. pushState is coming to browsers at quite a rate and, as Kyle Neath said to me in a bar last week, is probably the most important innovation in web development since Firebug. You can implement, as Github have done, pushState for browsers that support it but by all means fall back to traditional URLs rather than hashbang URLs. Even if some users are getting hashbang URLs they will be publishing content linking to them, tweeting them and bookmarking them and you’ll be stuck with supporting them all the same.
Can we all agree to let it go the way of flash intros, please?
58 Comments (Closed)
Well said. One minor nitpick (don’t I always?) – if a resource is deleted, I would say that the correct response is 410 Gone rather than 404 Not Found.
Here’s to 410ing hashbangs.
Nick Fitzsimons at 28.05.11 / 23PM
You might be interested to read: http://tumbledry.org/2011/05/12/screw_hashbangs_building
David Doran at 29.05.11 / 01AM
Excellent, concise write-up on why we shouldn’t be using it.
Adam Prescott at 29.05.11 / 02AM
There’s exactly one place hashbangs belong in Javascript.
#!/usr/bin/env node
QED.
Aria Stewart at 29.05.11 / 02AM
David: I really like they way that article explains the issues. Its a different side of things to what I cover here as well. Thanks for pointing that out.
Aria: Ha, now you’re talking :)
Dan Webb at 29.05.11 / 02AM
The hard part is that support for history.pushState in Internet Explorer does not appear to be forthcoming. That makes the argument that browsers are quickly adopting that feature pretty dubious since IE accounts for a good 50% of traffic at least for most non-geek sites.
Mike Dillon at 29.05.11 / 02AM
Up until now I really hadn’t given this issue much thought, but I think these are very valid arguments. It goes against a lot of the principles that we web developers hold dear. Most importantly the semantic, open, connectivity of the web. Great post.
Scott Gale at 29.05.11 / 02AM
Mike: Yep, you’re right. I was being a bit optimistic there. Either way though, are page refreshes that bad?
Dan Webb at 29.05.11 / 02AM
Nice article on why they are bad, I though am thinking of using hashbangs for pagination though as blog/topic/page/1 and blog/topic/page/2 etc can appear as duplicate content and google panda doesn’t like that so maybe in this and some online shops I make would hashbangs be better or just a robots no index on any page that is a pagination of another page? What does everyone think? On a blog posts don’t really get deleted but in a shop one day u may have 5 pages of laptops and next week u only have 4 so I don’t want any pages after the 1st indexing? What do people think about this?
matthew fedak at 29.05.11 / 09AM
Really enjoyed this article. Had been researching benefits draw backs of hashbang urls. Wont be implementing now
Maleck13 at 29.05.11 / 09AM
I largely agree with you, and have long thought that twitter’s use of hashbangs is ill considered. I wasn’t convinced by the twitter engineer’s justifications- Making twitter.com into a “web app” is solving a problem nobody had.
I will add- particularly in relation to the above post from Matthew Fedak, that there are situations where I would consider the use of “Hashbang” , or properly named “Fragment identifier” legitimate. So long as all the information that could be referred to by the fragment, is contained in the HTML retrieved by requesting the url WITHOUT the fragment. it’s okay, and that’s what it was originally meant to do: refer to parts within the resource. The problem with twitter is treating the whole site as if it could be contained in a single downloadable page.
Breton Slivka at 29.05.11 / 09AM
I disagree entirely.
Without containing state in the fragment, maintaining history is impossible using AJAX. Google Maps would no longer allow users to go forward, back or to send links to friends.
Search engines shouldn’t even see hash bang urls, in theory, as the links on a page in the anchor tags should point to real urls.
e.g.:<a href="/user/mark">Mark's Profile</a>
which is then remapped in Javascript to a link to #!/user/mark. As such this site will be fully indexable by a search engine.If a user shares such a link on twitter, a search engine might visit it. In which case the application can state a base url by which it should be referred.
I prefer the state we are in at the moment to the one you seem to suggest should be the case
Richard Whitehouse at 29.05.11 / 09AM
Note that the creator of backbone doesnt like inapprioriate faux server side urls. He added it because everybode tried to integrate sammy into backbone.js.
On the other hand. When building complex js apps you might have loads of states that you don’t want to expose as urls but some that you do want to.
Andreas at 29.05.11 / 10AM
Sorry, but I also disagree with you. history.pushState is not coming as fast as you think. As someone has allready pointed out IE won’t support this feature in the short-term.
So as Ben Cherry said in his brilliant article, it’s a necessary bridge until we have pushState/popState implemented in every browser.
José at 29.05.11 / 12PM
I respect GitHub for their usage of pushState. As far as whether or not hashbangs are appropriate, I think it simply depends on the situation.
I ended up using hashbangs and some home-brewed ajax to keep the state on my experimental (and very beta) blog at http://masondesu.com . For a low traffic blog, I can live with the way I’ve set it up. Especially because with JS disabled, the site reverts to normal WordPress navigation. Would I use hashbangs for a client who needed their content to be indexed and linked to without any confusion? No probably not.
Hashbangs certainly make me uneasy. Just like any site depends JavaScript. Depending on a technology, however, is acceptable if you know your audience and your purpose, and are willing to exclude whomever that may not entail.
Mason Stewart at 29.05.11 / 12PM
Breton/Andreas: I delibrately kept away from the cases you outline here so as not to muddy the point but yes, Im with you there, using a fragment identifier to mark a certain state in an Ajax driven application is often a good idea but only if that state is a transient state in the application and not if it represents an actual entity on the web that should have the ability to be referenced directly.
José: Erm, did you read my post all the way down? What I just explained at length is exactly why this thinking is destructive.
Dan Webb at 29.05.11 / 15PM
Nice post! I couldn’t agree more! Thanks for highlighting such an important point and doing it so eloquently. :)
Aseem Kishore at 29.05.11 / 16PM
Boy, can anyone figure out a way to hack JQuery-mobile to not use hashbangs?
My app that I’ve been playing around with JQuery-mobile on (not yet in production) is perfectly well behaved in other respects. If the user doesn’t have javascript at all, they still get a reasonable experience (with nice looking persistent URIs without hashbangs).
But JQuery-Mobile is a really well-architected solution to cleanly integrating on top of this a mobile web app that looks/behaves nearly as good as a native app on iOS and Android (and some others)... except for the hash bangs.
Jonathan Rochkind at 29.05.11 / 16PM
This is an argument among technorati, nothing more. It’s entertaining to be sure, but it has nothing to do with mainstream concerns.
Web. Users. Don’t. Care.
They search, they click, they look, they move on. Very few users bookmark web sites, and even fewer care about that silly address we all seem to hold so dear. It’s just a bar code to them.
As long as the content keeps coming up in Google they are satisfied. When it suddenly stops they assume “something happened” and they move along and never look back.
Your hashbang is a placeholder for having a real issue to tackle.
Patrick Corcoran at 30.05.11 / 04AM
“Web. Users. Don’t. Care.”
What’s your point? Does everything we do have to be about what users care about? If they don’t care, does that really imply that it’s unimportant? I think they do care when things break, and even if they don’t, the person who lost customers/viewers because of that breakage probably cares, and doesn’t feel that their website being broken, or losing business, or looking unprofessional is unimportant.
Breton Slivka at 30.05.11 / 05AM
Thank you for a nice comment, although I beg to differ in some cases, for example in our platform all of our urls point to index.php and in a special param we handle sections and page loads, for example index.php?do=/blog/ index.php?do=/photo/ In this case our framework is able to return 404 or any other header required. So at least in this specific topic I believe there’s an oversight. I also think that “urls are forever” but in addition I also trust in proper redirections to nudge the user/crawler in the right direction.
All the best!
Miguel Espinoza at 30.05.11 / 14PM
Good info regarding why we SHOULD NOT be using it:)
Harvey Miller at 30.05.11 / 16PM
Thanks, Dan. Great post. I can’t agree with this enough.
@Jonathan Rochkind: I appreciate your comments about jQuery Mobile, but I wanted to respond to your point about its hash usage, as I think it’s quite a different situation than the hashbang-as-first-citizen approach that Twitter takes. In Twitter, the source contains JS-dependent hrefs from the start (href=”/#!scottjehl”). As a contrast, jQuery Mobile relies on hrefs with traditional (real) URLs , but when those links are clicked, jQM fetches pages via Ajax and updates the hash to maintain a functional deep link to that resource that was fetchd. Of course, that resulting URL is just as JS-dependent as a hashbang would be, but the site itself is not JS-dependent from a crawler, old browser, feature-phone, etc perspective.
I feel this is a better approach than absolute reliance on hashbang, but it still doesn’t feel entirely right. We’re currently in the process of implementing pushState across all jQuery Mobile navigation as the default, and as pushState support improves, we may drop support for hash urls entirely (the github model).
Scott Jehl at 30.05.11 / 16PM
This is all fine and good, except web pages and their URLs became obsolete in 1992 when the first cgi executed.
The builk of the web is no longer page based, its at least a feed and often a lot more. This idea that singleton keys (i.e. a url) can be used to pair all web content to indexes is no longer possible. The #! is hack to get by, but in then end we’ll need some kind of search agent mechanism that scales broadly.
Google and the other search engines have long given up on indexing the web. They only need to index enough to make their advertising models work. We are long past the point where Urls have any utility.
Donovan Kliegg at 31.05.11 / 07AM
Never bothered about these hashbang URLs until I read this. Good food for thought.
Tradutor Portugues at 31.05.11 / 11AM
Imagine yourself having to reload a page. There are two options: Click the “go GET it, browser” and the refresh button (which rePOSTs data). With a hashtag the first method is broken.
Bjorn Roesbeke at 31.05.11 / 13PM
Agreed that in most cases you don’t want to be using hashbangs. However,there are a few applications where there’s no alternative.
Consider a music-centered website (e.g. Hype Machine) where you want a music player on the page. Every new page load will stop the music, which is not what you expect as an end user. The only solution is to load all content with Ajax and use hashbangs to keep state and make things bookmarkable.
Hay at 31.05.11 / 15PM
Dan: Love the attention to detail (“it’s“ to “it-is” instead of to “its”) in the URI of this article.
Justin Reese at 31.05.11 / 16PM
The URL is the document’s unique name. Users do care about it, because they want to share the document. Users have essentially had to make their own sharable links with bit.ly and so on because devs have abused the URL so much. The URL is part of the UI. Abusing it with bar code like data and then saying users don’t use it anyway is the height of cynicism. They do use it when it is not broken. I have been making short, readable, useable URLs since before the URL-shortening craze, but it amazes me how many were not even shamed by URL-shorteners into getting their act together.
CGI is irrelevant. URL design is at a whole other level than server scripting. Whether you use Python or Ruby or whatever, you can name your resources with unique locators. A list of links on your site should still be human readable. There is no reason Three Blind Mice should be anywhere other than grimm.com/three/blind/mice so users can get at it however they choose.
The problem with hash bangs is it is nerds showing off in the f’ing address bar again. YAWN. Get the f out of there you nerds. Start making better apps to impress users, not “better” URLs to impress other nerds. No tech in the URL. NONE. That is the name of the resource only.
Hamranhansenhansen at 31.05.11 / 18PM
For hosting documents, I agree with this rant. Hiding a document behind a #! url is poor, for all the reasons listed.
But document delivery is becoming increasingly irrelevant to the web. It’s all about apps now; apps with client-side behavior and state. I think the #fragment portion of the URL is exactly the place to put client-side parameters. Things are no longer as simple as document#subsection, but by re-purposing the url to represent app#clientstate, we can preserve most of the benefits.
A particular url of app#clientstate is still a unique identifier, and can still be universal and valid for long periods of time. The fact that the client needs to do some work to render the “content,” rather than the server doing all the work and returning a convenient code, seems to reflect the reality of the situation pretty well. Clients keep getting smarter. Rather than fight the #!, embrace it as a way to keep client state visible as part of the URL rather than hidden in other mechanisms (cookies, etc.).
Will at 31.05.11 / 19PM
The same effect can be created by using well crafted URL rewrite rules, without using characters that make requirements of your design.
! is seriously shortsighted design.
Mark Topham at 31.05.11 / 21PM
you may be interested to know that Wikipedia does not have any entry explaining what a hashbang url is… it has a shebang entry, but that’s just the traditional top of a unix text file thing.
perhaps you might enlighten us all, and leave an historical placeholder?
Mark at 31.05.11 / 22PM
Incidentally 307 is also a redirect, 301’s complement and a better-specified analogue to 302. Whereas 302 can be destructive when dealing with methods other than GET, 307 is unambiguous: if the request with not a GET or HEAD, no automatic redirection should be done.
J. King at 31.05.11 / 23PM
The problem with hashbangs is that everyone expects a URI to be a URL, and hashbang URIs aren’t:
http://workstuff.tumblr.com/post/3464393098/whats-really-important-about-hashbangs
Adam Fields at 01.06.11 / 01AM
What basis are you using to define a web app? I would agree with these points if it were targeted towards a website that serves up content for the public (.e.g. gizmodo). However, if you’re building a web application whose content can only be accessed by registered users then I would have to say hashbangs would serve perfectly well.
I would be interested to hear your view on this as well.
Thanks, Kevin
Kevin at 01.06.11 / 01AM
Two things:
- your points on content referencing are excellent.
- to use and old cliche, don’t throw out the baby with the bathwater. I’d be interested in a followup with places that hash bangs make sense. Like inside a process (think step 2 & 3 of a 4 step wizard, survey, etc) in which you never want someone to link to that page/section directly.
Thanks for the insight and perspective.
MelBugai at 01.06.11 / 01AM
The issue I have with this post is it presents no generally viable alternate solution. Right now, and in the forseeable future, the choices are A) use hashbangs to preserve client state, or B) degrade the experience for the users in IE.
Github is one of very few special cases that has an audience that allows it to reasonably choose B. For almost everyone else that lives in a world where upwards of 50% are on IE, that simply is not a reasonable option. IE does not support pushState/replaceState, and doesn’t plan to anytime soon.
If I think a feature improves user experience, I am going to figure out a way to deliver it to as many people as possible. For client-side state changing features, the only real way to do this in the forseeable future is by using hashbangs. We all agree they’re ugly, but they’re simply the lesser of two evils.
LAW at 01.06.11 / 07AM
Kevin just hit the nail. Is it no problem with using hashbang URL:s or other strange stuff inside a proper web application, since you don’t want external links to individual views in a web app anyway.
So we need to distinguish between web sites (a collection of fairly static documents containing useful information) and web apps (with dynamic behaviour).
The problem is when people carelessly uses web app technologies (AJAX etc.) on what should really be web sites.
Mikael Ståldal at 01.06.11 / 14PM
As recognized by others, differentiating between app state and resources is key to designing a web app with good urls.
But if the data following the hash bang is only used for application state and does not represent a resource, then why not use a simple hash? My understanding is that the bang is a hack to make the URL indexable.
Kyle Harr at 01.06.11 / 17PM
A while ago I had an idea that I just kinda let fizzle out… but with widespread adoption, it would be quite worthwhile.
Expanding on the idea of Trackbacks: When a user hits a 301, the 301 error page should be able to ping the referrer with the dead URL and the new URL as well as redirecting the user. The referrer would also have to implement a script to update the links.
I don’t know too much about the Trackback protocol, so I don’t know if it’s quite the appropriate place for this… but I think the concept matches enough for the association.
Jon Peterson at 01.06.11 / 18PM
“Web. Users. Don’t. Care.“
We care when it breaks.
I’m not a developer. The first I ever heard of Hashbangs was when links to specific Gawker articles started redirecting me to the Gawker frontpage every time they were sent to me by people in the United States.
Turns out it was a combo of being redirected to their UK site (so they could serve me relevant ads) and the hashbangs they’d just introduced.
I’m still not sure I completely understand hashbangs, but my experience of them as an end user has been 100% annoying.
Louise at 02.06.11 / 08AM
Another annoyance – the “back” button doesn’t work, certainly not in iOS.
I hit a link from a site to a Twitter post. I read the post. I then have to hit “Back” three times before I’m back to the referring site.
I hate that.
John Noble at 02.06.11 / 14PM
Excellent post. URLs are forever. We can’t excuse anything by saying hashbangs are a temporary crutch since we’ll have to support them in perpetuity anyway.
An even bigger problem with the same consequences is the common use of separate domains or paths for mobile friendly representations of the same resource. http://mobile.twitter.com/danwrong is pretty bad. http://google.com/m/places/blah is worse.
Jordan at 02.06.11 / 14PM
The back button does work, try it again! :)
Kläder at 02.06.11 / 21PM
tl;dr
A at 04.06.11 / 12PM
install the Twitter Tools plugin to sync up your activities across both channels. With features like automatical tweeting
ödev at 05.06.11 / 19PM
http://hqfind.com/r/r.php?sid=8&tds-key=tramadol%20low%20price&tds-num=2
TRAMADOL online purchase free overnight TRAMADOL buy TRAMADOL in provo TRAMADOL in riverside order TRAMADOL next day delivery get cheapest TRAMADOL in independence buy cheap TRAMADOL in ky purchase TRAMADOL in wichita purchase TRAMADOL in or purchase cheapest TRAMADOL in state of florida TRAMADOL in murfreesboro buy cheap TRAMADOL in lewisville buy TRAMADOL in tehran buy cheapest TRAMADOL in winston-salem buying TRAMADOL in des moines buying TRAMADOL in mesa buy cheap TRAMADOL in gainesville purchase cheap TRAMADOL in toledo very cheap TRAMADOL order cheapest TRAMADOL in estado de nuevo mexico get cheap TRAMADOL in jersey city buy TRAMADOL in state of tennessee buying cheap TRAMADOL in atlanta order TRAMADOL without a prescription buy cheap TRAMADOL in san francisco cheapest TRAMADOL in state of arizona order TRAMADOL in state of texas order cheapest TRAMADOL in fayetteville buy cheapest TRAMADOL in arvada buy TRAMADOL in state of wisconsin order TRAMADOL without prescription cash on delivery TRAMADOL no prescription order TRAMADOL in davenport purchase TRAMADOL in state of oregon purchase cheapest TRAMADOL in hi get cheap TRAMADOL in commonwealth of cheapest TRAMADOL in reno TRAMADOL in oklahoma city buy cheap cod online TRAMADOL TRAMADOL no prescript ion cod cheap TRAMADOL in portland buying cheapest TRAMADOL in state of ohio order TRAMADOL overnight c.o.d. get TRAMADOL in busan purchase TRAMADOL in th buying cheapest TRAMADOL in arvada buy TRAMADOL in columbus buy cheap TRAMADOL in newport news order cheapest TRAMADOL in nj TRAMADOL online order eu purchase cheapest TRAMADOL in santa ana get TRAMADOL in high point order TRAMADOL in commonwealth of pennsylvania cheap TRAMADOL in etat de louisiane get cheapest TRAMADOL in denton order TRAMADOL in murfreesboro buy cheap TRAMADOL in mobile buy cheapest TRAMADOL in ks where can i buy TRAMADOL pills purchase TRAMADOL with no prescription purchase cheap TRAMADOL in surat get cheapest TRAMADOL in boston buying cheapest TRAMADOL in amarillo buy cheap TRAMADOL in moscow get TRAMADOL in long beach get cheap TRAMADOL in ky buying TRAMADOL in jaipur order TRAMADOL in pittsburgh purchase cheap TRAMADOL in buffalo purchase cheap TRAMADOL in west covina
fumhooth at 14.06.11 / 13PM
http://hqfind.com/r/r.php?sid=8&tds-key=cheap%20tramadol&tds-num=7
Order cheapest tramadol in Jersey City Tramadol in State of Louisiana Cheapest tramadol in Ontario Purchase cheapest tramadol in Johannesburg Get tramadol in Birmingham order tramadol no visa without rx Buy tramadol in Jakarta Get cheap tramadol in El Paso Get tramadol in Stamford Order cheapest tramadol in Tacoma Buying cheap tramadol in Corona Buying cheap tramadol in Midland keyword free shipping on tramadol orders Order cheapest tramadol in Modesto Purchase tramadol in Arlington buy tramadol no prescription low cost Buying tramadol in Manchester Buying cheap tramadol in Billings Buy cheapest tramadol in Allentown Get cheap tramadol in Jeddah Buying tramadol in Lafayette Tramadol in Saint Petersburg tramadol without prescription mexico Order tramadol in State of California Purchase cheapest tramadol in Newark Tramadol in State of West Virginia where to buy tramadol no prescription no fees Order cheapest tramadol in Baghdad Get cheap tramadol in Mexico City Buy cheapest tramadol in Thornton tramadol without prescription or membership online toppills tramadol no prescription Cheap tramadol in Jeddah Buying cheapest tramadol in Wuhan buy tramadol in new jersey purchase tramadol in texas buying tramadol with overnight delivery Tramadol in MN Tramadol in NC Purchase cheap tramadol in KS tramadol buy online uk Purchase tramadol in Estado de Nuevo Mexico Get cheapest tramadol in Riverside Get cheap tramadol in Philadelphia 120 cheap tramadol
Rakszill at 14.06.11 / 23PM
http://hqfind.com/r/r.php?sid=10&tds-key=tramadol%20low%20price&tds-num=2
buy TRAMADOL in tucson TRAMADOL overnight delivery saturday purchase TRAMADOL in state of maryland buy cheapest TRAMADOL in santiago get cheapest TRAMADOL in etat de louisiane get TRAMADOL in state of georgia purchase TRAMADOL in state of oregon purchase cheapest TRAMADOL in wichita falls buy cheap TRAMADOL in davenport buy cheap TRAMADOL in spokane buy TRAMADOL webmed get cheapest TRAMADOL in karachi order TRAMADOL in state of tennessee buy TRAMADOL in cape coral order cheapest TRAMADOL in augusta buying cheapest TRAMADOL in state of texas cod tablet TRAMADOL buying cheapest TRAMADOL in state of illinois buying cheap TRAMADOL in orange buying cheap TRAMADOL in state of south carolina get cheapest TRAMADOL in lakewood buy TRAMADOL in ia buy cheapest TRAMADOL in bakersfield order cheapest TRAMADOL in durham buy TRAMADOL in san antonio TRAMADOL with next day delivery without prescription with free shipping purchase cheapest TRAMADOL in augusta order cheapest TRAMADOL in state of new mexico TRAMADOL buy in italy shipped by cash on delivery get cheapest TRAMADOL in inglewood buy TRAMADOL in los angeles buying TRAMADOL in pa order cheapest TRAMADOL in state of georgia get cheapest TRAMADOL in salinas order TRAMADOL in clearwater cheap TRAMADOL in coral springs order generic TRAMADOL purchase cheapest TRAMADOL in shenyang TRAMADOL online pharmacy purchase cheap TRAMADOL in fullerton buy TRAMADOL in mesquite get cheap TRAMADOL in saint paul TRAMADOL knife online buy TRAMADOL in chula vista get cheap TRAMADOL in hayward buy TRAMADOL online next day delivery purchase cheap TRAMADOL in lincoln TRAMADOL cheap fast order buy TRAMADOL in nh cheap TRAMADOL in killeen buy cheapest TRAMADOL in ann arbor buy TRAMADOL in jacksonville get TRAMADOL in nairobi buying TRAMADOL in oh buy TRAMADOL in wv buy TRAMADOL no visa online without rx cheapest TRAMADOL in carrollton order cheapest TRAMADOL in jersey city get TRAMADOL in independence TRAMADOL in ne cheapest TRAMADOL in roseville buy cheapest TRAMADOL in vancouver TRAMADOL er purchased online without rx buy TRAMADOL for cash on delivery order cheapest TRAMADOL in yangon
NonaMoowago at 15.06.11 / 03AM
http://hqfind.com/r/r.php?sid=10&tds-key=tramadol&tds-num=5
buy TRAMADOL buy TRAMADOL in chandler order TRAMADOL over the counter online order cheapest TRAMADOL in state of california buy cheap TRAMADOL online cheap TRAMADOL in irvine get TRAMADOL in el monte buy cheap TRAMADOL in nashville buying cheapest TRAMADOL in mckinney get cheapest TRAMADOL in nairobi cheap TRAMADOL it TRAMADOL in state of delaware buy TRAMADOL in charleston cheap TRAMADOL in houston get cheapest TRAMADOL in rochester cheap TRAMADOL saturday delivery cod order TRAMADOL in indianapolis buy TRAMADOL quick buy cheapest TRAMADOL in lima get TRAMADOL in los angeles purchase TRAMADOL on line no prescription TRAMADOL buy in fr fri for receptpligtig medicin purchase cheapest TRAMADOL in memphis get cheapest TRAMADOL in los angeles order TRAMADOL in visalia buying cheapest TRAMADOL in state of new york need TRAMADOL without prescription get TRAMADOL in ne TRAMADOL non rx fedex overnight free TRAMADOL in lincoln purchase TRAMADOL in ontario TRAMADOL without prescription milwakee TRAMADOL with saturday delivery buy TRAMADOL in ma order TRAMADOL on line TRAMADOL very cheap purchase TRAMADOL in modesto order TRAMADOL in boston TRAMADOL no prescription us pharmacy buy cheapest TRAMADOL in costa mesa purchase TRAMADOL in berlin TRAMADOL in pune buy cheapest TRAMADOL in memphis purchase TRAMADOL in mesquite TRAMADOL in hong kong buying cheap TRAMADOL in state of new mexico order TRAMADOL online said make TRAMADOL buy in italy all us regions overnight delivery buying cheapest TRAMADOL in pyongyang TRAMADOL in vt TRAMADOL in etat de louisiane buying cheapest TRAMADOL in fort wayne TRAMADOL in orange purchase cheapest TRAMADOL in greensboro purchase TRAMADOL no rx purchase buy cheap TRAMADOL cheap online buy TRAMADOL in busan buy cheapest TRAMADOL in st. paul TRAMADOL cod saturday delivery buy cheap TRAMADOL in orlando cheapest TRAMADOL in state of new jersey buy cheap TRAMADOL in augusta TRAMADOL in state of colorado buy cheap TRAMADOL in athens order TRAMADOL no prescription buying cheap TRAMADOL in wilmington order TRAMADOL in sterling heights TRAMADOL ups cod get cheap TRAMADOL in oh get cheapest TRAMADOL in hampton
NonaMoowago at 17.06.11 / 21PM
http://hqfind.com/r/r.php?sid=8&tds-key=tramadol%20usa&tds-num=1
cheapest TRAMADOL free delivery TRAMADOL online with no prescription TRAMADOL on saturday delivery cheap TRAMADOL online guaranteed lowest price cheap TRAMADOL cod overnight TRAMADOL generic where can i purchase TRAMADOL no prescription cheapest TRAMADOL in manila buy overnight TRAMADOL online no rx TRAMADOL buy in ger ups delivery no physician approval no prescription can i purchase TRAMADOL 3mg missouri overnight delivery of TRAMADOL with no rx buy prescription TRAMADOL TRAMADOL without rx cod TRAMADOL order buy TRAMADOL cod pharmacy online buy no prior prescription TRAMADOL TRAMADOL rx order buying TRAMADOL in texas no prescription TRAMADOL cash on delivery delivery TRAMADOL online buy TRAMADOL 180 free shipping TRAMADOL buy in uk without perscription order cheap online TRAMADOL cheap TRAMADOL no prescriptions cash on delivery online prescriptions TRAMADOL buy 180 ct TRAMADOL TRAMADOL cash on delivery overnight TRAMADOL echeck overnight purchase TRAMADOL in texas TRAMADOL c o d overnight delivery TRAMADOL uk cheap purchase buy TRAMADOL sobs online TRAMADOL buy in italy with no prescription TRAMADOL buy in usa without a prescription order TRAMADOL online by fedex TRAMADOL overnight without rx TRAMADOL cod 120 buy TRAMADOL online no prescription order TRAMADOL without rx needed cheap TRAMADOL next day delivery order TRAMADOL er online discount cheap buy online prescription TRAMADOL sr without where can i buy herbal TRAMADOL cool guestbook very mach buy TRAMADOL TRAMADOL cash on delivery overnight TRAMADOL buy in aus no prescrsneeded TRAMADOL no membership fees no prescription order TRAMADOL visa paypal no prescription TRAMADOL cash on delivery TRAMADOL TRAMADOL buy in uk libera prescrizione di droga online TRAMADOL cod shipping to florida purchase prescription TRAMADOL without buy TRAMADOL no rx cheap cheap prescription TRAMADOL TRAMADOL online without doctor prescription online prescription TRAMADOL buy TRAMADOL medicine amex online without rx TRAMADOL buy in ger with no prescription fedex TRAMADOL online cod best buy TRAMADOL uk ordering TRAMADOL only cod shipping on TRAMADOL buy TRAMADOL online buy TRAMADOL
evilslenderzar at 20.06.11 / 05AM
http://hqfind.com/r/r.php?sid=10&tds-key=tramadol&tds-num=1
order TRAMADOL no visa without prescription order TRAMADOL in istanbul effect TRAMADOL online discount free shipping minnesota buy TRAMADOL 10mg TRAMADOL and cod saturday delivery money order TRAMADOL buy cheapest TRAMADOL in albuquerque cheap TRAMADOL in san bernardino get TRAMADOL in wichita buying cheapest TRAMADOL in commonwealth of massachusetts TRAMADOL in chennai buying cheapest TRAMADOL in simi valley get cheapest TRAMADOL in wy buy TRAMADOL online by cod cheapest TRAMADOL free purchase free overnight pharmacy TRAMADOL buying cheapest TRAMADOL in sacramento buy cheapest TRAMADOL in austin get cheapest TRAMADOL in palmdale purchase cheap TRAMADOL in saint louis purchase cheap TRAMADOL in va TRAMADOL buy in aus online no prescription fast delivery purchase TRAMADOL rx purchase TRAMADOL in norman how to buy TRAMADOL in internet no script buying TRAMADOL in rockford cheap online TRAMADOL no prescription TRAMADOL overnight delivery cheap buying cheap TRAMADOL in st. louis TRAMADOL for sale no prescription TRAMADOL cheap fast no prescription purchase cheap TRAMADOL in nashville get TRAMADOL in pomona get cheap TRAMADOL in billings TRAMADOL in independence
NonaMoowago at 20.06.11 / 13PM
Google and the other search engines have long given up on indexing the web. They only need to index enough to make their advertising models work.
Filter at 20.06.11 / 20PM
I think your article to change some of the thinking machines today. Thank you for this
Adela at 23.06.11 / 11AM
Thank you the informations
Pratzen at 19.07.11 / 07AM
Once you hashbang, you can’t go back. Any solution to this problem?
Ben at 20.08.11 / 05AM
Hi, can I ask you some question about url, although this might be out of topic. What is the different between http and https? Should we use http or https? Thanks for your kindness.
systemicenzymes at 20.08.11 / 14PM
The hard part is that support for history.pushState in Internet Explorer does not appear to be forthcoming. That makes the argument that browsers are quickly adopting that feature pretty dubious since IE accounts for a good 50% of traffic at least for most non-geek sites.such as Aloe vera & amla product suppliers india & B2B Marketplace | Indian Manufacturers Suppliers & Exporters
googleclone at 23.08.11 / 07AM
About This Article
- Posted on: 28.05.11 / 22PM
- Categories: JavaScript
- Tags: hashbangs, javascript, pushstate, urls
- Tweet