4 ms·

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 responsive

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.

alunny 15y ago
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/thread/8e44da7f150b4e45/b99b13e4f54e8036?lnk=gst&q=addJavaScriptInterface#b99b13e4f54e8036 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.
- jamesbrady 15y ago
  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.
mikeklaas 15y ago
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)
- blueski 15y ago
  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.
  - MattRogish 15y ago
    I disagree to your disagreement. :) Although performance is important, as someone who does PhoneGap apps for a living (http://mulberry.toura.com 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. :) Thanks, -- Matt
    - newhouseb 15y ago
      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).
newhouseb 15y ago
> 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).
- jamesbrady 15y ago
  Yep, I was referring more to native accelerometer events being fed into the web view. True enough that on iOS we would perform comparably, but for Android, it would mean "long"-polling a local web server at 60Hz!
- utopkara 15y ago
  And, this half-baked reason was the example that James can give off the top of his head for not using PhoneGap.
utopkara 15y ago
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.

alunny 15y ago

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/thread/8e44da7f150b4e45/b99b13e4f54e8036?lnk=gst&q=addJavaScriptInterface#b99b13e4f54e8036 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.

jamesbrady 15y ago
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.

mikeklaas 15y ago

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)

blueski 15y ago
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.
- MattRogish 15y ago
  I disagree to your disagreement. :) Although performance is important, as someone who does PhoneGap apps for a living (http://mulberry.toura.com 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. :) Thanks, -- Matt
  - newhouseb 15y ago
    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).

newhouseb 15y ago

> 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).

jamesbrady 15y ago
Yep, I was referring more to native accelerometer events being fed into the web view. True enough that on iOS we would perform comparably, but for Android, it would mean "long"-polling a local web server at 60Hz!
utopkara 15y ago
And, this half-baked reason was the example that James can give off the top of his head for not using PhoneGap.

utopkara 15y ago

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.