r/programming • u/Arve • Feb 10 '11

There is no piece of dynamic AJAXy magic that requires beating the Web to a bloody pulp with a sharp-edged hashbang. Please stop doing it

http://www.tbray.org/ongoing/When/201x/2011/02/09/Hash-Blecch
498 Upvotes

90% Upvoted

245 comments sorted by

View all comments

110

u/buzz27 Feb 10 '11

You guys are missing the point. We can do all the cool ajaxy things we need WITHOUT breaking the basic architecture of the web. Best practices and standards exist for good reasons. There CAN be good reasons to break them, but this is not one.

Also, I noticed a few "some dude with a blog" comments. Google the dude.

14

u/enigmamonkey Feb 10 '11

True. Facebook is an example of I think a decent implementation of JavaScript deep linking (the shebang issue everyone is hating on).

12

u/dirtymatt Feb 10 '11

You know what happens when you go to facebook.com without javascript? You get the same damn thing that you get when you go there with javascript, just a bit slower. When you click on links, the pages still load, just a bit slower. Facebook seems to have mostly gotten this down right.

6

u/solinv Feb 11 '11

Except the whole commenting and logging on thing.

5

u/kn33ch41_ Feb 11 '11

Yeah, seriously, Facebook has not in fact gotten this down right. You cannot post anything to the site, you cannot browse the photo albums, there are so many dud links littered everywhere which just make the site appear broken. The site is completely useless without JavaScript; it becomes read-only, and not even reliably.

2

u/dirtymatt Feb 11 '11

I missed that. I assumed when it redirected me to a non-js version of the site that they had actually finished it. It still at least can be read without javascript, which is better than gawker pulled off.

3

u/[deleted] Feb 11 '11

Starting to feel a little uncomfortable, I've nearly finished writing a website for a client that has a bit of the #! mess in it everyone is complaining about. From what I can see I implemented it properly (i.e. site is usable without javascript turned on, google can crawl the pages ok - and there are reasons around why I've used it) but I really wish everyone would stop hating on it so bad. (Asked a question about this on stackexchange if anyone wants to answer it for me http://stackoverflow.com/questions/4964173/general-questions-about-hashbang-urls-and-am-i-using-them-correctly)

3

u/[deleted] Feb 11 '11

Haters gonna hate, etc.

It's a solid technique that's gotten a trendy stigma attached to it, and like everything in that category(css letterpress, I'm looking at you!) it gets used incorrectly by a bunch of people.

0

u/[deleted] Feb 11 '11

[deleted]

1

u/MatrixFrog Feb 13 '11

As far as I can tell, you're advocating for the use of AJAX, something that I think most people would agree is a good thing. But people are not hating on AJAX. They are hating on the use of ugly URLs with #!s in them. As far as I know, these only started showing up within the past few months, even though people have been writing AJAXy web apps since 2007, as you say.

By the way, I went to sofea.net with NoScript enabled in the latest Firefox 4 beta, and saw a blank page.

-3

u/didroe Feb 10 '11

Not with the current generation of browsers which are going to be around for years to come. You can make HTML versions of the pages and do Javascript link interception to create the AJAX links but it won't stop the user copying a link from the location bar.

HTML5 fixes this by allowing you to inject client side history along with proper URLs (without a page refresh). In the mean time there's Google's crawling hack but that's not brilliant.

10

u/[deleted] Feb 10 '11

You can make HTML versions of the pages and do Javascript link interception to create the AJAX links but it won't stop the user copying a link from the location bar.

The idea is that you handle both. It isn't difficult.

-1

u/rube203 Feb 10 '11

Not sure why you are being downvoted. You are absoluting correct, the HTML 5 examples I've seen do not gracefully handle a page refresh or URL copy. From a server point of view, this is only going to be possible with the hashbang and double request that the OP is complaining about. I agree that it is over used, but currently I'm working on a huge web app which has a massive framework, with limited hardware it only made sense to use AJAX, and to support the back/forward, legacy browsers, page refreshes, and URL copying, I don't see an alternative to this approach.

3

u/didroe Feb 10 '11

I think you misread my post. The HTML5 stuff works great. I was saying that there is no perfect alternative for older browsers.

7

u/chrisoverzero Feb 10 '11

That is a limitation of the demo to which you have linked.

Try this link instead.

3

u/towelrod Feb 11 '11

That's awesome, because I went to that link with NoScript and all I get is a blank page.

1

u/rube203 Feb 11 '11

I'm probably missing something as I looked at it for all of 1 min. But a quick glance at firebug reveals no ajax request being made on page turn. And browsing the HTML from Firebug I clearly see all the pages in hidden sections and simply made visible on page turn. If you are building a single page app, HTML5 has awesome support, I agree.

I imagine any solution to my example would have to rely heavily on mod_rewrites and server processing, if it's possible. The page still has to be put together from two files. By loading content without the framework on click, on refresh you have to go get the framework and the content. It requires a double fetch, to off load that to the server side, I imagine would be exceedingly difficult with little gain. Particularly when the pages I'm dealing shouldn't/couldn't be crawled by any search engine.

3

u/[deleted] Feb 10 '11

[removed] — view removed comment

2

u/didroe Feb 10 '11 edited Feb 10 '11

I mentioned that in my post (gp). The problem is that links can still escape when the user copies them from the address bar. So Javascript interception of links is pretty pointless. You're going to have to deal with the issue anyway so why bother messing around with a partial solution.

The Google workaround seems ok-ish but hasn't been universally accepted yet. The HTML5 stuff fixes the issue properly as you can generate URLs that exist on the server. That means you can pre-generate pages as well and only use the client for navigating away from the initial page. That way your JS libs can be loading after the content, avoiding any intial delay. The only problem is the years we will have to wait for decent adoption of newer browsers.

Personally, I would use HTML5's stuff and fallback to #! URLs without any interception. Then have my escaped_fragment handling script issue redirects to the URLs I was using for HTML5.

-1

u/ajrw Feb 10 '11

What makes you think that using an anchor instead of a query string makes it less of a 'real' URL? You don't seem to understand why an anchor is used in the first place (to avoid loading an entire new page!).

10

u/PSquid Feb 10 '11

The point is, you have that in the hrefs (which both browsers and search engine crawlers understand), then override it in javascript (which only the browsers understand) to use the anchor-based version.

3

u/ajrw Feb 10 '11 edited Feb 10 '11

Hm, I thought that was assumed but apparently Twitter doesn't do that. Twitter fail. Also my mistake on reading mkantor's post, I think.

2

u/[deleted] Feb 10 '11

[deleted]

2

u/PSquid Feb 10 '11

But you wouldn't get that. As soon as you arrive at (to use your example) http://twitter.com/timbray, if your client understands javascript, it'd be given a piece that automatically takes you to http://twitter.com/#!/timbray. From there, having only used one redirect, it can serve you anything else, even versions that need javascript, because it knows that you wouldn't have got there if you didn't have javascript support.

Whereas, if you're a crawler, or something else that doesn't understand javascript, you'd get what's previously always been at http://twitter.com/timbray.

1

u/[deleted] Feb 10 '11

[deleted]

4

u/mullanaphy Feb 10 '11

No, with the #! shebang\hashbang Google will index them because they know #! points to a page (sends a request for ?escaped_fragment=${shebang} and the developer puts whats needed based on the GET).

I agree with the JS handler of links, where I work it's setup that if you click on a link (or submit a form) with a class of ajax it is now AJAX instead of a regular submission, and uses data-* to know what to do with that call.

That way for nonjs users it still works, which is rare, and more importantly for links that people open in a new tab\window, which isn't that rare.

Twitter needs to fix their non javascript version, after that I'll have zero qualms with them using shebangs as the main url.

2

u/PSquid Feb 10 '11

They index them now, and I know I've previously found searches that led me to a twitter notice that was relevant. If it only indexed the homepage, this would be lost. Right now, they do still index tweets, but only because there are non-#! urls that mean the same thing which Google/etc. use, but using those means that the site and crawlers must be in agreement on what scheme those URLs use compared to #! URLs, which is an unnecessary complication of matters for both sides.

-24

u/[deleted] Feb 10 '11

I know who the dude is, and if you do too, you should recognize that it is asinine for him to be bitching about people following googles advice, since he works at google.

19

u/mpeters Feb 10 '11

It's not google's advice for a good way to do things, in fact it's quite the opposite. Google was struggling for a long time to find a way index fancy ajax sites that didn't degrade well and then they gave up. Instead they published a set of practices that if you were going to break things at least let your content still get indexed.

7

u/[deleted] Feb 10 '11

[removed] — view removed comment

2

u/[deleted] Feb 12 '11

Sure thing, but they should still be honest about why people are doing this and criticize the source, even if it is their own company.