YES!
For anyone with a high latency (huge swathes of the US are still stuck with satellite or mobile and the tech industry seems to have ignored this), twitter is a nightmare. The first pageload only pulls the empty 'framework' page, then a series of js requests pull the information. You can't walk away while it loads, either, because it will register the latency and display errors instead of content.
Twitter to move away from Hashbangs
61–70 of 82 posts
Re: Twitter to move away from Hashbangs
#62Good. A lot of developers justified doing it in their own projects because Twitter and Gawker were doing it. Now that one of the headline sites is no longer using it (and will hopefully condem it) we can file this episode to history and never speak of it again. Edit: wouldn't it be awesome if Google (they did start this, afterall) would allow sites using hashbangs to auto-update all indexed URls
Hashbangs for state representation are just a tool, which can be used to make things better or worse for the users. Where content is the main purpose ("websites"), they are overkill at best. They can be useful though in functionality-first applications ("apps"), where the interface can be costly to build (too slow if you reload the whole "page" on each state change). Ideally, the app differentiates between fundamenta…
I believe the best implementation of this patten comes from the trance.fm website. Trance.fm gets that people come to listen to their online radio, so avoiding a page refresh is priority #1. It's very quick and responsive, too. You can listen to the music as a non-member, become a member and rate the song you're listening to, all without the music stopping. I believe it makes for a really good experience.
Re: Twitter to move away from Hashbangs
#63As far as I know, the proper way to create a modern web app to deal with location.hash fallback and pushState, replaceState etc is to use https://github.com/balupton/History.js .
Comments/Corrections are welcome.
Re: Twitter to move away from Hashbangs
#64Earlier quoted context omitted.
This is what they do.
Nope. At the moment if you go to https://twitter.com/#!/twitter then it loads up the HTML for https://twitter.com/ , if you're logged in it will be the tweets of those you follow. Then the javascript magic loads in @twitter's profile dynamically. PushState will allow twitter to load in the static HTML for @twitter's profile at https://twitter.com/twitter/ and then progressively enhance it with javascript. The net gai…
[deleted]
Re: Twitter to move away from Hashbangs
#65Earlier quoted context omitted.
The tweet still needs to fit into 140 characters, including any metadata you want visible to the recipient. Think SMS. Hence, might as well make it a user-manageable item in the tweet itself.
I know that was the original idea, but I wonder how many people in the last year or two receive tweets via SMS. If I was in charge, it's a tradeoff I'd be willing to make.
The entire world is not the United States. :) "Feature" phones and spotty data service are still very common in certain regions, but SMS works almost anywhere with cell infrastructure (or via sat phones).
Re: Twitter to move away from Hashbangs
#66Earlier quoted context omitted.
This is what they do.
Nope. At the moment if you go to https://twitter.com/#!/twitter then it loads up the HTML for https://twitter.com/ , if you're logged in it will be the tweets of those you follow. Then the javascript magic loads in @twitter's profile dynamically. PushState will allow twitter to load in the static HTML for @twitter's profile at https://twitter.com/twitter/ and then progressively enhance it with javascript. The net gai…
Well, you're right and you're wrong. I'll be specific, since you are:
Twitter is sending down the home timeline as HTML. In fact, what most people are looking for when they go to twitter.com is their home timeline so I'm correct, this is what they are doing (at least in new-new-twitter which I think almost everyone now has). You're also correct, when you go to twitter.com/#!/n8agrin you get your timeline in the background which is then replaced with my tweets. However it wasn't always this way. At one point in time, going to twitter.com just downloaded a bunch of javascript and an HTML bootstrap. The whole site was generated by javascript. I know this because I worked on it.
Technically pushState doesn't really have anything to do with the practice of progressive enhancement or making anything "much faster". You can make pure javascript sites very fast, you can make serving straight up HTML very fast, you can progressively enhance HTML without pushState. pushState is really just a way to manipulate the history of a browser, while optionally changing the browser's current url, without a page refresh (read more here: https://developer.mozilla.org/en/DOM/Manipulating_the_browse...). You can use it to do a lot of things, one of which is to have it serve as one part of a solution for sites that behave like single-page apps without having to resort to the fragment identifier (http://en.wikipedia.org/wiki/Fragment_identifier), forever vilified as the hashbang.
Re: Twitter to move away from Hashbangs
#67Twitter's implementation of the hashbang was awful. It broke the back button and it was slow. I don't think it's a fair representation of the technique. EDIT: And based on their implementation, I wouldn't trust anything their engineers have to say about hashbangs either.
In what sense did it break the back button? Back takes you to the previous thing you clicked correctly.
It didn't break back. It just hijacked the browser's history by adding a 2nd page load in order to inject the "!#" into the address bar. Pressing back would, as a result, act like the refresh button.
Re: Twitter to move away from Hashbangs
#68Earlier quoted context omitted.
Nope. At the moment if you go to https://twitter.com/#!/twitter then it loads up the HTML for https://twitter.com/ , if you're logged in it will be the tweets of those you follow. Then the javascript magic loads in @twitter's profile dynamically. PushState will allow twitter to load in the static HTML for @twitter's profile at https://twitter.com/twitter/ and then progressively enhance it with javascript. The net gai…
Well, you're right and you're wrong. I'll be specific, since you are: Twitter is sending down the home timeline as HTML. In fact, what most people are looking for when they go to twitter.com is their home timeline so I'm correct, this is what they are doing (at least in new-new-twitter which I think almost everyone now has). You're also correct, when you go to twitter.com/#!/n8agrin you get your timeline in the backg…
IME I get my timeline flashing up in the foreground (not background!) before the actual content I want appears. Wastes a second or two.
Re: Twitter to move away from Hashbangs
#69Earlier quoted context omitted.
Wouldn't they have to, to support browsers without pushState? And even if they used terrible JavaScript hackery to get around that (serve same content for every URL, have clients AJAX in content based on location.href) how would they support web crawlers? I thought the whole point of the hashbang was that you would get the original content (or an equivalent representation) by removing it from the URL, so I'd think th…
They could use the exact same setup they have right now. They'd just serve the exact same (static) html for every twitter.com/username URL. I don't think it's exactly terrible Javascript hackery to look at the location.href and do an ajax call. They'd probably support web crawlers with the same system they use now. And many web crawlers these days execute javascript anyway.
The system they have now is the #! hack, the crawlers know how to request static versions of the pages. There isn't a similar mechanism for pushState based designs, you just serve up the content pre-rendered for the initial page. So that's probably what they will do to stay indexable. It will also make the first page load snappier (probably)
Re: Twitter to move away from Hashbangs
#70Can somebody explain to non-web-types why this matters, other than making the URL itself look cleaner?
It was hinted at in other comments, but when you go to http://twitter.com/#!/danwrong , what you're really doing is going to http://twitter.com/ , processing a chunk of JavaScript that looks at what's after the #!, then loading up danwrong's page. This causes issues with search engines (the server has already told the crawler everything's OK, so how do you tell it the page can't be found?) and changing URLs (if you w…
Actually, twitter should not have any google indexing problem. Search engines have provided new scheme for indexing hashbang URLs with Ajax content[1]. But, maybe, not all search engines have implemented it yet.
If I had to guess, primary reason would be that server is blind as to what page needs to be loaded when you click twitter.com/#!something and an ajax request actually serves the relevant content, so it's relatively slower. Twitter's implementation was particularly slower.
[1]https://developers.google.com/webmasters/ajax-crawling/docs/...