What's wrong with using hashbangs in URLs?
May 31, 2011 3:37 PM Subscribe
What's wrong with using hashbangs in URLs for AJAX functionality?
There's a lot of discussion about the use of hashbangs in URLs, and why the practise is good/bad, but I've yet to see to see a good business oriented (non-technical) discussion of the pros and cons.
Are there any better options for a site that needs:
- AJAX functionality
- the separate AJAX states to be accessible to users (cross-browser, including IE)
- the separate AJAX states to be accessible to search engines as distinct 'pages'
There's a lot of discussion about the use of hashbangs in URLs, and why the practise is good/bad, but I've yet to see to see a good business oriented (non-technical) discussion of the pros and cons.
Are there any better options for a site that needs:
- AJAX functionality
- the separate AJAX states to be accessible to users (cross-browser, including IE)
- the separate AJAX states to be accessible to search engines as distinct 'pages'
The biggest thing, in my opinion, that is wrong with it is that it locks you in to using Javascript to serve pages linked by that URL.
The anchor in a URI is interpreted by the browser, not the server (in fact, that part of the url isn't even sent to the server), so once you go that route, you can never go back to non-javascript populated pages (without at least keeping javascript around to handle the redirects).
I also think it's lazy. There are dozens of other ways to accomplish the same goal that don't rely on a client-side implementation to serve your content.
posted by toomuchpete at 4:52 PM on May 31, 2011 [4 favorites]
The anchor in a URI is interpreted by the browser, not the server (in fact, that part of the url isn't even sent to the server), so once you go that route, you can never go back to non-javascript populated pages (without at least keeping javascript around to handle the redirects).
I also think it's lazy. There are dozens of other ways to accomplish the same goal that don't rely on a client-side implementation to serve your content.
posted by toomuchpete at 4:52 PM on May 31, 2011 [4 favorites]
Oddly, I just read Dan Webb's blog entry about hashbangs in URIs today:
posted by Brian Puccio at 5:03 PM on May 31, 2011 [1 favorite]
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.There's much more in his blog entry, I don't want to quote the entire thing here, read it there. Also, the part about always answering with an HTTP 200, good point there, too.
posted by Brian Puccio at 5:03 PM on May 31, 2011 [1 favorite]
Response by poster: TooMuchPete: What are some of the dozens of ways to accomplish the same goal that don't rely on a client side implementation?
Brian: Yeah, I had read Dan Webb's blog entry. I wouldn't regard it as non-technical though.
posted by jedro at 5:11 PM on May 31, 2011
Brian: Yeah, I had read Dan Webb's blog entry. I wouldn't regard it as non-technical though.
posted by jedro at 5:11 PM on May 31, 2011
Oops, didn't answer all your questions. As to the business needs, there's no reason that you can't "include AJAX functionality" (Danger! PHB-oriented too-broad-of-a-phrase warning!) while making it accessible in all states to all users (including those stuck on IE6 by making sure your AJAX gracefully degrades) and accessible to search engines as distinct pages. I think what you're asking is if you can move over every single piece of navigation to a AJAX call. There's a big difference between "including AJAX functionality" which might be as simple as a gracefully degrading slide show of product photos and "including AJAX functionality" by putting their entire URI paradigm on its side.
If anything, using hashbangs everywhere would be counter to what you're trying to do since example.com/products#producta and example.com/products#productb are the same page, just different parts of it. The Google Docs on the entire AJAX navigation issue allow for handling this in a particular way. But if Google changes their mind in 10 years, or worse yet, becomes completely irrelevant and some new search engine unseats them, you're still redoing all of your URIs to the new way to make them all search engine friendly. In terms of a business arguments, you'd have to find how many search engines spider 100% AJAX navigation sites the Google way and how many don't and figure out how many of your visitors have come from the latter category and if it's worth losing them.
(While you're at it, figure out how many potential customers use a screen reader and figure out if you're WAI/Sec508 OK.)
And, on preview, in response to your "it's not non-technical" -- it's the internet, it's technical. PHBs may not like it, but making a website and planning for the next decade is technical. And while it has technical underpinnings, the idea of every URL on your site breaking in 2 years because you decided to move away 100% AJAX navigation, that's a business argument. As is being locked into the technology forever.
Put simply, what's the business gain for having 100% AJAX navigation? What does the business get? And what does it stand to lose? And what's the business gain for being WAI/Sec508 compliant? More sales from people who are differently abled? And what's the business stand to lose for that? And what does the business stand to gain by having the website professionally translated into a few other languages? And what does it stand to lose? If I were a business and I could choose to update my site to 100% AJAX navigation or any of the things I've mentioned above, I'd be hard pressed to see the business reason that 100% AJAX navigation would bring me more clients. (There's tons of neato tricks you can do with your web server to make sure page loads are practically instant without resorting to URI trickery, make sure you've exhausted those first.)
(I'm not saying get rid of all AJAX. There's tons of pre-caching things you can do and navigation you can make better with AJAX without jumping to complete AJAX navigation.)
posted by Brian Puccio at 5:27 PM on May 31, 2011 [1 favorite]
If anything, using hashbangs everywhere would be counter to what you're trying to do since example.com/products#producta and example.com/products#productb are the same page, just different parts of it. The Google Docs on the entire AJAX navigation issue allow for handling this in a particular way. But if Google changes their mind in 10 years, or worse yet, becomes completely irrelevant and some new search engine unseats them, you're still redoing all of your URIs to the new way to make them all search engine friendly. In terms of a business arguments, you'd have to find how many search engines spider 100% AJAX navigation sites the Google way and how many don't and figure out how many of your visitors have come from the latter category and if it's worth losing them.
(While you're at it, figure out how many potential customers use a screen reader and figure out if you're WAI/Sec508 OK.)
And, on preview, in response to your "it's not non-technical" -- it's the internet, it's technical. PHBs may not like it, but making a website and planning for the next decade is technical. And while it has technical underpinnings, the idea of every URL on your site breaking in 2 years because you decided to move away 100% AJAX navigation, that's a business argument. As is being locked into the technology forever.
Put simply, what's the business gain for having 100% AJAX navigation? What does the business get? And what does it stand to lose? And what's the business gain for being WAI/Sec508 compliant? More sales from people who are differently abled? And what's the business stand to lose for that? And what does the business stand to gain by having the website professionally translated into a few other languages? And what does it stand to lose? If I were a business and I could choose to update my site to 100% AJAX navigation or any of the things I've mentioned above, I'd be hard pressed to see the business reason that 100% AJAX navigation would bring me more clients. (There's tons of neato tricks you can do with your web server to make sure page loads are practically instant without resorting to URI trickery, make sure you've exhausted those first.)
(I'm not saying get rid of all AJAX. There's tons of pre-caching things you can do and navigation you can make better with AJAX without jumping to complete AJAX navigation.)
posted by Brian Puccio at 5:27 PM on May 31, 2011 [1 favorite]
Response by poster: Thanks for the thought out answer Brian. I definitely don't want to make the entire site AJAX-based. In fact, the majority of the site will be implemented as distinct pages.
However, there are a number of interactions where AJAX makes sense - most of the page is staying the same, but a small amount of important content is changing. In fact, the content is important enough that users may wish to access it directly via a search engine.
posted by jedro at 5:39 PM on May 31, 2011
However, there are a number of interactions where AJAX makes sense - most of the page is staying the same, but a small amount of important content is changing. In fact, the content is important enough that users may wish to access it directly via a search engine.
posted by jedro at 5:39 PM on May 31, 2011
Sure, but hashbangs are just a way to fill a page. Nothing requires you to change your URLs in order to use AJAX anywhere else you want, including filling miscellaneous boxes with updating content, except the hashbang URL scheme itself.
posted by rhizome at 5:57 PM on May 31, 2011
posted by rhizome at 5:57 PM on May 31, 2011
There's nothing wrong with them, particularly if you're using them to store temporary state. Things like sort order or page number on an ajax-powered table.
posted by Civil_Disobedient at 6:13 PM on May 31, 2011
posted by Civil_Disobedient at 6:13 PM on May 31, 2011
The simple answer requires you to answer one not-so-simple question - Do you want your "page" to feel like a web page, or like a thin-client application?
If the former, don't use them. If the latter, feel free to do whatever the Hell you want. Really that easy.
Personally (as someone forced to make the same decision on a daily basis), when writing "web pages" with just a hint of server-side interactivity, I try to make them behave like the user would expect, and keep it clean. When writing "real" code, however, I tend to view the browser as nothing more than Yet-Another-Window-Manager to abuse as I want (and thank Zeus for HTML5, woo-hoo!).
Keep in mind that if you don't make it look and feel like a "proper" web page, most users (geeks don't count here) won't have even the slightest notion of whether it runs locally or in a browser. That can work both to your advantage and your detriment.
posted by pla at 6:46 PM on May 31, 2011 [1 favorite]
If the former, don't use them. If the latter, feel free to do whatever the Hell you want. Really that easy.
Personally (as someone forced to make the same decision on a daily basis), when writing "web pages" with just a hint of server-side interactivity, I try to make them behave like the user would expect, and keep it clean. When writing "real" code, however, I tend to view the browser as nothing more than Yet-Another-Window-Manager to abuse as I want (and thank Zeus for HTML5, woo-hoo!).
Keep in mind that if you don't make it look and feel like a "proper" web page, most users (geeks don't count here) won't have even the slightest notion of whether it runs locally or in a browser. That can work both to your advantage and your detriment.
posted by pla at 6:46 PM on May 31, 2011 [1 favorite]
If you do the AJAX hashbang stuff, make sure to handle every error condition properly. I don't know how many times I've clicked on the next page link in Digg (for example) and just had... it... spin... out. User interface locked up, so I can't retry. Only hope is to reload the page and hope I can get back to where I was.
Or, more likely, I give up and go to another site.
Why does this happen? Because the server didn't respond or responded with an error and Digg didn't take the time to reset the interface/retry the request/notify the user on all errors. They just silently swallow it. I'm picking on Digg, but I've seen the same thing on almost every damn AJAX site I visit and it's frustrating. At least with plain old URLs the browser will give me some error page and I know how to retry the request.
GMail is the exception. Google has gone to great lengths to make sure the UI updates for what's happening in AJAX land. I may get the "Retrying request in 60sec" notification, but at least I know what's going on.
posted by sbutler at 7:10 PM on May 31, 2011 [1 favorite]
Or, more likely, I give up and go to another site.
Why does this happen? Because the server didn't respond or responded with an error and Digg didn't take the time to reset the interface/retry the request/notify the user on all errors. They just silently swallow it. I'm picking on Digg, but I've seen the same thing on almost every damn AJAX site I visit and it's frustrating. At least with plain old URLs the browser will give me some error page and I know how to retry the request.
GMail is the exception. Google has gone to great lengths to make sure the UI updates for what's happening in AJAX land. I may get the "Retrying request in 60sec" notification, but at least I know what's going on.
posted by sbutler at 7:10 PM on May 31, 2011 [1 favorite]
i consider hashbangs sort of the frameset of 2011
posted by the noob at 7:24 PM on May 31, 2011 [4 favorites]
posted by the noob at 7:24 PM on May 31, 2011 [4 favorites]
Also, you break a lot of the stuff that other people are trying to build that may use your pages. And it makes us crazy. Not that that should be your number one concern! But that's a business concern: outside products and services that want to incorporate lots of the web can't always handle hashbang (non)architecture.
posted by RJ Reynolds at 8:00 PM on May 31, 2011
posted by RJ Reynolds at 8:00 PM on May 31, 2011
Response by poster: I know it's not using hashbangs, but Github's tree slider seems to tick all the boxes.
Works cross browser (although not AJAXy in some browsers)
Can link to any state
Appears to be indexable, with distinct 'page titles'
posted by jedro at 9:34 PM on May 31, 2011
Works cross browser (although not AJAXy in some browsers)
Can link to any state
Appears to be indexable, with distinct 'page titles'
posted by jedro at 9:34 PM on May 31, 2011
Response by poster: To expand on my previous post, Github seems to offer the following
- AJAX style interaction on modern browsers
- Degrades gracefully on lesser browsers (eg. IE), so that each interaction goes to a new page
- URL for a single page/state is the same, regardless of AJAX or standard page load interaction
- Ability to link to any state/page
- Appears to be indexable, with distinct 'page titles'
posted by jedro at 9:43 PM on May 31, 2011
- AJAX style interaction on modern browsers
- Degrades gracefully on lesser browsers (eg. IE), so that each interaction goes to a new page
- URL for a single page/state is the same, regardless of AJAX or standard page load interaction
- Ability to link to any state/page
- Appears to be indexable, with distinct 'page titles'
posted by jedro at 9:43 PM on May 31, 2011
What are some of the dozens of ways to accomplish the same goal that don't rely on a client side implementation?
It depends on your architecture and other technical details, but what it comes down to is that hashbangs are good for UI statefulness -- which column in a table is the sort table, which tab in a tabbed dialog is selected, etc. In terms of what content goes on the page, it makes the most sense for that to be a part of the URL proper.
One way for that to happen, is to map a collection of URL's to one script file. For example, your mefi profile page is: http://www.metafilter.com/user/12664
There's no file on the server called '12664' in a 'user' folder. Essentially, URLs that match the form /user/______ are all served by one particular script (some sites make ALL URLs served by the same file -- this is known in MVC world as a 'Front Controller Pattern').
Frankly, I'm still trying to figure out what advantage there is to this hashbang nonsense. It's ugly, it removes future non-javascript compatibility, it wreaks havoc on some browsers, it's more difficult to handle errors... all for what?
posted by toomuchpete at 6:54 AM on June 1, 2011 [1 favorite]
It depends on your architecture and other technical details, but what it comes down to is that hashbangs are good for UI statefulness -- which column in a table is the sort table, which tab in a tabbed dialog is selected, etc. In terms of what content goes on the page, it makes the most sense for that to be a part of the URL proper.
One way for that to happen, is to map a collection of URL's to one script file. For example, your mefi profile page is: http://www.metafilter.com/user/12664
There's no file on the server called '12664' in a 'user' folder. Essentially, URLs that match the form /user/______ are all served by one particular script (some sites make ALL URLs served by the same file -- this is known in MVC world as a 'Front Controller Pattern').
Frankly, I'm still trying to figure out what advantage there is to this hashbang nonsense. It's ugly, it removes future non-javascript compatibility, it wreaks havoc on some browsers, it's more difficult to handle errors... all for what?
posted by toomuchpete at 6:54 AM on June 1, 2011 [1 favorite]
(And let's all just pretend like I didn't add an extra apostrophe after 'URL')
posted by toomuchpete at 6:54 AM on June 1, 2011
posted by toomuchpete at 6:54 AM on June 1, 2011
Github could be using hijax:
posted by kirkaracha at 7:50 AM on June 1, 2011
- First, build an old-fashioned website that uses hyperlinks and forms to pass information to the server. The server returns whole new pages with each request.
- Now, use JavaScript to intercept those links and form submissions and pass the information via XMLHttpRequest instead. You can then select which parts of the page need to be updated instead of updating the whole page.
posted by kirkaracha at 7:50 AM on June 1, 2011
A URL should be have a simple meaning:
posted by blue_beetle at 9:26 AM on June 1, 2011
Your data is located here.but hash-bangs mean:
Go here and we'll (probably) get the data for you.More levels of indirection mean more chances for something to fail.
posted by blue_beetle at 9:26 AM on June 1, 2011
Best answer: As far as I know, Github is using pjax.
posted by cardioid at 3:28 PM on June 1, 2011 [1 favorite]
posted by cardioid at 3:28 PM on June 1, 2011 [1 favorite]
nthing blue_beetle's comment: A URL is a Uniform Resource Locator. It is (or should be) a human readable, unchanging pointer to a piece of content. The stuff after the hashmark is still part of the URL, but it's meant to point to a piece of content within a larger document; if that matches your use case, go with that. If not, I'd jettison that as a workable solution.
I don't know the details of the search engine tweaking, but my suspicion is that you can't (or will have significant trouble with) indexing hashbang'd ajax calls. Sites that make significant use of hashbangs, such as gizmodo, usually offer a parallel url schema that lets you access an article directly with a "normal" url. It's this parallel route that search engines index.
If I had to make a recommendation, it would be to adopt GitHub's mechanism: For browsers that support the HTML5 Browser History API, allow life refreshing of a page while changing the URL path. Otherwise, reload the entire page. At this point, every leading-edge browser except IE9 supports the HTML5 API, and I would expect IE10 to support it. Until then, this is progressive enhancement at its best.
posted by TeslaNick at 10:37 AM on June 2, 2011
I don't know the details of the search engine tweaking, but my suspicion is that you can't (or will have significant trouble with) indexing hashbang'd ajax calls. Sites that make significant use of hashbangs, such as gizmodo, usually offer a parallel url schema that lets you access an article directly with a "normal" url. It's this parallel route that search engines index.
If I had to make a recommendation, it would be to adopt GitHub's mechanism: For browsers that support the HTML5 Browser History API, allow life refreshing of a page while changing the URL path. Otherwise, reload the entire page. At this point, every leading-edge browser except IE9 supports the HTML5 API, and I would expect IE10 to support it. Until then, this is progressive enhancement at its best.
posted by TeslaNick at 10:37 AM on June 2, 2011
« Older Old technology filter: Zip disk stuck in drive | I've been in more laps than a napkin. Newer »
This thread is closed to new comments.
posted by Rhaomi at 4:31 PM on May 31, 2011