Bit off topic, but I wish the page transitions in the provisioning portal didn't reload all the javascript assets (with a cache busting timestamp in the url) making every click annoyingly laggy.
This page seems to have debug.phonegap.com script tag included, means anyone can see everyone else viewing the page (and execute javascript in their browser)... http://debug.phonegap.com/client/#ultralinx
Ok, that makes sense, the JS -> Java communication in Android is already very fast as it is something that can be done as part of the WebView. The fake URI request is a workaround on iOS as this feature doesn't exist. I don't have any numbers offhand, but the JS -> Java communication is definitely a very quick part of the bridge.
We totally agree that when things have a solid foundation it makes sense to build on top of them. The problem we saw with Phonegap was several design decisions we disagreed with (as we described briefly in the blog post).
This left us with the option of putting up with it (and ending up with an inferior product), or writing our own bridge, and writing our own bridge made sense. Of course you are right in that writing anything new means you have to work hard to get it to as high a standard as the alternatives, which is why we work hard to test our platform - see http://trigger.io/cross-platform-application-development-blo....
It's also important to remember that the native bridge is just one part of our product, we also write the code that generates and builds the app, which we want to integrate as tightly as possible. Writing our own bridge makes this a lot easier to do well.
I'm not quite sure I understand what you mean (so if this is the wrong answer let us know). But if you mean why do we use a different method on Android compared to iOS: we can communicate directly from Javascript to Java as part of the WebView in Android, which is very fast. The URL interception method is actually the slowest part of iOS but there is no way around it.