

Twitter to move away from Hashbangs - ChrisArchitect
http://storify.com/timhaines/hashbang-conversation

======
simonw
This is fantastic news.

From the recent tweets by <https://twitter.com/danwrong> it looks like Twitter
are moving entirely to HTML5 pushState, and leaving IE users with full page
refreshes rather than continuing to serve them #! - Dan says "I'm not sure why
everyone is so adverse to page refreshes these days. You can make them fast
too."

Of course, Twitter are going to have to include a piece of JavaScript on the
<http://twitter.com/> homepage which checks for a #! and redirects the user to
the corresponding page - and they'll have to keep that JavaScript there
forever, since they have nearly two years worth of links that they need to
avoid breaking. One of the many reasons #! is such a nasty hack.

In terms of performance, this is going to make Twitter a lot /faster/ for me -
I often open Twitter profile pages in new windows (due to working on Lanyrd)
and each new window has to pull in and execute a HUGE chunk of JavaScript
before it will display the page. Being able to just load a regular HTML page
will be much faster for me.

~~~
joshuahedlund
can't they just do a one-line .htaccess regex replace? or is it more
complicated than that?

~~~
simonw
Nope, because anything after the # isn't included in the HTTP GET request made
to the server - so a .htaccess-level redirection won't see it. You have to
execute actual JavaScript on the client to read and redirect the #! bit.

------
Nitramp
The actual URL for the informative blog post is this:
<http://danwebb.net/2011/5/28/it-is-about-the-hashbangs>

The linked blog post only contains some relatively meaningless Twitter
messages and the hyperlink as text, not as an actual link.

One of the things the post doesn't mention (it's sort of implicit in "going
under the radar") is that with hash bangs, every request has double the round
trip time to retrieve the initial data being displayed, as the server cannot
know what data the client wants to retrieve. This makes a lot of nifty
performance optimizations impossible.

~~~
wmf
Only inter-site links incur the double round trip (and in NewTwitter's case,
serious load time); intra-site links should be faster.

~~~
sirclueless
"intra-site links should be faster"

Why? With proper caching, all you need is the new content. Which possibly
entails a few KB of HTML boilerplate and a few milliseconds for the browser to
render it, but the round trip is the lengthy part and you get that either way.
The only thing hashbangs get you is a prettier transition.

------
nikcub
Good. 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

~~~
AlexBucataru
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 fundamental
states, represented in URLs, and transient states, represented in hashbangs.

Anyway, this is good news for Twitter, if they are really going through with
it.

~~~
RegEx
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.

------
jquery
Twitter'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.

~~~
alexmic
In what sense did it break the back button? Back takes you to the previous
thing you clicked correctly.

~~~
Smudge
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.

~~~
jamesgeck0
I don't follow you. Changing the functional behavior of the back button
_sounds_ a lot like broken.

~~~
alexmic
I'm not sure that this is the case.

Back works as expected - it takes you to the previous page you were at.
Fragment identifiers don't break the back button. That's all from a user
perspective's point of view, which is mostly all that matters in the end.

If you look at this from a technical standpoint, then back is a refresh of
twitter.com, yes.

------
protospork
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.

------
guelo
Good. Now if they would get rid of minified urls they would be done with their
damage to the web.

------
technomancy
I've been using the mobile version on my laptop for a few months now since the
hashbang was so sluggish, but this could get me to switch back.

------
kylemaxwell
Can somebody explain to non-web-types why this matters, other than making the
URL itself look cleaner?

~~~
ceol
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 want to stop
using hashbangs, you have to include an annoying piece of JavaScript on your
home page _forever_ ).

So now, Twitter wants to get rid of the hashbang from its URLs because of— in
part— the first reason, and it's currently dealing with the second.

Hope that explained a bit.

~~~
x3c
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/...](https://developers.google.com/webmasters/ajax-
crawling/docs/getting-started)

~~~
bad_user

         Search engines have provided new scheme for
         indexing hashbang URLs with Ajax content[1].
    

This is a myth.

First of all there is no standard and Google has no way of knowing if a
website's implementation of hashbang URLs behaves in the expected manner, or
not.

Then, you've got all those other issues ... with hashbangs you have no
standard way of telling Google some content moved (302, 303) or is not
available anymore (404).

Therefore they have to make tweaks for individual websites (akin to how
Microsoft was pushing "special" fixes for various popular software running on
Windows that broke on updates).

Telling people that hashbang URLs are indexed is exactly the same as telling
them that Flash content is indexed ... sure it is. But unless you're too
popular for Google to ignore, then get ready for a world of pain.

~~~
EdiX

        This is a myth.
        First of all there is no standard and Google has no way of knowing if a website's implementation of hashbang URLs behaves in the expected manner, or not.
    

[https://developers.google.com/webmasters/ajax-
crawling/docs/...](https://developers.google.com/webmasters/ajax-
crawling/docs/specification)

However you are probably right on everything else.

------
martindale
Thank god. I've always felt uncomfortable that every link normal users share
(I manually remove them) is technically pointing at their front page.

------
lucb1e
I especially agree with that last comment, people are so hyping over not
making pages refresh for speed, they rather often trigger the opposite effect.

------
xpose2000
As 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.

------
zaidf
I thought this was about twitter moving away from hashtags. For some reason I
got a bit excited, may be because I find vast majority of hashtags to be
annoying noise. That said, I know they serve a purpose in specific use cases
and donno a better alternative.

~~~
ecocentrik
Hashtags were/are a Twitter user creation that they do very little to support
apart from making them linkable within posts so they are easily searchable
from their application interfaces.

~~~
skeletonjelly
Seems a bit disingenuous saying they do very little to support it. There was a
big UI change in the latest official Twitter client that made a major tab for
trends and hashtags. Seems to be a core facet to me.

~~~
chimeracoder
Yes and no. First of all, at least until recently, a hashtag wasn't actually
distinguishable from the word itself. So 'ycombinator' and '#ycombinator'
would both show up in a search for 'ycombinator' (and that was intentional. If
anything, they were making it easier for people to ignore them (if they wanted
to).

Second, the hashtags (as well as the @replies) both grew organically out of
the userbase. They adopted them because the users had _already_ adopted the
hashtags. In fact, if I remember correctly, they were initially resistant to
the idea until they saw how much people took to them and used them even
without any official support.

The new tab seems like a glorified search - they use a hashtag for an icon,
but it seems like the system itself would work pretty well for any single-word
search. And with a data firehose as fast as Twitter's, you don't really want
to have to do search over multiple words if you can avoid it.

------
johnbender
"PushState or bust" means there will be no support for IE version 9 or
earlier, which makes me wonder if they'll take the approach of layering
replaceState on top of the existing hashbangs thereby fixing the deeplinks
issue.

------
swah
OTOH isn't this the "modern way" to develop a web app?

HTML templates + AJAX on the client and a REST/JSON API that you can reuse for
iOS apps on the backend?

~~~
nkohari
I wouldn't say the re-use is specifically for iOS apps, but in general, you're
right.

------
firefoxman1
Even though Twitter has decided it's either "pushstate or bust" what sort of
fallback for pushstate exists for those of us who care about _all_ our users,
not just the ones with good browsers?

~~~
epistasis
The fallback is a normal web request and page refresh. This seems far more
caring for all of their users than the high load that the hash-bang design
placed on client computers.

~~~
firefoxman1
In their case, yes, but the _potential_ speed gain by pushing a lot to the
client-side is great when properly harnessed.

------
zerostar07
How about they move away from URL shorteners too?

------
thelicx
That totally makes sense. Time to pushState!!!

------
altcognito
Dan says "I'm not sure why everyone is so adverse to page refreshes these
days. You can make them fast too."

 _Rolls eyes_ I don't need Twitter (140 characters should be enough for any
application!) telling me how "fast" their pages load. Particularly coming from
the notorious fail whale.

