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

61–67 of 67 posts

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

#61

Post by alexbell »

AntiRush wrote: post #60
alexbell wrote: post #27

Earlier quoted context omitted.

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?

Firefox Mobile supports WebGL on Android. With a little work, UIWebviews on iOS (4.2+) support WebGL.[1] [1] http://atnan.com/blog/2011/11/03/enabling-and-using-webgl-on...

Sweet, I did not know. Is the performance respectable (provided it's a modern device)?

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

#62

Post by varelse »

alexbell wrote: post #61
AntiRush wrote: post #60

Earlier quoted context omitted.

Firefox Mobile supports WebGL on Android. With a little work, UIWebviews on iOS (4.2+) support WebGL.[1] [1] http://atnan.com/blog/2011/11/03/enabling-and-using-webgl-on...

Sweet, I did not know. Is the performance respectable (provided it's a modern device)?

It's not going to match native apps, but it works. Chrome Beta (ICS-only alas) supports WebGL as well

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

#64

Post by jamesbrady »

newhouseb wrote: post #55
MattRogish wrote: post #46

Earlier quoted context omitted.

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 w…

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.

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

#65

Post by jamesbrady »

MattRogish wrote: post #46
blueski wrote: post #38

Earlier quoted context omitted.

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 w…

Hi Matt,

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.

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

#66

Post by utopkara »

newhouseb wrote: post #39
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…

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

And, this half-baked reason was the example that James can give off the top of his head for not using PhoneGap.
Post reply on HN