[codeLullaby]

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?]

[npk]

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

[nostrademons]

It's so that if the server update fails, the user isn't mislead into thinking it succeeded. They can then take whatever action needed to correct it, like clicking the arrow again.

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.

[paul]

Yeah, it seems to work ok for reddit (try "work offline" then click the arrows on reddit).

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.

[codeLullaby]

Paul can say this, but,

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

[philh]

You could always update the UI on the assumption that it will succeed, and then check the return value. If you get failure, notify the user somehow. Making the UI seem a slight bit more responsive might not be really worth it, of course.

[paul]

UI latency is actually very important, and generally under-appreciated. Sometimes, it's better to be fast than perfect.

[aston]

I think the standard solution here would be not to lie to the user. A quick sending graphic, which is replaced with a received graphic would accurately portray the events that are happening. These could easily be iconic, maybe just a differently colored arrow while sending, which fades out when it's sent.

[benhoyt]

Definitely true, especially for something like up-voting. I mean, it might fail on 0.1% of clicks, but 0.1% accuracy on a vote is pretty good.

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.