Using Javascript, the client could as well only send the fields that have changed.

That's true. However, depending on the needs of the application, you might want to take things a step farther and engage the client in a dialogue about values changed by others. For that purpose it helps to tell the server what the values were when the client loaded the form.

Exactly what I was thinking.

What do you mean by "faking" it? Example please.

Are you not too concerned about this because the real validation happens on the server anyway?

Suppose two people are updating info about a T shirt: size=M color=green

Suppose Al is in charge of color and Betty is in charge of size. They both get the form at the same time.

Al sends oldsize=M newsize=M oldcolor=green newcolor=blue

Betty sends oldsize=M newsize=S oldcolor=green newcolor=green

The server ignores Al's oldsize/newsize and Betty's oldcolor/newcolor because the values are unchanged.

You end up with size=S and color=blue no matter who sends the update first.

By "faking it" I refer to the fact that the old values are user-supplied data. Validation of the new data is a separate issue. Someone could "fake" an old value. This merely means they would change a value that they were already authorized to change. Messing with the "old" values on the client side has no hack value. That's why I'm not at all concerned about it.

What if they changed the old value to the same value as the new value? Then your client side app would do nothing. Right?

Correct. I am not concerned about someone deliberately hacking the system in such a way as to do nothing.