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

51–60 of 67 posts

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

#51

Post by MattRogish »

amirnathoo wrote: post #18
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.

When thinking about the pricing model, you should compare us to a combination of PhoneGap's cloud build service (which is also fremium and restrictive) and their support packages: http://phonegap.com/support#support-packages The main difference with us is that you do not pay to raise a support tickets: you get direct access to our developers on any plan. And we charge per-app with no restrictions on the number of dev…

Is that really the main difference?

It seems, from what I can tell, users must go through Trigger.io to do a build to get their app in the store. Their code isn't portable to a non-trigger.io platform, either (mobile web, etc.), and the built binary contains closed-source code (Trigger.io platform stuff).

You can run a PhoneGap build locally without going thru the PhoneGap build service. And you get complete and unrestricted access to the source code.

If your service disappears or starts charging exorbitant amounts of money, users are SOL.

Trigger.io is a commercial entity that is in the business of locking customers into a platform and exploiting it. PhoneGap is the opposite. I place no value judgements on this (I use plenty of licensed code on a daily basis and I work for a commercial entity doing something similar); that may or may not matter to a person, but to me - that seems to be the main difference.

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

#52

Post by lukifer »

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!

Debugging tools definitely need to be improved, but what I struggle with the most are memory/crashing bugs. XCode, for all its warts, provides sophisticated tools for handling this. Troubleshooting these issues on WebKit+PhoneGap is a miasma of trial and error, especially if the bug is hard to replicate on a desktop with 10 times as much RAM as a mobile device.

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

#53

Post by lukifer »

MattRogish wrote: post #51
amirnathoo wrote: post #18

Earlier quoted context omitted.

When thinking about the pricing model, you should compare us to a combination of PhoneGap's cloud build service (which is also fremium and restrictive) and their support packages: http://phonegap.com/support#support-packages The main difference with us is that you do not pay to raise a support tickets: you get direct access to our developers on any plan. And we charge per-app with no restrictions on the number of dev…

Is that really the main difference? It seems, from what I can tell, users must go through Trigger.io to do a build to get their app in the store. Their code isn't portable to a non-trigger.io platform, either (mobile web, etc.), and the built binary contains closed-source code (Trigger.io platform stuff). You can run a PhoneGap build locally without going thru the PhoneGap build service. And you get complete and unre…

+1. Even if there is perfect trust with a platform vendor, that doesn't mean they won't come under new management tomorrow that rewrites the rules. That's a scary proposition for the backbone of one's business, since porting to a new platform is almost as much work as writing it in the first place.

I can't say I never use closed libraries/platforms/APIs, but when possible, I always choose the option that has a community fork, or some other escape route.

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

#54

Post by amirnathoo »

MattRogish wrote: post #51
amirnathoo wrote: post #18

Earlier quoted context omitted.

When thinking about the pricing model, you should compare us to a combination of PhoneGap's cloud build service (which is also fremium and restrictive) and their support packages: http://phonegap.com/support#support-packages The main difference with us is that you do not pay to raise a support tickets: you get direct access to our developers on any plan. And we charge per-app with no restrictions on the number of dev…

Is that really the main difference? It seems, from what I can tell, users must go through Trigger.io to do a build to get their app in the store. Their code isn't portable to a non-trigger.io platform, either (mobile web, etc.), and the built binary contains closed-source code (Trigger.io platform stuff). You can run a PhoneGap build locally without going thru the PhoneGap build service. And you get complete and unre…

You're right in that we're mostly closed at the moment, with our command line build tool open here: https://github.com/trigger-corp/build-tools

We think the biggest barrier to adoption of a platform like ours or PhoneGap's is complexity. So to keep the API and dev process as simple as possible we decided to keep control of the whole experience for our launch. Now, we're considering opening up more than just our command line tools, and will likely start doing that soon.

But being closed for now, people will hold us to a higher standard of simplicity, performance and customer support to give them a reason to change. We work hard to live up to that.

What you consider the 'main' thing is subjective, just wanted to point out the difference in how we support our customers and the pricing for it in the previous comment.

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

#55

Post by newhouseb »

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…

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

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

#56

Post by msh »

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.

I have a small phonegap app in the app store. It was approved without any problems.

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

#57

Post by spacy »

Connorhd wrote: post #22
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…

You gotta admit the native bridge is pretty important though, it could be a bottleneck for all the nice bits native code. On that basis the bridge is fundamental to good performance.

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

#59

Post by utopkara »

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…

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.

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

#60

Post by AntiRush »

alexbell wrote: post #27
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?

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

Post reply on HN