That's why I used the comparison, it's definitely doable and I would assume that you'd get a decent enough performance out of it (as opposed to e.g. a JS-based Rage).
I just don't get the argument at all that this would enable it to run on a cheaper platform, i.e. somewhere where a native app wouldn't run. You're slicing away a tiny bit of overhead (once a kernel+browser is loaded), but adding more than that.
Wrong. Think of the three big mouths to feed in Android running modern apps or a browser (all of which require the embedded WebKit):
* Kernel
* Dalvik
* WebKit
The middle one is in fact a big memory and CPU pig for real workloads. Take it out, and B2G fits with room to spare on the 256MB QualComm phone we demo'ed at MWC -- ~128M used by kernel, Gecko, Gaia and apps at most.
Android does not even fit on this phone.
Your assumption that native-app framework and VM code loaded in practice is a "tiny bit of overhead" is false.
I just don't get the argument at all that this would enable it to run on a cheaper platform, i.e. somewhere where a native app wouldn't run. You're slicing away a tiny bit of overhead (once a kernel+browser is loaded), but adding more than that.