Disagree it's disingenuous. I'm a web developer without any mobile experience. I accept there will be some performance impact from using a web bridge. However, I want to minimize this as far as possible - and all the studies show milliseconds really do count so far as usability goes.
Agree the web<->native api performance is important for the use cases you mention.
Although performance is important, as someone who does PhoneGap apps for a living (http://mulberry.toura.com) I can tell you that there are so many other performance problems with HTML5 that this is wayyy premature optimization.
11ms isn't going to kill you, and if you are experiencing performance problems, there are far more important things to do (check for DOM leaks, dealing with 3G latency, etc.) than shave off a few ms on a call to a native function.
Or put another way, there's no reason to create another PhoneGap-like framework to save 11ms on a native function call. There are a whole lot of other reasons (many business-related) of course. But this isn't one of them. :)
Of course, there were a number of reasons we were wary of being downstream of PhoneGap. The specific issue of Android performance wasn't a blocker, but was, to us, symptomatic of a philosophical difference between PhoneGap's approach and ours. We're not saying one is Right and one is Wrong - we just have different priorities.
Another key aspect for us was that our runtime platform is tightly integrated with our tooling: how those tools interact with the generation of runnable apps is obviously key to usability of our product, so we were very uncomfortable not owning such a key part of the puzzle.
The other option would have been to fork PhoneGap with no intention to push upstream, but that, to me, is against the spirit of open source, and still not optimal to us as we'd need to shoe-horn our tooling to fit a code base not designed with our needs in mind.
This a million times. I spent a better part of the last year optimizing the hell out of an HTML5 app and the bottlenecks are almost entirely in initial rendering time (CSS stylesheets and HTML Parsing/Manipulation and coaxing the memory management to not explode on you with a lot of images).
Hi,
Agreed that in your standard app, the overhead of rendering will outweigh that of communication with native code.
For us at Trigger, however, we don't have any control over the efficiency of your Javascript, or the interpreter and rendering engine that holds it.
What we can control is how efficient the communication is between your JS and the underlying native APIs. Everyone agrees that performance is a key issue, so we take great care to ensure that the performance of code we control is as small as possible.
Agree the web<->native api performance is important for the use cases you mention.