Using the language you're comfortable with client-side. Though what this really shows, once again, is that we really need a good, open, virtual machine specification for client-side byte code so we aren't stuck with the same javascript hammer for all problems.
How is that a bad thing? Source code VMs are easier to secure and as the tooling improves, you don't need to look a the generated JS anymore to debug, it becomes "byte code".
If you can perform computation on the client, you can avoid some round trips to the server. Of course, you can't trust the client, so you still need to perform (some of) the same computations on the server.
If you can use the same code for both client and server, then it opens up the possibility of sending chunks of logic over the wire.
Here's a trivial example: a website uses Markdown for comment formatting. You can improve the feedback cycle, especially for those who aren't overly familiar with Markdown, by rendering a preview on the client side. However, this means that you need two Markdown parsers, one in your server-side language, and one in JavaScript. That's a potential duplication of effort. Someone has already written a JS Markdown parser, but it might not have exactly the same behaviour as your server implementation. So why not just write the code once and have it work on both sides?
I have a feeling that there are a lot more interesting things that you can do with split computation, but I haven't seen many examples yet. I think they'll come.