Hashbang URIs Aren't as Bad as You Think

&#62; Now, take away the constant loading of the JavaScript and CSS, and you've significantly decreased bandwidth and server load<p>On a related note, if this is a problem for you, now might be a good time to check your Expires headers. The 'some clients turn off caching' seems like a bit of a non sequitur too- some clients also have javascript disabled. Some clients are IE6. How many clients are like that in the wild? How many of /your/ users?

<p><pre><code> &#62; If I have JavaScript enabled, and send my friend (who has &#62; JavaScript disabled) a "Hashbang" URI, he won't load the &#62; content! &#62; You're right. This is the primary drawback of an &#62; approach like this, and you'll need to figure out if &#62; that's acceptable for you. </code></pre> Simple answer: "no". It's not acceptable for me in any way. Not as a user, who disables JS by default (for speed, security and annoyance avoidance), and not as a site own either.<p>So, these URLs are still as bad as I think.<p>Do you know the old joke about Java where people can't by hammers anymore, but need to buy a HammerFactory to produce hammers for them (and then HammerFactoryFactory etc.). Requesting a page that then requests the right content from the server just feels like an unnecessary Factory step.

I'm not a fan of the hash-bang URLs, but I think this article largely misses the objections I (and many others) have to them. Nothing that he said is unique to hash-<i>bang</i> URLs; the same thing could be done with typical fragment identifiers, and indeed has been for ages. My objection to hash-bang urls <i>in particular</i> has nothing to do with using fragments to dynamically load content, which I think is a great idea. If you write your code like the article suggests, you'd be fine by me: he's taking a page which can be accessed by a non-js enabled browser and using js to modify the links so they load content dynamically. I can still look at that page with, say, wget or lynx and nothing would break. The Gawker redesign—and the whole hashbang scheme—requires any agent that doesn't execute js to <i>mangle the URL</i> in order to get at the static content. And that's the issue here—<i>forcing non-compliant agents to change</i> in order to do what they've always done runs in the face of the Robustness Principle. Hash-bang URLs are an non-elegant solution to a minor problem; use normal fragment identifiers for your Ajax instead.

Large/lots of javascript files can slow down the loading of the page, but that wasn't the real issue people were taking with JS-controlled sites (as I interpreted things).<p>The real delay cost was from the inevitable redirect to the root of the website. When you visit domain.com/user-name, a JS-controlled site will usually redirect you to domain.com#!/user-name, and then loading up the page. There is no avoiding this unless you want really ugly urls: domain.com/user-name#!/user-name...<p>So large JS files might increase the load speed slightly, but adding an entire redirect is the kicker.<p>Like most things, there's a time and a place. Using hashbang urls can increase response-time when navigating through a site and provide a really cool experience. On the other hand, it definitely doesn't work for all browsers and users.

Shebang. It's called a shebang.

Hear hear.<p>I can think of many cases where ajax loaded content and the attendant hashbang URLs are far preferable, like with twitter's web interface or with gmail. It just makes sense for web applications to work differently than static content, and persistent display of information often beats out clean looking URIs.<p>Plus the whole anti-hashbang thing has a reactionary air to it.

I wonder if anyone has tried this: suppose that to make page transitions faster, you strip out everything from each page other than the data itself? The page should just contain the main content (which would have to be fetched via AJAX anyway), and JavaScript can fill in things like sidebars and navigation.

A better approach in all ways is to use the HTML5 history API, a la GitHub.<p><a href="https://github.com/blog/760-the-tree-slider" rel="nofollow">https://github.com/blog/760-the-tree-slider</a>

I only wonder why websites who use it themselves, break other shebang urls when you post them - try sharing a twitter url on facebook (always have to strip the #!/ manually).

Much of the speed increase (assuming fast and properly cached server) can come from the decreased need to repaint the entire DOM. For my site, this is a big deal.