> Also, I've thought of a good reason myself: performance. If I'm adding
> an item to a list, it's a better user experience to update the display
> immediately rather than waiting for the server to send back a 200 OK,
> and handle the error or timeout case specially.

While in general I tend toward the other the other thing you said, "Does it make sense to replicate the
server-side functionality on the client?" -- I think what you propose above is legit. 

MOST people don't write interfaces like that, even in js.  That is, an interface that will update the user interface even before/without receiving _anything_ back from the server. (But, in the best cases, produce and error message and/or 'undo' the user interface action iff the server does later get back with an error/failure message). 

So if you're going to do that, then--- it kind of doesn't matter if the server sends back HTML or JSON or anything else, the user interface is updating before/without getting _anything_ from the server. But to the extent the server's response then serves pretty much only as a notification-of-failure or whatever, yeah, JSON is the way to go. 

So, yeah, if you're going to go all the way there, that's a pretty cool thing (if you can make sure the failure conditions are handled acceptably), sure, go for it.