Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hashbang URIs Aren't as Bad as You Think

mtrpcic.net

Post reply on HN
Print view View original

21–30 of 46 posts

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

#21

Post by andymism »

simonw wrote: post #18
burgerbrain wrote: post #16

Earlier quoted context omitted.

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.

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.

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?

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

#23

Post by andymism »

skybrian wrote: post #17

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.

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

#24

Post by simonw »

andymism wrote: post #21
simonw wrote: post #18

Earlier quoted context omitted.

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.

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

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.

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

#25

Post by mtrpcic »

perlgeek wrote: post #20

> 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 treating your browser as an API consumption service, and treating it as you would any other application. This isn't necessarily a bad thing, but does have drawbacks.

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

#26

Post by mtrpcic »

jmah wrote: post #22

A better approach in all ways is to use the HTML5 history API, a la GitHub. https://github.com/blog/760-the-tree-slider

The article makes mention that the example doesn't use the HTML5 History API, and that the onus is on the developer to check for and use that as appropriate.

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

#27

Post by burgerbrain »

simonw wrote: post #18
burgerbrain wrote: post #16

Earlier quoted context omitted.

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.

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.

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

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

#28

Post by ptarjan »

zalew wrote: 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.

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

#29

Post by prodigal_erik »

farlington wrote: post #8

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.

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

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

#30

Post by stylejam »

burgerbrain wrote: post #16
simonw wrote: 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…

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.

I agree 100%.
Post reply on HN