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

21–30 of 67 posts

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

#21

Post by jamesbrady »

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.

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.

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

#22

Post by Connorhd »

ynniv wrote: post #10

facepalm . First, it is generally better to apply performance improvements to the existing framework than to create a new one. Second, different is not always better. This will increase call performance, but will incur a (de)serialization penalty, limit parameter types (likely to scalars and read-only hashmaps), and make debugging more difficult. And beware of telling the OS that you implement this protocol, or you w…

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.

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

#25

Post by jamesbrady »

pmuellr wrote: post #20

re: "This approach is heavier and hackier, but a decision they made in order to sideline a bug in the Android 2.3 simulation. It’s not a bug that affects actual Android 2.3 devices, so we take this to be a bit of overkill." From what I could tell, the bug was shipped starting with some version of Android 2.x (I'm thinking 2.2) where JSC was used as the internal JS engine for WebKit instead of V8. When the Android dev…

Hey Patrick, we support from v2.0 upwards, although not as heavily tested on 2.0 and 2.1. Our tooling actually sets users up with an AVD, and our docs (http://docs.trigger.io/en/v1.2/android/getting-started.html) do say that 2.3 is not supported on the emulator.

Although we obviously can't test every device out there, everything so far points at no device ever actually shipping with JSC after 2.2, e.g. see http://code.google.com/p/android/issues/detail?id=12987

If we do get requests from our users to change that approach, we'd obviously consider it, but at the moment, we think the significant performance and code cleanliness benefits outweigh the downside.

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

#26

Post by sahilpjain »

JRambo wrote: post #24

This is great. I`m a huge fan of PhoneGap. I'll check out Trigger for sure, hope it's just as easy!

Awesome - we'd love to hear what you think after you have a play. Feel free to email me directly at sahil@trigger.io if you have any questions.

Simplicity is and has always been of huge importance for us. Developers that use our framework tell us it is much easier to get started with than other offerings out there.

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

#27

Post by alexbell »

varelse wrote: post #17

Naive question: Does Trigger.io allow multiplatform use of WebGL?

Multiplatform on mobile? As far as I am aware, no browsers for Android support WebGL. And Safari on iOS certainly doesn't.

And as long as you're referring to mobile, why wouldn't you just use OpenGL anyways?

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

#28

Post by alunny »

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…

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.

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

#29

Post by willtheperson »

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!

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.

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

#30

Post by Connorhd »

theoj wrote: post #15
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.

Thanks for the answer. Sorry I wasn't clear... I was referring to this part of the article, in which you describe how the HTML / JavaScript communicates with Objective C on the iPhone: >> We then make a request to a fake URI (forge://…) which we intercept in native code Have you tried doing the same for Android? Do you have any numbers that compare the performance of this method with the JS -> Java bridge?

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.
Post reply on HN