(disclaimer: I work for Adobe on a competing service (PhoneGap Build) and have worked with PhoneGap for years)
This is a silly benchmark - there is absolutely no reason you would put 1000 calls at once, sequential or parallel, across this sort of bridge in a real app. You probably shouldn't be calling any JavaScript API in a client-side app 1000 times at once.
The bridge in PhoneGap Android probably is slower than the one in Forge but
1) that's a tradeoff the PhoneGap devs were willing to make for wider compatibility, support for older devices, and isolation from the bizarre Android WebKit bugs that crop up in every release.
2) synthetic benchmarks aside, there's no indication this would affect the usability of the app.
Take the camera example in the article. A PhoneGap call (judging from the graphs) takes about 14ms, a Forge call about 3ms. That's for the entire round trip (JavaScript -> Native -> JavaScript), so divide each in half for each side of the trip.
With PhoneGap:
* first half of the trip (7ms)
* Android presents Camera activity, user picks a photo, Android returns control to original app (say, 500ms, very conservatively)
* second half of the trip (7ms)
= 514ms
With Forge:
* first half of the trip (1.5ms)
* Android presents Camera activity, user picks a photo, Android returns control to original app (500ms)
* second half of the trip (1.5ms)
= 503ms
This is much closer to a real-world use case - and the calls to native APIs entirely dominate the time spent on the bridge.
Hey Andrew - a disclaimer of my own: I'm a co-founder of Trigger.
Actually, we think this is a pretty important benchmark: battery drain and general responsiveness is a huge deal on mobile devices, so we take performance of the bridge very seriously. Every millisecond counts here.
Also, I can absolutely see the need to send large number of messages - a streaming accelerometer API, for example, which is on our roadmap.
You're right that there might be trade-offs between raw performance and supporting every quirk of every device. However, in this case, the Android bug you refer to only affects v2.3 emulators, not actual devices (to the best of our knowledge). We automatically set up our users with a v2.2 emulator to side step the problem.
We think such significant performance gains for our users, and a much cleaner, easier to maintain codebase for us, is well worth it in this case.
That's disingenuous: if every millisecond counted, then you'd be developing apps natively instead of using a web bridge.
Clearly, there is a tradeoff to be made between usability&portability and speed. To be fair, I think the camera example is not a good one: at Zite we use web<->native api for lots of things that performance is really important for since they are frequent (logging, timing, anything called frequently)
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.
I just wanted to say that I LOVE Zite on my TouchPad, every single day I spend about 2 hours looking at all articles... it is a joy to use. Thanks for the hard work making quality webOS software....
re only affecting emulators: see @pmuellr's reply below - the bug in question affects 2.2 devices also. Since we're a community-driven open source project, you can see the discussion process :)
http://groups.google.com/group/phonegap-dev/browse_thread/th...
Again, "such significant performance gains for our users" is just FUD when you're talking about arbitrary benchmarks. An app built using Forge and PhoneGap, providing the same functionality, with the same UI layer, would be a much better measure of that. I'd be happy to be proven wrong.
Thanks for the link - I can only see two mentions of 2.2 in that thread: one (in the first question) where the OP was asking about it, and another mention from Patrick, suggesting he think the issue only affects 2.3 phone using JSC. We don't know of any shipped phones that fall into that category.
Remember, this post was called "Why Trigger.io doesn’t use PhoneGap" - it's about the reasons we chose not to live downstream from you, not just a post bashing what you've done.
For us, the significant delta in performance is evidence of a different philosophy between what we are aiming for, and what you offer. We clearly want to make different design decisions, and need to be independent to do that properly.
> Also, I can absolutely see the need to send large number of messages - a streaming accelerometer API, for example, which is on our roadmap.
There is no benefit to sending ondevicemotion events out to the native code because you can always get higher frequency updates on the native code (60Hz vs 20Hz) and sending them in via stringViaEvaluatingJavascriptFromString is identical between Trigger.io and PhoneGap (and will happen with a lower latency than things are drawn on screen in a UIWebView).
Hi James. You do realize that the bridge can be optimized to the bone to beat Trigger if needed. Even with the negligible difference in bridge speed, Cordova is superior to your closed platform because it is open.
It is perfectly OK if you learn from inspecting the open platform, just don't come back to badmouth it.
I hate to hijack, but are you guys seeing any of these apps rejected by Apple because they weren't made with native controls or any other reason? There's a project I'm going to begin working on and phonegap looks like a real time saver to me, but I don't want to have to deal with Apple telling me that my apps aren't "good enough" for them.
We've submitted hundreds of apps with PhoneGap and never had Apple reject due to PhoneGap. However, if your HTML/CSS looks terrible, Apple will probably reject you. Especially if it's just a static website app. Make it look nice and give it more functionality than a static website, and you should be fine.
They tried to do that a few years ago, but nowadays they don't reject just because an app is web-based. I have one that's 95% HTML5 and it was approved absolutely fine.
On a side note, are there plans to develop a better set of debugging tools for PhoneGap? It's one of the major pains of the platform. If one is already in development can you point me in the proper direction? Thanks!
Debugging tools definitely need to be improved, but what I struggle with the most are memory/crashing bugs. XCode, for all its warts, provides sophisticated tools for handling this. Troubleshooting these issues on WebKit+PhoneGap is a miasma of trial and error, especially if the bug is hard to replicate on a desktop with 10 times as much RAM as a mobile device.
Ripple (http://ripple.tinyhippos.com/) does a pretty good job. You can get an extension for Chrome. It will simulate PhoneGap events and extend JS api's to support what iOS and Android should have. Kind of clunky but pretty useful.
As I understand it, the main objection to `__proto__` is that it's writable, and thus not atomic with object creation. This creates a bunch of headaches for implementors for performance and security.
Yeah, I can understand how it makes implementors' lives easier... I just like it when they deal with annoying stuff so that I don't have to :)
I know people don't use mutable __proto__ for anything useful, but it does enable some neat tricks. Personally I wish implementors would embrace it and optimize for it rather than trying to make it go away.
As for the "prototype for" operator... that's disgusting.
"git commit --amend" is very useful if you realise you forgot to include some files in the last commit.
Although if you committed since then you might be better off adding a new commit with the missing files and then doing a "git rebase -i" to move and squash the commits as appropriate.
The Underscore functions do exactly the same as Resig's in the simple case (when passed just an array of numbers). They're longer because they accept custom iterators for non-numerical arrays.
And I'm sometimes a little annoyed at all the things to which I've been saying for the last week "I'll get back to that" suddenly showing up in my company's proxy logs all at once.
Chrome actually reopens all tabs for you if you use the command after restarting chrome. I don't like the author's solution because I use cmd 1-9 for navigating between tabs.
I don't like the author's solution either. Cmd+Option Q seems like an unused alternative that wouldn't require a major re-wire of habits to change to, just a slight mash of the keys to the left.
I initially thought Cmd+Shift Q would be better, but that is tied to System Logout.
Ah, that must be why there's the inconsistency between Mac and other platforms here. On Windows and Linux, Ctrl-Q does nothing; Ctrl-Shift-Q exits Chrome.
I forget where I saw this tip, but after making this mistake several times I remapped command-Q in Chrome to the "Zoom" command. (Keyboard control panel -> Keyboard Shortcuts -> Application Shortcuts). It's already saved me lots of time. And of course, any harmless menu command will work in place of "Zoom."
Edit: after I RTFA, I see this is much like what the article suggested. The only real difference is that my approach prevents you from quitting from the keyboard at all.
This is a silly benchmark - there is absolutely no reason you would put 1000 calls at once, sequential or parallel, across this sort of bridge in a real app. You probably shouldn't be calling any JavaScript API in a client-side app 1000 times at once.
The bridge in PhoneGap Android probably is slower than the one in Forge but
1) that's a tradeoff the PhoneGap devs were willing to make for wider compatibility, support for older devices, and isolation from the bizarre Android WebKit bugs that crop up in every release.
2) synthetic benchmarks aside, there's no indication this would affect the usability of the app.
Take the camera example in the article. A PhoneGap call (judging from the graphs) takes about 14ms, a Forge call about 3ms. That's for the entire round trip (JavaScript -> Native -> JavaScript), so divide each in half for each side of the trip.
With PhoneGap: * first half of the trip (7ms) * Android presents Camera activity, user picks a photo, Android returns control to original app (say, 500ms, very conservatively) * second half of the trip (7ms) = 514ms
With Forge: * first half of the trip (1.5ms) * Android presents Camera activity, user picks a photo, Android returns control to original app (500ms) * second half of the trip (1.5ms) = 503ms
This is much closer to a real-world use case - and the calls to native APIs entirely dominate the time spent on the bridge.