Does nobody care that this makes the world-wide-web completely pointless from any perspective that isn't a web browser with JavaScript? I'm going to be royally pissed if I have to write from scratch an http library in C with JavaScript support just to make a friggin' scraper script or debug a website/webserver.<p>If you want to be annoyingly fancy with the way you deliver content, just do it to user agents that <i>support JavaScript</i>. For any other user agent just provide the actual content we wanted! To do this, all you have to do is <i>not use hash tags</i>. The URI can remain the same and the application will work just fine (JS can still check the friggin query uri and do any Ajax trickery it wants). Sometimes I think webapp designers are just trying to piss hackers off.<p>We'll ignore the fact that having to escape the bang is really annoying, considering the page is useless from the console anyway due to the aforementioned requirement of JavaScript.
At Cloudkick we use the hash bang on our new overview. The hash bang URI represents the application state or view. It is a UI tool that helps provides the user with an additional, browser friendly, means to navigate the application. The information in the hash bang is also private to the account and irrelevant to the public which can't access the same information. The URI portion without the hash bang is simply the application's address. The server doesn't need to know about application's UI, all it does is deliver the application. Many sites make the server part of the user facing application with server side templates and scripts but we are moving away from that. The UI will be in the client and server doesn't need to know about UI state. If your server is part of the UI then don't use the hash bang convention as the server can't make sense of it.
It's part of 2 general trends that are taking place recently.<p>1) A move away from server-side programming. Server is now used to serve static files and json data. Not to dynamically create pages. Application logic is not done in javascript.<p>2) The emergence of high-level javascript frameworks that do most of the blunt work. These frameworks are server-language agnostic and hence do all of the application scripting in browser. JQuery Mobile and Mobl come to mind here.
Great article. Recommends building on conventional hash-less URIs and using progressive enhancement e.g onClick handlers to implement hash-bang URIs.<p>Three particularly interesting ideas:<p>* sites should support the _escaped_fragment_ query parameter, the result of which should be a redirection to the appropriate hashless URI<p>* if you’re serving large amounts of document-oriented content through hash-bang URIs, consider swapping things around and having hashless URIs for the content that then transclude in the large headers, footers and side bars that form the static part of your site [can't envisage how this would work]<p>* "I suspect we might find a third class of service arise: trusted third-party proxies using headless browsers to construct static versions of pages without storing either data or application logic"
I think the whole method that these sites use to deliver content is completely backwards, at least from the user perspective.<p>The goal of going to a web site is ultimately to get the content you are looking for. If you're going to Twitter, it's to read someone's twitter stream, etc.<p>The way these hashbang sites function is to display the least-relevant (to the user) information first, all the chrome and ads of the page. Then, when all the stuff you don't actually care about is done rendering, only then does it go and get the content you came to see.<p>This drives me nuts as a user. It is particularly annoying on slower devices, such as Edge or 3G smartphones, where you see the lag even more strikingly.<p>From a user-experience, content-oriented framework, this entire architecture should be reversed. The URI should point to the content, not the presentation as it does with Hashbang. The content should be served first, in a readable format, and then the javascript magic should kick in, download all the chrome in the background and then update the page once with all the other elements.<p>If you're going to have your page do a secondary load anyway (as hashbang does now) you might as well make the content the front-and-center part.
I am hearing a lot of vitriol against the use of the hash uri (or hash-bang uri) pattern. While I agree that it does make a slightly different set of assumptions about the browser model, I don't think that application developers are employing it just because it is a " cool new thing".<p>In many cases, the hash-uri enables a new class of applications and system architectures that were not previously possible on the web. Naked (hash less) uri's require that all state transitions round-trip to the server. This isn't at all desirable if you want to support offline, or high latency (mobile) clients.<p>I am in agreement that we want to retain the link structure of the web. But we also do want to not freeze the application architecture of the web to 1997. I think this post had some great recommendations about implementing a hash-bang based site, and still "playing nice" with a diversity of client assumptions.
<i>Fragment identifiers are currently the only part of a URI that can be changed without causing a browser to refresh the page</i><p>This is actually the primary reason for most of the hash and hash-bang uris in today's javascript-heavy sites. Once all the popular browsers allow changing URI without reloading the page, the whole issue will become irrelevant.<p>I am actually a big fan of HTTP and REST (the real one, with HATEOAS), but browsers have a long history of making it hard to write RESTful web sites. HTTP methods had long been restricted to GET/POST; code-on-demand support before XHR had been very rudimentary (javascript was almost useless, and I don't even want to mention java applets); browser addressing conventions led to horrible (from the REST point of view) practices like redirect-after-POST etc.
Good article. Although instead of writing "A browser that doesn’t support Javascript ..." (implying some failure or deficiency in the browser) he might have written "For users who selectively disable Javascript ..."