The surest way to stop this from happening is to run all the business logic server-side, only accepting commands from the browser. If the key variables are not resident in the browser (or the copy in the browser is a cached copy and never accepted as authoritative) then client-side manipulation is unable to do anything except perhaps automating UI actions.
If the client code has to be made tamper-resistant, you've already lost; that way lies PunkBuster, Valve Anti-Cheat, and other mechanisms that generally require the user to let you permanently install a rootkit on his machine so you can satisfy yourself by inspection that he's not cheating.
For some projects I've been working on recently using ASP.Net as a back-end, I've found SignalR to be a very efficient Comet-type communications layer for JavaScript and dynamic HTML, even taking advantage of HTML 5 WebSocket support if available.