Despite all the FUD around hashbangs, the genuine problem I see with them is that they optimise for internal page loads, not the entry into a website. For example with hashbangs, requests to twitter when logged in go like;
3) HTML tells browser to download some JS -> HTTP GET bundle.js [~500ms for me] (concurrently here we start getting CSS)
4) JS reads hashbang & request actual data -> HTTP GET data.json [~500ms for me]
... only after about 2 seconds can we start(!) rendering data. Now there's about another 2 seconds for all json data & CSS calls to complete. It takes upwards of 4 seconds for a twitter page to render for me (the Load event lies as it fires well before actual data shows. Try it yourself with your favourite browser inspector).
When not using hashbangs, a single HTTP request can get all the data for the page and start rendering it. One blocking CSS call (possibly cached) is all that's needed for styling.
Hence when I see an external link with a hashbang it frustrates me (barely perceptively) because I know that when I load the page it's going to take a longer than a normal HTTP request. Significantly longer. While subsequent page loads are faster, it's not these you want to optimise for if you care about bounce rates. This issue affects every new link you click into a website, so it affects an even larger number of requests than normal bounces.
Hashbangs are a good solution to an important problem, but I don't see them as a tool to build entire websites upon. Fortunately I see the performance issue as one which will result in people voting with their browsers and choosing sites which only use hashbangs when they genuinely improve the user experience - especially since they're easily visible in the url.
But once you do launch it, everything is faster than it would have been if you were performing full page loads at each step. For sites you "live" in, the application route makes a lot of sense. This is the way GMail works and people seem to like it a lot.
Unfortunately, web applications and web pages are growing increasingly divergent. It is simply not feasible to take the performance of web apps to the next level without doing away with full page loads. This is why Facebeook, Twitter et al are going the #! route. That's the cold hard truth.
You follow a canonical link to the resource, get a real page back, with real links, but js click handlers to enable AJAX-goosed speed for those with javascript enabled? And given that they imply a fallback for those times when javascript fails, aren't they actually better?
And GMail is a bit different than Twitter. It handles inward-facing data; content that no-one particularly wants crawled and wouldn't benefit much from caching.
Unless you want your URLs to look like twitter.com/someone#!someone_else, you're going to have to take the multi-step page load at some point when you transition from the HTML version to the AJAXy one.
Admittedly, you need a modern browser for that. But you can always present full-page-load HTML to users with older browsers and then provide AJAXy history-ified goodness to everyone else.
But Gmail is a webapp, not a website. You don't get a link to an email stored in Gmail. You can only access things once you're already inside.
Twitter is very different. If you're signing in yourself to update your own feed, that's one thing. But when you are trying to view the feed of someone else, that's a horse of a different color.
The question really is: should Twitter be an "app" or a "site"? If you allow links in from the rest of the web, it should be a "site".
Which sucks, because I frequently end up "launching" it by clicking a link to a Twitter profile or tweet on another site, so every few minutes I have to wait for the entire thing to load - and I often end up with a dozen tabs containing the Twitter app when all I really wanted was a few hundred bytes of HTML containing a single tweet!
Even with the assets cached, there's still an 8-10 second loading time (I just timed it). Compare that to a static HTML page showing the same content which would probably load and render in under a second.
Yea, in this case HTML/HTTP is being abused as wrapper around an app written in JavaScript, which loads and manipulates the content you see in your browser.
Hashbangs are a workaround. A good _solution_ would be something that doesn't require running JavaScript and doesn't mess with URL/document models most of the Web is based on.
For example, browsers could implement partial caching. Here is how it could work. The first time the browser requests a page, it gets all the content in the response. However, some fragments of the content are identified as cacheable and marked with unique ids. When a browser requests a page for the second time, it sends a list of identifiers for the cached fragments to the server. The server then doesn't render those fragments, but places small placeholders/identifiers where they should be substituted into page content.
---
First Request
GET index.html
---
First Response
[cacheable id="abc"]
[h1]This is twitter[/h1]
bla bla bla, header content
[/cacheable]
...
Page content
...
[cacheable id="xyz"]
footer content
[/cacheable]
1) HTTP GET http://twitter.com/some_account [~500ms for me]
2) 302 redirect -> HTTP GET http://twitter.com/ [~600ms for me]
3) HTML tells browser to download some JS -> HTTP GET bundle.js [~500ms for me] (concurrently here we start getting CSS)
4) JS reads hashbang & request actual data -> HTTP GET data.json [~500ms for me]
... only after about 2 seconds can we start(!) rendering data. Now there's about another 2 seconds for all json data & CSS calls to complete. It takes upwards of 4 seconds for a twitter page to render for me (the Load event lies as it fires well before actual data shows. Try it yourself with your favourite browser inspector).
When not using hashbangs, a single HTTP request can get all the data for the page and start rendering it. One blocking CSS call (possibly cached) is all that's needed for styling.
Hence when I see an external link with a hashbang it frustrates me (barely perceptively) because I know that when I load the page it's going to take a longer than a normal HTTP request. Significantly longer. While subsequent page loads are faster, it's not these you want to optimise for if you care about bounce rates. This issue affects every new link you click into a website, so it affects an even larger number of requests than normal bounces.
Hashbangs are a good solution to an important problem, but I don't see them as a tool to build entire websites upon. Fortunately I see the performance issue as one which will result in people voting with their browsers and choosing sites which only use hashbangs when they genuinely improve the user experience - especially since they're easily visible in the url.