Live data from Hacker News

Hashbang URIs Aren't as Bad as You Think

mtrpcic.net

31–40 of 46 posts

Re: Hashbang URIs Aren't as Bad as You Think

#31
post #28
post #19

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).

I'm an engineer at Facebook. We started using Google's ajax crawling spec. Whenever we see: http://twitter.com/#!/ptarjan we actually crawl http://twitter.com/?_escaped_fragment_=/ptarjan Let me know if you notice any issues.

Oh, now it works and links fine! Tx for the update

//edit: btw, do you work with the new messages? I got an annoying bug there - as you type, often the cursor jumps to the end. annoying as hell when you edit sth in the middle of the sentence.

Re: Hashbang URIs Aren't as Bad as You Think

#33
post #13
post #10

Earlier quoted context omitted.

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.

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 engin…

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.

Re: Hashbang URIs Aren't as Bad as You Think

#34
post #25

> If I have JavaScript enabled, and send my friend (who has > JavaScript disabled) a "Hashbang" URI, he won't load the > content! > You're right. This is the primary drawback of an > approach like this, and you'll need to figure out if > that's acceptable for you. 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 no…

That's why this approach isn't for everyone. To each his own. One thing to keep in mind, however, is that the approach is meant more for projects that can be thought of as "web applications", rather than websites; things that would require JavaScript to be enabled to even work. Also, another way of thinking of it is to stop thinking of the browser as a browser. If you do the hashbang thing properly, you're now treati…

The problem is that - as Gawker have shown - people start thinking that techniques that might be acceptable for web apps are acceptable for content sites.

They don't think this through as they don't use anything other than a modern web browser with javascript switched on.

Re: Hashbang URIs Aren't as Bad as You Think

#35

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.

IIRC, Posterous does this as part of their caching strategy. Static content is HTTP cached and dynamic content is pulled in via AJAX on page load. The result is that the primary content is available fast and dynamic secondary information (such as view count, etc) pops in soon after.

Jolly good. A site that understands the concept of 'progressive enhancement'.

Re: Hashbang URIs Aren't as Bad as You Think

#36
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-bang URLs; the same thing could be done with typical fragment identifiers, and indeed has been for ages. My objection to hash-bang urls in particular 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 mangle the URL in order to get at the static content. And that's the issue here—forcing non-compliant agents to change 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.

Re: Hashbang URIs Aren't as Bad as You Think

#38

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- bang URLs; the same thing could be done with typical fragment identifiers, and indeed has been for ages. My objection to hash-bang urls in particular has nothing to do with using fragments to dynamically load content, which I think is a great idea. If yo…

"And that's the issue here—forcing non-compliant agents to change in order to do what they've always done runs in the face of the Robustness Principle."

You nailed it. Hashbang URLs are not backwards compatible with the existing World Wide Web. And existing tools that use the Web today, cannot in their current state use these hashbang frameworked sites in the same way.

As another commenter noted, hashbangs silo a site within a non-standard requirement. That approach explains why posts such as these overlook or ignore fundamental behaviour of the Web and how it brings together fragments of distributed conversation.

Hashbang URLs break the World Wide Web stack at the HTTP and URL levels, and attempt to fix the damage at the behaviour level. The fix is inferior, and results in breakage of the World Wide Web model (like framesets).

It's a technical implementation of a walled-garden. Walled off from the exisiting World Wide Web.

Re: Hashbang URIs Aren't as Bad as You Think

#39
post #33
post #13

Earlier quoted context omitted.

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 engin…

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.

"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.

Re: Hashbang URIs Aren't as Bad as You Think

#40
post #33

Earlier quoted context omitted.

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.

"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.

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

Yeah, not that hard dude.

Post reply on HN