Narrow scope benchmarks are nice. But I wonder how these platforms (phonegap, trigger.io, feedhenry) stack up in real world development scenarios.
Why Trigger.io doesn’t use PhoneGap – 5x faster native bridge
41–50 of 67 posts
Re: Why Trigger.io doesn’t use PhoneGap – 5x faster native bridge
#42(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.
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.
Re: Why Trigger.io doesn’t use PhoneGap – 5x faster native bridge
#43Interesting - haven't heard of Trigger.io before (I build a lot of PhoneGap applications). One thing that's going to keep me on PhoneGap for the foreseeable future, despite its issues, is the fact that it is an Open Source project now. I trust ASF + volunteers more than any startup/company.
Re: Why Trigger.io doesn’t use PhoneGap – 5x faster native bridge
#44Re: Why Trigger.io doesn’t use PhoneGap – 5x faster native bridge
#45Or you could realized language bridges are stupid and just write the Android and iOS code. Seriously, all you do is trade one set of problems for another. Might as well deal with the native platform problems and make an awesome app for that platform.
Re: Why Trigger.io doesn’t use PhoneGap – 5x faster native bridge
#46Earlier quoted context omitted.
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.
I disagree to your disagreement. :)
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. :)
Thanks,
--
Matt
Re: Why Trigger.io doesn’t use PhoneGap – 5x faster native bridge
#47Earlier 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…
> 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 wi…
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!
Re: Why Trigger.io doesn’t use PhoneGap – 5x faster native bridge
#48How does this compare to other native bridging platforms like Appcelerator Titanium? I see no mention of it anywhere in the blog posts or on the comparison charts on your site, etc.
Re: Why Trigger.io doesn’t use PhoneGap – 5x faster native bridge
#49Earlier 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)
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: Why Trigger.io doesn’t use PhoneGap – 5x faster native bridge
#50How does this compare to other native bridging platforms like Appcelerator Titanium? I see no mention of it anywhere in the blog posts or on the comparison charts on your site, etc.
We'll do other articles and comparisons in the future - we haven't yet had a chance to benchmark against Appcelerator.
Anecdotally we think a performance comparison of the bridge would be favorable, but actually the main reason people use us over other frameworks is that our development process is designed for web devs.
So with us, you don't need to do local compiles or use a particular IDE, and we have a much faster build / test cycle.