Shebang. It's called a shebang.
Hashbang URIs Aren't as Bad as You Think
11–20 of 46 posts
Re: Hashbang URIs Aren't as Bad as You Think
#12Large/lots of javascript files can slow down the loading of the page, but that wasn't the real issue people were taking with JS-controlled sites (as I interpreted things). The real delay cost was from the inevitable redirect to the root of the website. When you visit domain.com/user-name, a JS-controlled site will usually redirect you to domain.com#!/user-name, and then loading up the page. There is no avoiding this…
Such a redirect isn't slow? It's near instant if done right.
Here's twitter doing it: http://twitter.com/bjorntipling
It's absolutely super fast for me. How is that a 'kicker'?
Large JS files only need to be downloaded once and are cached.
There's no problem here.
Re: Hashbang URIs Aren't as Bad as You Think
#13Hear 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.
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 engine that happens to run over HTTP.
Re: Hashbang URIs Aren't as Bad as You Think
#14Much of the speed increase (assuming fast and properly cached server) can come from the decreased need to repaint the entire DOM. For my site, this is a big deal.
Re: Hashbang URIs Aren't as Bad as You Think
#15Large/lots of javascript files can slow down the loading of the page, but that wasn't the real issue people were taking with JS-controlled sites (as I interpreted things). The real delay cost was from the inevitable redirect to the root of the website. When you visit domain.com/user-name, a JS-controlled site will usually redirect you to domain.com#!/user-name, and then loading up the page. There is no avoiding this…
Such a redirect isn't slow? It's near instant if done right. Here's twitter doing it: http://twitter.com/bjorntipling It's absolutely super fast for me. How is that a 'kicker'? Large JS files only need to be downloaded once and are cached. There's no problem here.
> Such a redirect isn't slow? It's near instant if done right. Here's twitter doing it: http://twitter.com/bjorntipling
On slower devices (such as mobile phones) redirecting can be more noticeable. You're right though, in general it's not really a problem, but might be more so than a larger-than-normal JS file.
> Large JS files only need to be downloaded once and are cached.
Yeah, I was trying to say that. Larger JS files aren't a problem at all; load them once and they're cached.
Re: Hashbang URIs Aren't as Bad as You Think
#16Earlier 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…
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.
Re: Hashbang URIs Aren't as Bad as You Think
#17I 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.
Re: Hashbang URIs Aren't as Bad as You Think
#18Earlier 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.
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.
Re: Hashbang URIs Aren't as Bad as You Think
#19I 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).
Re: Hashbang URIs Aren't as Bad as You Think
#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.
So, these URLs are still as bad as I think.
Do you know the old joke about Java where people can't by hammers anymore, but need to buy a HammerFactory to produce hammers for them (and then HammerFactoryFactory etc.). Requesting a page that then requests the right content from the server just feels like an unnecessary Factory step.