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.

? Doesn't this show that we aren't stuck with the same hammer? Opal is a different hammer.

Not really. You're still using Javascript in the end.

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".

Wasn't that the original goal of Java, like, 20 years ago?

It was, but the big issue there was that sun decided to keep all the keys of the castle to themselves. Hence the desire for an open bytecode format.

Native Client? Or PNaCl if you insist on extreme portability.

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.

Rewriting your entire Rails app in Node so that it goes faster!

Porting existing code without having to re-implement. Keeping a single reference implementation of a particular method.