Are there good examples of this kind of coding? I'm excited about the idea of using the same language and maybe some of the same models on the client and the server, but the idea of just writing one application and having pieces of it execute on the server and pieces of it execute on the client is not clicking for me yet. Is it a good idea to abstract away the communication between the client and the server? It seems to me that designing that is one of the important parts of writing a good client/server app. How does that work when you are running the same code on both sides?
I've played with toy versions I've hacked up, and I think the idea is promising, but the analysis is difficult. The idea is that you should be able to write, say, an HTML canvas game as if you were running code on one machine, writing to a 2d framebuffer. But then how do you deploy it? If the clients are powerful enough (and there are no dependencies on server-side state), you can run it all client-side, as JS that implements the game and writes to the canvas.
Alternately, you can run everything server-side, except every time a framebuffer update is needed, you generate an AJAX call which triggers the appropriate canvas update, treating the client as just a remote framebuffer. But that can be way too high-latency, and not run enough on the client side. So instead you might want to put the data boundary somewhere between those two extremes. Ideally the compiler would figure out where, based on some kind of analysis (either static or from profiling data, or both) that tries to minimize latency problems and/or data transfer, and takes into account capabilities of the client and server.
