The innovation here is using the type system to determine whether code should be executed on the client or the server. Contrast this with writing code manually for node and the browser. In this case, though it's all javascript, the programmer must explicitly divide the code for the server and the client. Or contrast with Meteor. Here there is a bit more code sharing, but the programmer still needs to think about client vs server (by checking `Meteor.is_client` and `Meteor.is_server` where appropriate).

In Opa (as I understand it--I haven't used it), the programmer can be explicit about where code execution should occur, but the compiler can also infer where it should occur, determine the best place to put the "data boundary", and warn the programmer if code is executed in an unsafe context.

For "traditional" next-gen web apps, it's a tough call that this is enough of a win to warrant learning a new language. Further, because this style of server-client programming is pretty immature, programmers may want to have tight control over where code is run.

However, I think this is very important work for the future of distributed computing. In particular, consider if we are ever to move from the web's dominant server-client architecture to a more fluid peer-to-peer model, with code moving from client to client where appropriate (i.e. mobile agents). For example, say my phone needs to grab some data from my laptop, but rather than have the laptop send all the raw data to my phone and have my phone process it, the system figures out that it would be more efficient for my phone to send code to my laptop, have the laptop process the data locally, then send the processed data back to my phone.

To be able to make inferences like in that example, I think we will need to use approaches like Opa.