On a related note, if this is a problem for you, now might be a good time to check your Expires headers. The 'some clients turn off caching' seems like a bit of a non sequitur too- some clients also have javascript disabled. Some clients are IE6. How many clients are like that in the wild? How many of /your/ users?
If your cache headers are set incorrectly, you should probably fix that instead of reworking your entire site.
Reddit.com HTML.: 37.6 KB Text in that HTML: 5.9 KB
(That's just what I got from copy+pasting.) The difference at issue is loading another 37.6 KB page versus loading whatever part of that 5.9 KB is the "interesting" text (i.e. probably not the header or footer) plus its links and styles and the overhead of whatever you want to stick it in (JSON, an HTML fragment, etc). The huge CSS and JS files are not reloaded every time you go to a new page.
> 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.
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.
They don't think this through as they don't use anything other than a modern web browser with javascript switched on.
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.
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 unless you want really ugly urls: domain.com/user-name#!/user-name...
So large JS files might increase the load speed slightly, but adding an entire redirect is the kicker.
Like most things, there's a time and a place. Using hashbang urls can increase response-time when navigating through a site and provide a really cool experience. On the other hand, it definitely doesn't work for all browsers and users.
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.
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.
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.
'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?
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.
We started using Google's ajax crawling spec. Whenever we see:
http://twitter.com/#!/ptarjan
http://twitter.com/?_escaped_fragment_=/ptarjan
//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.