4 ms·

I think it comes back to the idea of "jack of all trades, master of none." No matter what PhoneGap does, it will never do everything superbly, and sometimes (of

I think it comes back to the idea of "jack of all trades, master of none." No matter what PhoneGap does, it will never do everything superbly, and sometimes (often, even, I'd say) the trade-off isn't worth it. There's also probably an ego play, too. I see the "Objective-C isn't that hard. Learn it." argument a lot, but it does have a steep learning curve. For one, it's syntax is confusing if you don't recognize the brackets and messaging. Second, it's a lot closer to C than something like Ruby or Python, so you have to learn about types and memory management.

brodney 14y ago
I thought it might be the jack of all trades issue. I find phonegap to be a great framework when it is appropriate to use. In the project I mentioned, it fits the client's needs perfectly. I wouldn't use it to develop an app that needs tighter access to the api or hardware than what phonegap offers. I have another project using audio units - phonegap would be a bad choice there. It's a mistake to compare these frameworks to native apps, not that you did but several posts are. They are different, and that's good. It's like complaining that C isn't object oriented. Find the right hammer for your nail.
- GantMan 14y ago
  That's the attraction to phonegap, but what happens when your "nail" changes? Your client might ask for a small feature that the API doesn't support, which renders your entire solution useless, or cumbersome. One of the points in the article is that the second you want something phonegap doesn't provide, you're stuck back-peddling, or over-engineering your fix. We've already come across such a situation with one of our upcoming projects that requires camera overlays. Ultimately, it's important to compare options, whether they be frameworks, native, or toolchains. They're all avenues that need to stand their ground against other avenues.

brodney 14y ago

I thought it might be the jack of all trades issue. I find phonegap to be a great framework when it is appropriate to use. In the project I mentioned, it fits the client's needs perfectly. I wouldn't use it to develop an app that needs tighter access to the api or hardware than what phonegap offers. I have another project using audio units - phonegap would be a bad choice there. It's a mistake to compare these frameworks to native apps, not that you did but several posts are. They are different, and that's good. It's like complaining that C isn't object oriented. Find the right hammer for your nail.

GantMan 14y ago
That's the attraction to phonegap, but what happens when your "nail" changes? Your client might ask for a small feature that the API doesn't support, which renders your entire solution useless, or cumbersome. One of the points in the article is that the second you want something phonegap doesn't provide, you're stuck back-peddling, or over-engineering your fix. We've already come across such a situation with one of our upcoming projects that requires camera overlays. Ultimately, it's important to compare options, whether they be frameworks, native, or toolchains. They're all avenues that need to stand their ground against other avenues.