Nice move!
But one thing...
The server should get updated first. Only after that should the UI value change.
[Right now, its the reverse here.Is there any particular reason for such an implementation?]
I think the answer boils down to this: http://paulbuchheit.blogspot.com/2007/06/wasting-time-on-things-that-really-dont.html
(This is not meant to be a nasty sounding response.)
It probably doesn't matter much for a site like this, but it's one of those things that's just a good habit to get into. Perform validations first, then actions, then UI updates. And do the actions that are most reversible or most likely to fail first. If you have a POST that updates a DB table and sends an e-mail, update the database first, because there's no way to unsend that e-mail.
It's like comparing constants from the left in C or doing "literal".equals(var) in Java - each individual occurrence is trivial, but taken together, it can save you a lot of grief.
Edit: though looking at the source, it's done through an Image update. I don't think there's any way to trap failure with that implementation, so here, it really doesn't matter.
For things that are really important (sending an email or something) I'd check the reply, but for arrow clicking it's probably not worth the effort and delay.
{update the server first} - {return a value} - {update the UI}
doesn't require much "effort".Its just a good practice. I am just suggesting Paul.
I guess if one was really concerned, you could update the UI immediately like News.YC does, and then change it back or show an error if it does happen to come back failed.