[farlington]

Hear hear.

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.

Plus the whole anti-hashbang thing has a reactionary air to it.

[prodigal_erik]

"Web app" is a misnomer. If the content isn't browsable hypertext, it has abandoned the Web and stepped backwards into the ghetto of siloed client/server apps that were deservedly hated in the 90s. And the industry has yet to deliver a trustworthy js sandbox that can safely run any code it happens to find anywhere—the majority uses the defaults because they don't know how reckless those defaults are.

[farlington]

Thanks for this response, it's really thought provoking. I have a few questions:

'The ghetto of siloed client/server apps'? Would those be like ActiveX controls and Java applets? Isn't JavaScript fundamentally different?

Does the definition of 'browsable hypertext' preclude hypertext that's scripted to operate differently, e.g. 'ajax'? Are you not still 'browsing hypertext'?

The industry has yet to deliver a trustworthy js sandbox—should browsers not support JavaScript?

[prodigal_erik]

By siloed I was referring to all the VB-style apps that predated widespread use of the Web. You had to use a single mediocre client app because it was the only piece of code in existence that could support the proprietary protocol for the matching server. Lock-in was rampant and building a better client or repurposing the data in any way was almost impossible.

Now we have servers that may technically still be talking XML or JSON or something over HTTP, but it might as well be an opaque proprietary protocol, because there's only one piece of code in existence (the javascript embedded in some page) that knows how to send meaningful requests to the server or decode its responses. The protocol isn't even stable enough to reverse-engineer because the author can make arbitrary changes to it and migrate everyone to an updated version of their client code at any moment. I find this vastly inferior to query strings, multipart/form-data, and scrapable semantic HTML, which a growing number of web devs completely neglect (none of whom I'd ever hire).

> should browsers not support JavaScript?

They shouldn't run it by default without asking whether the user trusts the author. Privacy violations are rampant and even malicious scripts have become a recurring problem. I don't see why a sandbox that works shouldn't be possible, but it hasn't happened yet.

[mtrpcic]

That's the thing. When you're making something on the web, you need to define to yourself whether it's a Web Application or a Web Site. The hashbang approach lends itself very well to the Application side of the browser.

[simonw]

The difference between a web site and a web application isn't binary. Modern web sites increasingly blur the lines between the two.

Hashbang URLs are bad because they damage the addressability of the Web. If I can't take a URL, telnet to port 80, run GET /path and get back a representation of the thing that the URL points to, that URL isn't really part of the Web - it's part of a JavaScript application delivery engine that happens to run over HTTP.

[burgerbrain]

Here's the thing: I don't hate hashbang URLs, I hate [site]'s use of hashbangs URLs. One example of [site] that stands out in particular is lifehacker. Why in the world does a blog need that? There isn't a good reason.

I don't think anybody opposes it in cases where it actually makes sense, but I assert that the dividing line is pretty clear.

[simonw]

Do you mean the dividing line between web sites and web applications?

How would you categorise Flickr, or YouTube, or Wikipedia, or Yelp, or Lanyrd, or Craigslist - or pretty much any other UGC site? I'd argue that all of them could be described as both.

[andymism]

The distinction between web sites and web applications is not granular enough to make this decision. What you should be considering as a developer/designer of a web site/app is not about what bucket Flickr or YouTube or Yelp falls into, but what specific screens should be accessible with shebangs and which screens should not.

Flickr's photo indexes and Yelp's listings and reviews should probably be accessible via regular old URLs. But Flickr's uploader screen? Adding a new listing to Yelp? If you're ok with leaving behind users who have javascript turned off, it simply _does_ _not_ matter. In those cases, why not take advantage of the snappy UX that shebanged interfaces offer?

[simonw]

That's true, to a point. My principle objections to hashbang URLs is greatly reduced for pages which people are never intended to link to - private "edit" interfaces protected by a login are a prime example.

Personally I'm not OK leaving behind non-JS users in my own development, but provided a site's public pages are accessible I'm not too bothered what they're doing when people log in.

[burgerbrain]

All of those are examples of websites that would or do suffer from excessive use of javascript.

[stylejam]

I agree 100%.

[jarin]

If you want to curl a hashbang URL (or access its content in some other non-Javascript-requiring way), there's a pretty easy way to do it. Just do the same thing Google does and remove the hashbang. It's like getting mad because you can't parse the XML you find at a JSON endpoint.

[Isofarro]

"If you want to curl a hashbang URL (or access its content in some other non-Javascript-requiring way), there's a pretty easy way to do it. Just do the same thing Google does and remove the hashbang."

Which command line option on curl does that? (Maybe they haven't updated the man page? http://curl.haxx.se/docs/manpage.html ).

Oh, if you reply, could you do it in the form of interpretative dance.

[jarin]

sed 's/#!\///g' urls.txt | xargs curl

Yeah, not that hard dude.

[Isofarro]

> sed 's/#!\///g' urls.txt | xargs curl

So easy, you've actually got it wrong.

Certain special characters after the hash-bang need to be url-encoded, and then that value needs to be added to what's before the #! by including a query string parameter of _escaped_fragment_, checking first whether there is already a query string so as to append the information rather than incorrectly whacking on a '?'.

Plus, this isn't in the form of interpretive dance. So no content for you.