I think the whole method that these sites use to deliver content is completely backwards, at least from the user perspective.
The goal of going to a web site is ultimately to get the content you are looking for. If you're going to Twitter, it's to read someone's twitter stream, etc.
The way these hashbang sites function is to display the least-relevant (to the user) information first, all the chrome and ads of the page. Then, when all the stuff you don't actually care about is done rendering, only then does it go and get the content you came to see.
This drives me nuts as a user. It is particularly annoying on slower devices, such as Edge or 3G smartphones, where you see the lag even more strikingly.
From a user-experience, content-oriented framework, this entire architecture should be reversed. The URI should point to the content, not the presentation as it does with Hashbang. The content should be served first, in a readable format, and then the javascript magic should kick in, download all the chrome in the background and then update the page once with all the other elements.
If you're going to have your page do a secondary load anyway (as hashbang does now) you might as well make the content the front-and-center part.
> If you're going to Twitter, it's to read someone's twitter stream, etc.
You may be interested in the twitter-like website I'm currently developing. It currently uses no JS at all (it will do so, for e.g. writing new messages, but the entire functionality will work without JS).
The goal of going to a web site is ultimately to get the content you are looking for. If you're going to Twitter, it's to read someone's twitter stream, etc.
The way these hashbang sites function is to display the least-relevant (to the user) information first, all the chrome and ads of the page. Then, when all the stuff you don't actually care about is done rendering, only then does it go and get the content you came to see.
This drives me nuts as a user. It is particularly annoying on slower devices, such as Edge or 3G smartphones, where you see the lag even more strikingly.
From a user-experience, content-oriented framework, this entire architecture should be reversed. The URI should point to the content, not the presentation as it does with Hashbang. The content should be served first, in a readable format, and then the javascript magic should kick in, download all the chrome in the background and then update the page once with all the other elements.
If you're going to have your page do a secondary load anyway (as hashbang does now) you might as well make the content the front-and-center part.