Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Trigger.io doesn’t use PhoneGap – 5x faster native bridge

trigger.io

Post reply on HN
Print view View original

31–40 of 67 posts

Re: Why Trigger.io doesn’t use PhoneGap – 5x faster native bridge

#31

Post by Connorhd »

ynniv wrote: post #12
Connorhd wrote: post #7

Earlier quoted context omitted.

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.

You can call Objective-C from JavaScript on iOS: [ https://developer.apple.com/library/mac/#documentation/Apple... ]

I believe this is a Mac OS X feature that isn't supported on iOS.

Re: Why Trigger.io doesn’t use PhoneGap – 5x faster native bridge

#32

Post by alunny »

gavingmiller wrote: post #19
alunny wrote: post #16

(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 th…

Totally agree with you on this one. 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!

Agreed - I'd definitely like to see something like JSFiddle for PhoneGap. We're working on weinre right now - http://phonegap.github.com/weinre/ - and also recommend Aardowlf - https://github.com/lexandera/Aardwolf - and Ripple - http://ripple.tinyhippos.com/

Re: Why Trigger.io doesn’t use PhoneGap – 5x faster native bridge

#33

Post by [deleted] »

drewda wrote: post #9

Anyone have experiences of moving from PhoneGap to Trigger.io? Sounds like the tooling is a bit simpler to use (you can avoid XCode): http://www.quora.com/How-is-Trigger-io-better-than-PhoneGap-... But otherwise I can't see many inducements to using Trigger.io's commercial service over open-source PhoneGap.

[deleted]

Re: Why Trigger.io doesn’t use PhoneGap – 5x faster native bridge

#34

Post by mikeklaas »

jamesbrady wrote: post #21
alunny wrote: post #16

(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 th…

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…

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 webnative api for lots of things that performance is really important for since they are frequent (logging, timing, anything called frequently)

Re: Why Trigger.io doesn’t use PhoneGap – 5x faster native bridge

#35

Post by jamesbrady »

alunny wrote: post #28
jamesbrady wrote: post #21

Earlier quoted context omitted.

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…

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, provi…

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.

Re: Why Trigger.io doesn’t use PhoneGap – 5x faster native bridge

#36

Post by mirsadm »

Last time we were looking at the web/javascript based cross-platform tools there seemed to be lots of issues with memory handling (running out of memory to be specific). Is this still the case or, even, has this ever been a major issue for big applications? Maybe somebody who has used these tools successfully can provide some more information.

Re: Why Trigger.io doesn’t use PhoneGap – 5x faster native bridge

#37

Post by drzaiusapelord »

alunny wrote: post #16

(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 th…

Whoa a phonegap person!

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.

Re: Why Trigger.io doesn’t use PhoneGap – 5x faster native bridge

#38

Post by blueski »

mikeklaas wrote: post #34
jamesbrady wrote: post #21

Earlier quoted context omitted.

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…

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 webnative api performance is important for the use cases you mention.

Re: Why Trigger.io doesn’t use PhoneGap – 5x faster native bridge

#39

Post by newhouseb »

jamesbrady wrote: post #21
alunny wrote: post #16

(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 th…

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…

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

Re: Why Trigger.io doesn’t use PhoneGap – 5x faster native bridge

#40

Post by MattRogish »

drzaiusapelord wrote: post #37
alunny wrote: post #16

(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 th…

Whoa a phonegap person! 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.

Thanks,

-- Matt

Post reply on HN