Ran into it yesterday (via a notice on the Python newsgroup). Same code both sides is nice: that's what Rhomobile does with it's Ruby JIT inside mobile devices, and what Lianja will do (with it's VFP/Python/PHP JIT) inside mobile devices. And the caching is cool also: Ayende does that with RhinoBus, for one. I prefer the JIT approach, but that makes Web apps problematic if they are public, rather than Employee -- Android apps will run in BlueStacks unchanged, applications.

These guys look for real.

The other interesting development for cloud work is in the area of distributed database with transactional certainty, where the transaction is complete only when the data has been replicated to all the instances -- but doesn't lose appreciable speed in doing so. http://www.nuodb.com/how_it_works.html is one. I haven't looked seriously at Xeround, another player in the cloud database world.

H

>While JS is not as elegant as Python, the same language used for front and backend keeps me looking into node.js.
>
>Newest Find: http://www.meteor.com/screencast
>from their blurb:

>
>Seven Principles of Meteor
>
>Data on the Wire. Don't send HTML over the network. Send data and let the client decide how to render it.
>One Language. Write both the client and the server parts of your interface in JavaScript.
>Database Everywhere. Use the same transparent API to access your database from the client or the server.
>Latency Compensation. On the client, use prefetching and model simulation to make it look 
>    like you have a zero-latency connection to the database.
>Full Stack Reactivity. Make realtime the default. 
>    All layers, from database to template, should make an event-driven interface available.
>Embrace the Ecosystem. Meteor is open source and integrates, 
>    rather than replaces, existing open source tools and frameworks.
>Simplicity Equals Productivity. The best way to make something seem simple is to have it actually be simple. 
>     Accomplish this through clean, classically beautiful APIs.
>
>...
>Data
>
>Meteor makes writing distributed client code as simple as talking to a local database. 
>It's a clean and simple approach, much easier than building individual RPC endpoints, 
>slow roundtrips to the server, and orchestrating invalidation messages.
>
>Every Meteor client includes an in-memory database cache. 
>Each client's cache holds valid copies of some set of documents that are stored in a server's master database. 
>When a matching document in that database changes, Meteor automatically synchronizes that change to every subscribed client.

>
>Nothing to use today: Validation in place, but no auth ;-)
>And it is currently "underdesigned" (while IMHO some Dotnet is overdesigned).
>And only on -x currently - while most biz runs windows, intersting new developments are very often first seen elsewhere.