I don't understand the apparent disdain here for phonegap. I'm currently working on a freelance project to convert a blackberry app to a phonegap app. Everything they want to do they can do using phonegap. I don't feel held back or like I'm half-assing it. I have access to CSS for, in my opinion, easier UX designing, and jQuery for things like posting or modal dialogs. Why aren't more people excited about developing once and it working on multiple platforms?
PhoneGap vs RubyMotion
21–30 of 37 posts
Re: PhoneGap vs RubyMotion
#22I don't understand the apparent disdain here for phonegap. I'm currently working on a freelance project to convert a blackberry app to a phonegap app. Everything they want to do they can do using phonegap. I don't feel held back or like I'm half-assing it. I have access to CSS for, in my opinion, easier UX designing, and jQuery for things like posting or modal dialogs. Why aren't more people excited about developing…
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.
Re: PhoneGap vs RubyMotion
#23I don't understand the apparent disdain here for phonegap. I'm currently working on a freelance project to convert a blackberry app to a phonegap app. Everything they want to do they can do using phonegap. I don't feel held back or like I'm half-assing it. I have access to CSS for, in my opinion, easier UX designing, and jQuery for things like posting or modal dialogs. Why aren't more people excited about developing…
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 b…
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.
Re: PhoneGap vs RubyMotion
#24One thing that really put me off about this article: the giant header that scrolls with the page. Vertical real-estate is already limited on a wide-screen monitor. I hate it when CNet does it, I hate it when news sites do it, I hate it all around. I understand I might not be speaking for everyone, but a nice thing would be an option to stick the header to the top. It could scroll by default until you click a button,…
buy a better monitor jj. Good point, we'll add an unstick on our todo list.
I really do need a monitor that can stand vertical. Wide screen monitors for reading text makes zero sense.
Re: PhoneGap vs RubyMotion
#25One thing that really put me off about this article: the giant header that scrolls with the page. Vertical real-estate is already limited on a wide-screen monitor. I hate it when CNet does it, I hate it when news sites do it, I hate it all around. I understand I might not be speaking for everyone, but a nice thing would be an option to stick the header to the top. It could scroll by default until you click a button,…
buy a better monitor jj. Good point, we'll add an unstick on our todo list.
> we'll add an unstick
NO. This is just as bad. I loathe sites that require me to take action to make browsing sane just as much as the current situation. Each site that does this has its own way to make it unstick and I won't even bother looking 15 seconds how to hide that crap you're sticking through my optical nerve to read some content I may or may not even be interested in.
Solution: show your header for a second or two, then roll it up, leaving the bottom rounded part shown as a hint. If the user wants to show it again he will reach for that middle rounded part, upon which you could react to a hover, a click/tap and/or a drag. Why does it suck less? The animation builds expectation and explains the behavior, while the hint explains how to take action. Zero thought needed, and no friction to 100% content.
Re: PhoneGap vs RubyMotion
#26The article isn't necessarily a far comparison: PhoneGap is cross platform, RubyMotion isn't. But it's nice to see someone holding up the different tools against one another. His conclusion is more than correct for PhoneGap: PhoneGap feels like half-assing it.
While it is early days, it is worth mentioning (or at least taking note of) Ruboto: http://ruboto.org/ Between Ruboto and RubyMotion, I think there is a very real possibility that Ruby will become a significant player in the mobile space.
jballac, excellent point. If you post this as a comment on the page, we'll approve it ASAP, so that viewers from all origins will see it.
Re: PhoneGap vs RubyMotion
#27One thing that really put me off about this article: the giant header that scrolls with the page. Vertical real-estate is already limited on a wide-screen monitor. I hate it when CNet does it, I hate it when news sites do it, I hate it all around. I understand I might not be speaking for everyone, but a nice thing would be an option to stick the header to the top. It could scroll by default until you click a button,…
buy a better monitor jj. Good point, we'll add an unstick on our todo list.
[deleted]
Re: PhoneGap vs RubyMotion
#28Having just spent the weekend doing an iOS app in PhoneGap and jQuery Mobile, I can say that PhoneGap can get you to the first 80% really fast and it can look/feel native, but the devil is in the details and the last 20% is going to take an extra 80% for sure.
Native vs HTML/PhoneGap is about tradeoffs. With a little bit more experience I'll be able to easily ship a working app in a weekend using PhoneGap, but there are plenty of use cases where native would be a much better way to go (games, photo filter apps, etc.)
It's not about what is better in all cases, it's about what is better for your project.
Re: PhoneGap vs RubyMotion
#29One thing that really put me off about this article: the giant header that scrolls with the page. Vertical real-estate is already limited on a wide-screen monitor. I hate it when CNet does it, I hate it when news sites do it, I hate it all around. I understand I might not be speaking for everyone, but a nice thing would be an option to stick the header to the top. It could scroll by default until you click a button,…
buy a better monitor jj. Good point, we'll add an unstick on our todo list.
Why not do a simple thing - when the user starts scrolling down, switch to a mini-version of the header.
Re: PhoneGap vs RubyMotion
#30Earlier quoted context omitted.
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 b…
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 framew…
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.