Twitter to move away from Hashbangs

http://storify.com/timhaines/hashbang-conversation

by ChrisArchitect • 14 years ago

363 77 14 years ago

simonw4• 14 years ago

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• 14 years ago

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

tkaemming• 14 years ago

The redirection has to be done on the client-side, because the server never receives the fragment identifier as part of the URL.

simonw4• 14 years ago

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.

sirclueless2• 14 years ago

That is the fundamental problem with hashbangs: the server receives "GET / HTTP/1.1" and the client uses javascript to render the hashbang. The server has no idea a hashbang is present until after it sends javascript to run client-side.

mnutt2• 14 years ago

It doesn't sound like they're switching to rendering on the backend, though. So you're most likely still going to have to execute a huge chunk of javascript before displaying the page, though hopefully it will get faster.

n8agrin3• 14 years ago

Dan doesn't say anything about where the rendering will happen.

Most sites these day (including Facebook, Gmail, etc) have to execute "a huge chuck of js" before displaying the page.

I have been told by some people in the know that they have come up with a system similar to pjax for certain page components, though that may have changed.

pak• 14 years ago

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 they still support backend rendering at some level.

simonw4• 14 years ago

I'm hoping that they plan to serve up the HTML and CSS for the basic page as quickly as possible, then load the JS that adds the pushState / interactive stuff asynchronously.

A page with a single tweet on really shouldn't need to pull down much code. The JS can all be cached by the browser (far future expires headers etc) and there are some neat tricks you can do with app cache and localStorage to make that work even better.

sjs• 14 years ago

Dan says he is on the job.

https://twitter.com/#!/danwrong/status/171730032807518210

zeeg• 14 years ago

To be honest, I'd prefer maintaining a single JS redirect on the main page, rather than many server-side regular expressions trying to redirect to appropriate pages.

nikcub3• 14 years ago

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

simonw4• 14 years ago

Do you know how long ago Gawker dropped them?

nikcub3• 14 years ago

~6 months ago IIRC

they constantly had problems with their redesign and the last update involved removing the hashbangs

marknutter• 14 years ago

hash bangs and push state are essential for creating single page apps.

AlexBucataru• 14 years ago

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• 14 years ago

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.

kragen• 14 years ago

I'm particularly happy about this because I spent a bunch of time yesterday trying to get any of the current lightweight web browsers (Dillo and Links2; I couldn't get Arachne not to crash at startup, and I couldn't find the source to hv3) to log into either twitter.com or mobile.twitter.com, with no success at all. m.facebook.com worked, more or less, but no love from Twitter.

Apparently you can't log into Twitter without 64MiB of RAM, which is what Midori uses. Dillo and Links2 use 6MiB.

Hopefully this means they're switching to a more normal HTML interface and will become a web site instead of a DHTML application again.

Nitramp• 14 years ago

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• 14 years ago

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

sirclueless2• 14 years ago

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

Lazare• 14 years ago

No. That link is to an OLD blog post explaining why Dan Webb (and many other people) think hashbangs are bad idea.

The actual news here is that Twitter is moving away from them, which is very new and welcome news. That link is only useful for general background on the hashbang argument; it's otherwise irrelevant.

technomancy• 14 years ago

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.

kylemaxwell2• 14 years ago

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

mbreese• 14 years ago

The fundamental problem is that when you use hashbangs, if you want the page "/#!12345" the server gets:

    GET / HTTP/1.1

And never knows what content the client is trying to access, until the client retrieves and processes client-side javascript. Then the client can request further information from the server. The theory is that you can make a "single-page" web-app that loads all of the javascript at once. Then went state needs to be updated, you can do it all from javascript. In practice, it didn't work as well.

alexmuller• 14 years ago

And to expand a little on what mbreese said, the basic, fundamental idea behind the URL is for a client to indicate to a server what resource it's trying to access. So it's totally broken by that #!.

http://isolani.co.uk/blog/javascript/BreakingTheWebWithHashB... is a great article.

ceol• 14 years ago

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.

kylemaxwell2• 14 years ago

Thanks, that's what I didn't get: the stuff after the hashbang isn't sent directly to the server as part of the GET request but interpreted by JavaScript after the page starts to load.

x3c• 14 years ago

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

jordhy• 14 years ago

Several issues: back button programability, URIs become uglier so then you need to do some parsing, etc.

The sample the pros and cons of hashbangs, refer to the discussion on this page: http://ask.metafilter.com/187222/Whats-wrong-with-using-hash...

zaidf• 14 years ago

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.

intellection• 14 years ago

Is it un/reasonable to consider moving hashtags out of tweets and into metadata or just separate?

Just as useful, but can be styled separately. Evolved hashtags, backwards compatible.

MBCook2• 14 years ago

That would make sense to me. I always thought it was odd that you weren't allowed to attach a link as metadata, causing the rise of all the various URL shorteners.

ecocentrik• 14 years ago

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• 14 years ago

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.

toyg• 14 years ago

Dropping hashtags would be suicide. It's one of the elements that make Twitter unique, and it's even managed to break into mainstream culture in most countries. It doesn't matter that they're full of noise, people just love to tag #somerandomstuff and see it spread (or not), gives them a feeling of belonging, the holy grail of social networks.

Us nerds, we won't care one way or the other anyway.

johnbender• 14 years ago

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

lucb1e• 14 years ago

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.

jquery• 14 years ago

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.

alexmic2• 14 years ago

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

Smudge• 14 years ago

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.

firefoxman12• 14 years ago

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• 14 years ago

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.

firefoxman12• 14 years ago

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

martindale• 14 years ago

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

altcognito• 14 years ago

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.

guelo• 14 years ago

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

thelicx• 14 years ago

That totally makes sense. Time to pushState!!!

protospork• 14 years ago

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.

xpose2000• 14 years ago

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.

swah• 14 years ago

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• 14 years ago

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

zerostar072• 14 years ago

How about they move away from URL shorteners too?

Twitter to move away from Hashbangs

Related Stories