This is native vs. java all over again. Apps that use UIKit look like iPhone apps.
Phonegap apps look and feel like phonegap, but 'run everywhere'.
I think Phonegap is a suitable replacement for Android & Blackberry where cheap > good.
On iOS I'm not sure how receptive the market would be... I think we all know how horrible Java apps feel on OS X, because it uses a slightly different UI paradigm (one menu bar).
I do think that you can do quality work on Phonegap, however, it's never going to 'feel' native iOS for a few years until the CPU performance improves on iPhone. That said there are certainly places when writing 'native' code that you throw in a UIWebView because getting iOS to do what you want is a major PITA.
Except the "native" look and feel is falling out of style fast anyway. The iOS app store is a fashion show and nothing screams amateur now like stock widgets.
>On iOS I'm not sure how receptive the market would be
I'm not convinced that normal people care that much about design. If the app solves a pain point for them, they could care less about how native it feels.
Do _not_ assume this will always work. If you bind to the tap events and change content positions you _will_ end up firing the click on an unintended element. Remember the click almost always trails the tap (save for on the Windows Phone platform). He mentions that jQuery Mobile does some "magic" to deal with the click and tap. This is the vmouse module and you can use this independent of the library for just this purpose.
"JQuery is enormous and has no business being on a phone"
It's a phonegap application, the assets can be packaged with the application itself which means that in many cases this doesn't apply.
"Massive Footprint. 248k wowsers"
I'm still confused why this matters if you are packaging your assets with the phonegap build which I would expect most people do.
He's very right. Phonegap is no trumpcard, but I'd appreciate a more thorough treatment of the "best practices" he espouses.
A few issues with this article. First, if jQuery is censored in the app bundle, it could be 500k and it wouldn't matter. 500k isn't big for an app.
Second, ontouchstart is a tricky game. It's wonderfully fast, but breaks scrolling completely if you start scrolling from an ontouchstart-bound element.
Basically, it's a shortcut around learning Objective-C. You get a lot of quick wins, but the end product isn't quite as good - except if you're doing something unusual, like one-page apps with no scrolling. I find it's good for prototyping.
The problem is absolutely not about initial download, but rather about runtime performance. Parsing and executing 500k of JavaScript on mobile is crazy slow, and it blocks the whole app while this is happening. You can mitigate this by loading the JS on demand, but you still need to pay the cost at some point. For the time being, the best approach is to only include what JavaScript you absolutely need.
The ontouchstart issue can be avoided by using the ontouchmove/end to check of the user is scrolling. Infact zepto.js has a custom event called "tap" which does exactly that.
I've built a few apps in Objective-C and in HTML5 and on both platforms you've got to be careful about performance. I don't think it's a HTML specific problem:
I remember building my first Objective-C application and having it perform terribly. I had to learn to reuse table cells and not to redraw an entire UIView.
Each platform has its quirks and if you're willing to learn about them you can make terrible and good apps in either.
You certainly cannot approach HTML5 apps as a standard chrome browser. That's just unrealistic.
This is a really good example of the kind of app that users want now. A completely custom UI with a distinct style is what it takes to get attention. For better or worse the stock UI is out and it's actually easier in some ways to build this kind of UI in HTML/CSS.
I used PhoneGap to develop my app (http://chaincalapp.com) and I've been very pleased with the result. It's not so much the cross-platform targeting that interests me, but the ability to use the tools I already know and enjoy (e.g. Backbone.js). Furthermore, the ability to use a language designed for presentation only (CSS3) is a great improvement in terms of separation of concerns. The author is also spot on about the value of not having to spend time studying native APIs in depth.
He's also absolutely right about results equalling effort. I've seen plenty of terrible mobile apps developed in JS, and I also have yet to see a jQuery Mobile app that feels right to me. I think some of this stems from attempting to recreate stock native UI elements and failing halfway. I wasn't interested in doing so with ChainCal, so I avoided that issue altogether.
As for performance, JS execution has never really been a bottleneck -- it's DOM manipulation. My advice would concur with the author's: use CSS transitions for everything. If you put in the time with benchmarking small operations and you approach things in different ways to squeeze out performance, your app can feel native. Trial and error led me to plenty of performance discoveries. As an example, using translate3d to move an element offscreen is tremendously faster than setting its display to 'none'.
Finally, I will agree about jQuery being a very large library with a lot of cross-browser support that isn't necessary for mobile. However, from my benchmarking, it would seem jQuery is still faster at most DOM operations than Zepto.
Happy to answer any questions about my experience with PhoneGap.
It pushes HTML5 canvas to its limits to create a completely cross-platform 2.5D action shooter. Also, a lot of players really like it and that is really the only metric that matters.
The game has its share of mobile specific optimizations, none of which are related to it being a PhoneGap application. Overall, PhoneGap just gets out of the way, the way things should be.
This article hits pretty hard on jQuery Mobile. I'm considering it for an upcoming project and hadn't heard about it being such a steep tradeoff on performance. Can anyone who has played around with it comment?
I used it with PhoneGap. I had no issues with PhoneGap, and unlimited issues with jQuery Mobile.
Basically, jQuery Mobile wants your whole app to be on one page. You can either have one giant HTML file that has a bunch of divs representing multiple pages, or you can have several different HTML files and link them as normal. Then jQuery Mobile will take all of your anchor links and turn them into something that fetches that page's contents and inserts it into the DOM of the current page, instead of loading a new page. Then their "page transitions" are triggering hide and show actions on the various pages in the DOM.
This also makes registering event handlers awful. First, all of your javascript has to be in one file and it has to be included in every page that a user could possibly navigate to. This means that you can't just bind on document.ready like normal, because some of the elements you're binding to don't actually exist on the page until you try and navigate to the page.
Then, jQuery Mobile uses custom events to tell you when there's been a page transition. However, you can't put your event bindings in there, either, because then your event bindings will be reapplied every time the user navigates away from and back to that page - basically, every action will be applied multiple times. Terrible.
So this means that all of your bindings have to be live bindings. Oh, also, you need to make sure none of your elements on different pages have the same id since, in the long run, jQuery Mobile mashes them all onto one page.
I recently made a very small jquery mobile web app. It still feels like alpha software, I was on an extremely tight deadline so I persevered with it, the end result worked out ok. I would be interested in other javascript framework recommendations that perform better, however from my research they all seemed to be at a similar stage to Jquery Mobile, either that or they were abandoned. If I was spending a lot of time on a mobile web app I'd probably invest the time into writing it without the layer of abstraction.
Two big tips:
1. Turn off the transitions, they perform poorly and look out of place on most devices.
2. Don't use the navbar, it just doesn't work properly on all devices, I wasted so much time trying to work out the issues with it before changing my navigation scheme.
Jokes aside, yes... it is that bad. I help out in the PhoneGap IRC channel, and I see more frustration surrounding jQuery Mobile in the PhoneGap community than any other single tool.
One of the core PhoneGap devs even tried to use it just so he could try and help people who come to us with issues relating to it. The experience was so bad I think he gave up on the idea.
I ended up making the above joke tumblr instead ;) I just try and steer people away from it.
Its performance and (in my opinion) visual appearance bely it's post 1.0 version number.
Using PhoneGap at all seems like half-assing it to me. Just because some people think iPhone and Android apps should look the same doesn't make it so. A native app for each will look and perform much better.
It's easy vs simple. HTML is familiar and therefore perceived as the easy way to build apps. Native apps are invariably simpler after a certain level of necessary complexity.
I'd wager a guess that the "single codebase" app written in PhoneGap get exponentially more complex with each platform due to browser/device/OS quirks, whereas the native implementation means an effectively linear complexity for each additional platform.
maybe the PhoneGap website should make it more obvious that it is a bad idea to use jQuery Mobile instead of listing it on its Tools page: http://phonegap.com/tools/page/2/
What concerns me the most of this post is that it offers no clear alternatives. Are we expected to write all of the UI by hand? That's not really comparable to native development.
I would like to see a light-weight Javascript UI and MVC library that is recommended by Phonegap.
one reason we use JQM is for page transitions. what other frameworks provide page transitions? we could obviously roll our own, but are just curious what the other options are. zepto and XUI are two alternatives to JQM mentioned in the article. what other ones have people tried?
So this guy thinks knowing your target platform is a burden and not knowing it somehow is a pro?
On topic of half-assing: If you're using a multi platform 3rd party layer because you're too lazy/reluctant to learn the native technology you are already half assing it.
Take a look at all those multi platform desktop frameworks like Qt, wxWidgets, etc. Apps made with those don't feel native and usually deliver subpar user experience. It's not much different with PhoneGap, RubyMotion and friends.
[+] [-] fleitz|14 years ago|reply
Phonegap apps look and feel like phonegap, but 'run everywhere'.
I think Phonegap is a suitable replacement for Android & Blackberry where cheap > good.
On iOS I'm not sure how receptive the market would be... I think we all know how horrible Java apps feel on OS X, because it uses a slightly different UI paradigm (one menu bar).
I do think that you can do quality work on Phonegap, however, it's never going to 'feel' native iOS for a few years until the CPU performance improves on iPhone. That said there are certainly places when writing 'native' code that you throw in a UIWebView because getting iOS to do what you want is a major PITA.
[+] [-] sintaxi|14 years ago|reply
[+] [-] cageface|14 years ago|reply
[+] [-] hboon|14 years ago|reply
When this is brought up, I point people to Cyberduck. http://cyberduck.ch/
[+] [-] statictype|14 years ago|reply
I'm not convinced that normal people care that much about design. If the app solves a pain point for them, they could care less about how native it feels.
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] johnbender|14 years ago|reply
Do _not_ assume this will always work. If you bind to the tap events and change content positions you _will_ end up firing the click on an unintended element. Remember the click almost always trails the tap (save for on the Windows Phone platform). He mentions that jQuery Mobile does some "magic" to deal with the click and tap. This is the vmouse module and you can use this independent of the library for just this purpose.
"JQuery is enormous and has no business being on a phone"
It's a phonegap application, the assets can be packaged with the application itself which means that in many cases this doesn't apply.
"Massive Footprint. 248k wowsers"
I'm still confused why this matters if you are packaging your assets with the phonegap build which I would expect most people do.
He's very right. Phonegap is no trumpcard, but I'd appreciate a more thorough treatment of the "best practices" he espouses.
[+] [-] elliottkember|14 years ago|reply
Second, ontouchstart is a tricky game. It's wonderfully fast, but breaks scrolling completely if you start scrolling from an ontouchstart-bound element.
Basically, it's a shortcut around learning Objective-C. You get a lot of quick wins, but the end product isn't quite as good - except if you're doing something unusual, like one-page apps with no scrolling. I find it's good for prototyping.
[+] [-] apike|14 years ago|reply
[+] [-] sintaxi|14 years ago|reply
[+] [-] ahrjay|14 years ago|reply
[+] [-] eli|14 years ago|reply
[+] [-] pistoriusp|14 years ago|reply
http://itunes.apple.com/us/app/totally-editable-calculator/i...
I've built a few apps in Objective-C and in HTML5 and on both platforms you've got to be careful about performance. I don't think it's a HTML specific problem:
I remember building my first Objective-C application and having it perform terribly. I had to learn to reuse table cells and not to redraw an entire UIView.
Each platform has its quirks and if you're willing to learn about them you can make terrible and good apps in either.
You certainly cannot approach HTML5 apps as a standard chrome browser. That's just unrealistic.
[+] [-] cageface|14 years ago|reply
[+] [-] pistoriusp|14 years ago|reply
TW7XME4JH6RN
NWWTRHHNMYPT
HKXELLNFFAJM
JY9WLFTR9Y7T
J4XTAFW9MA6K
4HEL349WWPKH
MLNKFM46KAXX
3AL9FJ7LWFW6
AH43J9KA6ERN
FH4RFWXMMW76
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] hobonumber1|14 years ago|reply
[+] [-] dmotz|14 years ago|reply
He's also absolutely right about results equalling effort. I've seen plenty of terrible mobile apps developed in JS, and I also have yet to see a jQuery Mobile app that feels right to me. I think some of this stems from attempting to recreate stock native UI elements and failing halfway. I wasn't interested in doing so with ChainCal, so I avoided that issue altogether.
As for performance, JS execution has never really been a bottleneck -- it's DOM manipulation. My advice would concur with the author's: use CSS transitions for everything. If you put in the time with benchmarking small operations and you approach things in different ways to squeeze out performance, your app can feel native. Trial and error led me to plenty of performance discoveries. As an example, using translate3d to move an element offscreen is tremendously faster than setting its display to 'none'.
Finally, I will agree about jQuery being a very large library with a lot of cross-browser support that isn't necessary for mobile. However, from my benchmarking, it would seem jQuery is still faster at most DOM operations than Zepto.
Happy to answer any questions about my experience with PhoneGap.
[+] [-] dmotz|14 years ago|reply
LRXTYFWEMJXM
JMH34LFNX44W
3N7YXP7HN9P7
PF3RLT4PHWML
MWFHXK669M4L
[+] [-] vgig|14 years ago|reply
[+] [-] vgig|14 years ago|reply
[+] [-] johnyzee|14 years ago|reply
https://play.google.com/store/apps/details?id=webworks.gangs...
It pushes HTML5 canvas to its limits to create a completely cross-platform 2.5D action shooter. Also, a lot of players really like it and that is really the only metric that matters.
The game has its share of mobile specific optimizations, none of which are related to it being a PhoneGap application. Overall, PhoneGap just gets out of the way, the way things should be.
(EDIT: Forgot to mention, you can try the game in your browser at http://www.gangstagangsta.com/play)
[+] [-] gbog|14 years ago|reply
[+] [-] gbog|14 years ago|reply
[+] [-] sheriff|14 years ago|reply
[+] [-] pistoriusp|14 years ago|reply
http://itunes.apple.com/us/app/totally-editable-calculator/i...
Here are some vouchers:
NLXEH6NE7W43
XL6AF63J7K9P
MNJKYR3YAN9M
3ARXXHX3HMYN
6WXJA97FL9LK
[+] [-] thijser|14 years ago|reply
[+] [-] gfosco|14 years ago|reply
[+] [-] dmotz|14 years ago|reply
http://itunes.apple.com/us/app/chaincal/id499195302?ls=1&...
I posted some promo codes in the parent thread. Let me know if those run out and I can add some here.
[+] [-] sheriff|14 years ago|reply
[+] [-] powrtoch|14 years ago|reply
[+] [-] azylman|14 years ago|reply
Basically, jQuery Mobile wants your whole app to be on one page. You can either have one giant HTML file that has a bunch of divs representing multiple pages, or you can have several different HTML files and link them as normal. Then jQuery Mobile will take all of your anchor links and turn them into something that fetches that page's contents and inserts it into the DOM of the current page, instead of loading a new page. Then their "page transitions" are triggering hide and show actions on the various pages in the DOM.
This also makes registering event handlers awful. First, all of your javascript has to be in one file and it has to be included in every page that a user could possibly navigate to. This means that you can't just bind on document.ready like normal, because some of the elements you're binding to don't actually exist on the page until you try and navigate to the page.
Then, jQuery Mobile uses custom events to tell you when there's been a page transition. However, you can't put your event bindings in there, either, because then your event bindings will be reapplied every time the user navigates away from and back to that page - basically, every action will be applied multiple times. Terrible.
So this means that all of your bindings have to be live bindings. Oh, also, you need to make sure none of your elements on different pages have the same id since, in the long run, jQuery Mobile mashes them all onto one page.
Yeah, I may be a bit bitter.
[+] [-] rodh257|14 years ago|reply
Two big tips: 1. Turn off the transitions, they perform poorly and look out of place on most devices. 2. Don't use the navbar, it just doesn't work properly on all devices, I wasted so much time trying to work out the issues with it before changing my navigation scheme.
[+] [-] devgeeks|14 years ago|reply
Jokes aside, yes... it is that bad. I help out in the PhoneGap IRC channel, and I see more frustration surrounding jQuery Mobile in the PhoneGap community than any other single tool.
One of the core PhoneGap devs even tried to use it just so he could try and help people who come to us with issues relating to it. The experience was so bad I think he gave up on the idea.
I ended up making the above joke tumblr instead ;) I just try and steer people away from it.
Its performance and (in my opinion) visual appearance bely it's post 1.0 version number.
[+] [-] tomjen3|14 years ago|reply
In that case you don't need it. It exist mainly to paper over the differences between the different browsers (i.e IE) which you don't care about.
You will find that HTML5 can do most of the nice things jQuery can.
[+] [-] 54mf|14 years ago|reply
[+] [-] clarky07|14 years ago|reply
[+] [-] jcromartie|14 years ago|reply
I'd wager a guess that the "single codebase" app written in PhoneGap get exponentially more complex with each platform due to browser/device/OS quirks, whereas the native implementation means an effectively linear complexity for each additional platform.
[+] [-] gcarre|14 years ago|reply
[+] [-] evilgeenius|14 years ago|reply
Seriously?
I'd rather write a web app in Ruby than C++ any day of the week.
[+] [-] at-fates-hands|14 years ago|reply
[+] [-] erichmond|14 years ago|reply
[+] [-] cbetta|14 years ago|reply
I would like to see a light-weight Javascript UI and MVC library that is recommended by Phonegap.
[+] [-] snowwrestler|14 years ago|reply
[+] [-] treelovinhippie|14 years ago|reply
Any recommendations for JQM alternative in regards to UI/design components?
[+] [-] evilduck|14 years ago|reply
[+] [-] panabee|14 years ago|reply
[+] [-] Zelphyr|14 years ago|reply
[+] [-] franzus|14 years ago|reply
So this guy thinks knowing your target platform is a burden and not knowing it somehow is a pro?
On topic of half-assing: If you're using a multi platform 3rd party layer because you're too lazy/reluctant to learn the native technology you are already half assing it.
Take a look at all those multi platform desktop frameworks like Qt, wxWidgets, etc. Apps made with those don't feel native and usually deliver subpar user experience. It's not much different with PhoneGap, RubyMotion and friends.