I wrote a very full-featured MVC client-side web framework for mobile browsers called Blossom[0]. It uses Canvas and hardware-accelerated CSS transforms, and has great performance, very similar to native iOS.<p>Recently, I began splitting Blossom up into two threads:<p>- a UI thread, which does all of the drawing, animation, and event handling, and<p>- an application thread, which runs in a web Worker, which has all of the business logic, model layer, and is also responsible for talking to the server.<p>Anyway, long story short, one unexpected fallout of this separation is that nearly all of the application logic is in a JavaScript thread/context that has, really, nothing to do with a web browser. It talks to our server over a WebSocket, and it talks to the UI with postMessage() calls on a message channel. There's no reason the other end of the postMessage() calls has to be a browser.<p>What we're looking into now is actually having native implementations of the UI thread. So on iOS, that "thread" would be written in Objective-C, and we'd have a separate, background thread with a JavaScript context (JavaScriptCore-based) that ran our application logic.<p>On Android, the equivalent UI thread would be written in Java, and the background thread running the application logic would use the v8 JavaScript library.<p>A similar approach would also be possible in Windows 8.<p>We'd still do a mobile web app as well, since many users will only interact with our app occasionally, and thus won't have it installed. Having the business logic in JavaScript makes it really easy.<p>I guess that's my point: what I love about mobile web development, and web development in general, is the easy with which you can share business logic between platforms. With the latest work we're doing in Blossom, we'll even be able to do that while still having a fully-capable, platform-native UI.<p>That's pretty cool. :)<p>[0] <a href="https://github.com/erichocean/blossom" rel="nofollow">https://github.com/erichocean/blossom</a>