It all started out when I wanted to play a little bit with mootools Move.Drag. The original plan was to make a javascript version of magnetic poetry – why not? – it sort of got a little out of hand and turned into chess, and consequently the drag/drop implementation for good old tested left-click.
But what does this has to do with anything. Well to start there's the very simple (quickly hacked) two player javascript version of the game, really quite uninteresting, but as my little project continues onward getting it to look a little better and implementing an actual server in php. So far it looks something like this. It's quite basic at the moment, no feedback whatsoever, text-graphics, doesn't care about check-mate (and probably never will because it is a little more computationally expensive than the rest), and only covers basic legal moves (ie. Castling and En Passante is out of the picture). Check it out if you want to but the code is a mess of UI handling and logic in one small bowl of spaghetti-o, more to come later.
So what?
you should probably ask by now. Except for sharing that fugly hack of a chess-implementation, what is the point I'm trying to make? Well it's this: Javascript is a convenient way to validate input data on the client side. Big whoop, you could say, but it does add to the responsiveness of the application and it does save a smidgen of band-width, not to mention processing power since most of the request (assuming that end-users actually use your client) will be more or less valid. By not having to check all input against the server latency becomes much less of an issue (javascript performance could however show it's ugly face in extreme or badly coded cases).
Practical one could say, just getting validated data to mash into your application. But not so fast, javascript being easily changed from the console (or from skimming to the source to get the format of those pesky GETs/POSTs) and that way skip the verifying scripts all together you still run the risk of getting malicious data. Cheating being an issue for chess – (you are using prepared SQL statements to help combat SQL-injection right?), not to mention data that will simply break your carefully crafted app.
So boys and girls, no matter how much client-sided work you do, always always always treat data as poison and verify it on server side as well. Always.