[apike]

Querying each URL would be impractical to do on the Twitter client side, especially on a mobile device, even simply from the latency before you can render perspective. You could render the tweets with the shortened links and then reflow the text if/when each HEAD request returns, but that would probably result in a crummy, slow experience for the reader as they scroll through tweets.

Twitter could indeed have done it on their side, but just doing it themselves is more efficient for them and provides a bit of extra user benefit - the fact it's automatic so you get more room for text in your tweets, their malicious link protection, and reliability if you assume Twitter is more reliable than J Random URL Shortener.

[natrius]

> Still, skipping the middle man is both more efficient

The middle man will not be skipped. It will be wrapped. Two redirects instead of one.

http://twitter.com/twitterapi/status/15741693182

[apike]

I've updated my post to be clear that I meant more efficient for Twitter, not the end user in that case. Also, my assumption is that people use this instead of normal URL shorteners in most cases.

[natrius]

Ah, I misunderstood.

Regardless, URL shorteners cannot be described as beneficial for users (except those who want to track clicks on their links). They make it take longer to get to the page. They are an extra point of failure. They are bad for users. That doesn't mean it shouldn't be done, but it isn't altruistic by any measure.

[johns]

Nambu for Mac reverses every short URL and does so without affecting the app performance negatively.

[hboon]

That's on the Mac, not on a mobile devices with a higher latency cellular connection.