9 ms·
You half assed it. That is why your PhoneGap application sucks.
- gfosco 14y agoYou used PhoneGap.. that's why your application sucks.
- kevincennis 14y agoSo under no circumstance is it possible to build a high-quality application using PhoneGap?
- tomkin 14y agoFirst: Do you care if you're building a native app or a web app? Don't care? Cool. Do you need notification/photo functionality? PhoneGap. If we're to believe that one day HTML5-based mobile web apps will rule, what is wrong with PhoneGap exactly?
- kevincennis 14y agoOh, I'm fully on-board with the idea that web apps can be a reasonable alternative to native. I spend a huge amount of my time at work building mobile experiences in HTML5, because that approach makes sense for our product. I was just sort of hoping that gfosco would enlighten me as to why PhoneGap is so universally terrible.
- gfosco 14y agoIt would be very very hard. It's so incredibly bloated and not modular at all. Every piece of it loads even if you don't use it. To me, it's like using Java for a Windows desktop app.
- drivebyacct2 14y agoCan you articulate this any more than a really poor analogy that falls flat for more than one reason? Do you just have a problem with the native components that are all always there versus just the shim pieces you need, etc? Any evidence that that really causes any sort of perceivable issue? It seems like it would all be microscopic compared to... anything else in a real application.
- gfosco 14y agohttp://news.ycombinator.org/item?id=4076018 http://news.ycombinator.org/item?id=4076018
- tomjen3 14y agoI have a hard time believing that. Yeah it may take meg or so extra space, but if you think that is bloated it is time to upgrade that PDP 10 to a phone were it is about a rounding error.
- colinplamondon 14y agoCorrect. Where "high quality" is pegged to apps like Tweetbot or Instagram, it's not currently possible to make webkit-based apps that are equally performant. Even examples of "web with native wrapper" apps, like Facebook and OkCupid, are dramatically, dramatically worse than best of breed native apps.
- kevincennis 14y agoInteresting that your two examples of "high quality" apps don't have web counterparts. Both Tweetbot and Instagram exist solely as native applications - which means that it makes business sense for them to develop natively. Companies like OkCupid and LinkedIn, whose apps both rely heavily on web views, need to think about the benefits of using the same code across multiple platforms. I'd tend to argue that both of those apps are pretty well-done. They certainly lack some of the really slick transitions and polish of an app like Tweetbot, but I definitely don't think either one feels cheap.
- drivebyacct2 14y agoNo offense, but Facebook's webapp is stellar compared to the native app, Instagram can't stop crashing left and right and I don't even follow anyone, Twitter's app has taken it ages to get where it is today.
- sheriff 14y agoCould someone please recommend any PhoneGap-based apps that they consider "best-of-breed?"
- gfosco 14y agoI'd love to see any that run as smoothly as if they were native.
- pistoriusp 14y agoYou could try mine out, I put a lot of love into it. http://itunes.apple.com/us/app/totally-editable-calculator/id529571185?mt=8 http://itunes.apple.com/us/app/totally-editable-calculator/i... Here are some vouchers: NLXEH6NE7W43 XL6AF63J7K9P MNJKYR3YAN9M 3ARXXHX3HMYN 6WXJA97FL9LK
- slig 14y agoI took the last one. I'm very interested in trying PhoneGap. I'll check your app and leave a review. Thanks!
- sheriff 14y agoPurchased this to check it out, since I couldn't figure out how to use the vouchers. Thanks for posting this example. It's pretty responsive... not sure if I would have known it was PhoneGap. One bug report: Divide-by-zero seems to act as if nothing happened, rather than reporting an error or NaN value.
- drivebyacct2 14y agoNot listed in Google Play? :( I would have even paid for it to try it.
- pistoriusp 14y agoI'll be porting it this weekend; need to figure out that whole "fragmented" display size issue.
- franzus 14y ago> you have to know Apple's platform 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.
- chime 14y agoIf you want to make a new iOS app, it is not a big deal to learn ObjC + XCode etc. If you want to port your existing application to work on iOS while you are still managing the web, desktop, and other mobile/tablet development, it is difficult to devote enough time to properly learn ObjC. The goals are different. Flipboard and InstaPaper wanted to make great iOS apps and spent the time and effort to learn the right away. And it took well over a year for a native Android port of InstaPaper. When your value proposition is finesse and performance, go native. If BingoCardCreator wants an iOS port so teachers can easily drag and drop words using touch on an iPad while sitting in front of the TV, I don't see why Patrick/BCC should spend months and months learning ObjC when he could just hook something up easily with jQuery draggables UI. I've released ObjC and PhoneGap apps on the App Store and frankly, like everything else in life, you have to make the best use of the resources (time/budget/energy) available to you to make the best product. What this blog post is saying, is that just because you use PhoneGap, does not necessarily mean your application will be subpar. You must know how to use it well. Also, RubyMotion uses the exact same iOS objects as ObjC does (and then some). So it should be no different than coding natively in ObjC.
- fleitz 14y agoI've been using RubyMotion for a few weeks now and sometimes when reading/writing code I have to look for semi-colons to tell the difference. Especially if the code is using a lot of structs.
- potatolicious 14y ago
- powrtoch 14y agoThis 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?
- 54mf 14y agoYes. Don't use it. Not worth the performance hit.
- tegansnyder 14y agoThere are ways to improve performance of JQuery Mobile. Tips and tricks. It's a delicate flower. For instance turn of transitions, hovers, etc. Here is a good thread: https://github.com/jquery/jquery-mobile/issues/4024#issuecomment-5757443 https://github.com/jquery/jquery-mobile/issues/4024#issuecom...
- tomjen3 14y agoAre you writing a mobile only webapp? 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.
- untog 14y agoI think you're confusing jQuery with jQuery Mobile. You're right about the former, but the latter exists to paper over the differences between different mobile platforms, as well as provide an HTML-based UI framework.
- rodh257 14y agoI 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.
- elliottkember 14y agoA 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.
- sintaxi 14y agoIt's a footprint issue, not latency. A 94k jQuery file comes at a price and 99% of that codebase never gets hit for an application like this.
- elliottkember 14y agoThat's not a big footprint for an app, especially compared with image assets, app code and CSS bundled alongside. It also means being able to add more functionality at will without having to rebundle, or worse, work on basic functionality helpers. Just seems like wasted time for such a small improvement. These devices were built to have application code on them.
- eli 14y agoSeems mostly academic, no? Do you think fewer people will download a 1.4MB app versus a 1.2MB app?
- deleted 14y ago[deleted]
- deleted 14y ago[deleted]
- cageface 14y agoZepto is 24k. Does that extra 70k really make that big of a difference? A single retina resolution png is going to be bigger than that. I think there are other reasons to consider a library that's tailored for mobile webkit but size doesn't seem like a dealbreaker.
- evilduck 14y agoPrevious discussion: http://news.ycombinator.com/item?id=4063907 http://news.ycombinator.com/item?id=4063907
- fleitz 14y agoThis 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.
- sintaxi 14y agosome of us prefer to see it as native vs web all over again ;)
- deleted 14y ago[deleted]
- cageface 14y agoExcept 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.
- drivebyacct2 14y agoAnd thank god for that. Android started out ugly, but I don't hear many people asserting that iOS apps are de facto better than Holo-themed apps for Android anymore. Frankly, I feel like it's 2003 when I pick up an iPhone. Plastic and faux-wood. Comforting.
- gurkendoktor 14y agoCan you please provide examples? After uninstalling Facebook, every single third-party app on my phone is built of stock widgets. Some skin them, but that retains both behavior and dimensions. I would even say that the "snob masterclass" of iOS apps is all about using stock widgets in style, like Instapaper and Carcassonne do it. Or only in select places, like Paper, but still seamlessly. The only example of well-received custom widgets on my iPad is eBay.
- pistoriusp 14y agoThis is a PhoneGap app that I just released myself: http://itunes.apple.com/us/app/totally-editable-calculator/id529571185?mt=8 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.
- pistoriusp 14y agoHere are some promo codes, please try it out: TW7XME4JH6RN NWWTRHHNMYPT HKXELLNFFAJM JY9WLFTR9Y7T J4XTAFW9MA6K 4HEL349WWPKH MLNKFM46KAXX 3AL9FJ7LWFW6 AH43J9KA6ERN FH4RFWXMMW76
- hobonumber1 14y agoLooks like you're getting some nice reviews. I do admire the UI. Great job!
- deleted 14y ago[deleted]
- cageface 14y agoThis 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.
- evilgeenius 14y ago> .. swaps one language for another thats it. Remind me what is gained by doing this? Seriously? I'd rather write a web app in Ruby than C++ any day of the week.
- erichmond 14y agoYou lost at "In my opinion any more than one codebase is too many"
- johnyzee 14y agoHere's my PhoneGap app, a fairly spiffy HTML5 game (it got a lot of attention as 'GTA in HTML5'): https://play.google.com/store/apps/details?id=webworks.gangsta 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 http://www.gangstagangsta.com/play)
- gbog 14y agoWhile dling: you have 44 five stars and zero four stars, which sounds like 44 good friends and zero good reviews.
- gbog 14y agoYour game has nice music but ui is way too small on Galaxy note and lagging.
- johnyzee 14y agoYou can try it in the regular browser, I noticed that the app (the WebView) has poor performance on some tablets. Need to look into that.
- johnbender 14y ago"click instead of tap" 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.
- grayrest 14y agoI don't develop phonegap apps but I'll have a go at answering this: > I'm still confused why this matters if you are packaging your assets with the phonegap build which I would expect most people do. Ignoring download time, loading, parsing, and evaluating 250k of javascript is not free[1]. [1] http://carlos.bueno.org/2010/02/measuring-javascript-parse-and-load.html http://carlos.bueno.org/2010/02/measuring-javascript-parse-a... That article is on a desktop (well, laptop) processor. The timings on mobile are obviously higher. JS parse & load is mostly ignored on the desktop but I know I've read at least one article where a team was pulling down their JS as plain text and eval()ing it later to get their load times down.
- johnbender 14y agoI'd be interested to see the actual numbers for jqm here but I don't think the 100-150ms initial load time is a deal breaker for almost any app. Your point is well taken though, and thanks for the link.
- joemoon 14y agoIt's more like 800-900ms. Here is a link to the jquery init time on Android: https://docs.google.com/spreadsheet/ccc?key=0Aq_a4WNAMuCEdDdjSlhyWXJaTkQ0TVJFc1k1RzlTTlE#gid=0 https://docs.google.com/spreadsheet/ccc?key=0Aq_a4WNAMuCEdDd... I don't recall when this kind soul made this document public, but I believe it was in a similar discussion on hacker news and I've had it bookmarked since. I have also done my own tests, and the iOS numbers are similar (depending on the device of course).
- sparknlaunch 14y agoCan someone explain why loading 240k of library files is a negative? Is this a performance issue or a storage issue? If the later, surely consumers don't care about space?
- mkmcdonald 14y agoBecause loading 50+ kB of code when you probably only need 10 kB of it is really stupid. This is compounded by underpowered mobile devices that can't digest a single-page ExtJS "app" with 2 MB of script. Simple is best.
- gcarre 14y agoperformance issue, all this javascript code has to be parsed by the application before it is able to execute it. So you might end up parsing 95% of jquery/jquery mobile code that your application won't use.
- panabee 14y agoone 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?
- andyl 14y agoI've had great experience using Zepto, Backbone & custom styles. Was able to field a single-page app with about a dozen views - very interactive and very fast. Total app size about 25K including support libraries. Data loads asynchronously, cached using localstorage. I ran into endless glitches with JQM, but Zepto/Backbone/CustomCSS has been bulletproof every step of the way.
- panabee 14y agocool, thanks! what did you do for page transitions? we see that zepto handles the touch events and dom events.
- cageface 14y agoI'm heading this way on a PhoneGap app I'm working on right now. Once you give up the goal of a pixel-perfect emulation of a stock iOS UI the combination of Zepto/Backbone/CSS is pretty powerful and much, much faster than Cocoa for prototyping.
- treelovinhippie 14y agoI found a similar problem using Phonegap and JQM. I was also loading another script in and the app became very sluggish. Any recommendations for JQM alternative in regards to UI/design components?
- clarky07 14y agoUsing 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.
- jcromartie 14y agoIt'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.
- gcarre 14y agomaybe 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/ http://phonegap.com/tools/page/2/
- cbetta 14y agoWhat 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.
- dmotz 14y agoI used PhoneGap to develop my app (http://chaincalapp.com 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.
- dmotz 14y agoSome promo codes if anyone's interested in trying it out: LRXTYFWEMJXM JMH34LFNX44W 3N7YXP7HN9P7 PF3RLT4PHWML MWFHXK669M4L
- jaxn 14y agoI redeemed LRXTYFWEMJXM. I dig Quantified Self stuff so I am looking forward to playing with this. Thanks for sharing.
- vgig 14y agoWhat are all the other performance discoveries you made?
- at-fates-hands 14y agoI'm wondering why nobody has brought up Sencha Touch yet. It's got a full MVC framework and easy to get up and running.
- Zelphyr 14y agoThe title is somewhat misleading. Its more of a discussion of why jQuery Mobile sucks.
- snowwrestler 14y agoIf you are building a PhoneGap application, why would you need: -moz-transition: opacity .15s ease-in-out; transition: opacity .15s ease-in-out; A PhoneGap app runs in a Webkit view on both iOS and Android.