You half assed it. That is why your PhoneGap application sucks.(sintaxi.com)
sintaxi.com
You half assed it. That is why your PhoneGap application sucks.
http://sintaxi.com/you-half-assed-it
22 comments
What are all the other performance discoveries you made?
Why you didnt launch for Andriod?
If you are building a PhoneGap application, why would you need:
-moz-transition: opacity .15s ease-in-out;
transition: opacity .15s ease-in-out;
The title is somewhat misleading. Its more of a discussion of why jQuery Mobile sucks.
You used PhoneGap.. that's why your application sucks.
So under no circumstance is it possible to build a high-quality application using PhoneGap?
Correct. 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.
Even examples of "web with native wrapper" apps, like Facebook and OkCupid, are dramatically, dramatically worse than best of breed native apps.
Interesting 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.
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.
No 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.
First: 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?
If we're to believe that one day HTML5-based mobile web apps will rule, what is wrong with PhoneGap exactly?
Oh, 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.
It 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.
To me, it's like using Java for a Windows desktop app.
I 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.
Can 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.
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.
Could someone please recommend any PhoneGap-based apps that they consider "best-of-breed?"
You could try mine out, I put a lot of love into it.
http://itunes.apple.com/us/app/totally-editable-calculator/i...
Here are some vouchers:
NLXEH6NE7W43
XL6AF63J7K9P
MNJKYR3YAN9M
3ARXXHX3HMYN
6WXJA97FL9LK
http://itunes.apple.com/us/app/totally-editable-calculator/i...
Here are some vouchers:
NLXEH6NE7W43
XL6AF63J7K9P
MNJKYR3YAN9M
3ARXXHX3HMYN
6WXJA97FL9LK
Purchased 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.
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.
I took the last one. I'm very interested in trying PhoneGap. I'll check your app and leave a review. Thanks!
Not listed in Google Play? :( I would have even paid for it to try it.
I'll be porting it this weekend; need to figure out that whole "fragmented" display size issue.
What, you used Phonegap and still made everything pixel/density/size specific? Uh, what?
Figuring it out is probably going to be redoing much of it correctly. You might want to read up on responsive design.
Figuring it out is probably going to be redoing much of it correctly. You might want to read up on responsive design.
The AppBrain library stats page for phonegap lists the top Android apps that are based on Phonegap: http://www.appbrain.com/stats/libraries/details/phonegap/pho...
I'd love to see any that run as smoothly as if they were native.
Here's mine:
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.
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.
I would love it if the OP would chime in here, so we could see what the RubyMotion folks are missing.
> 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.
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.
If 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.
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.
I get the business justification for using PhoneGap, but it doesn't change the fact that you're still half-assing it. Half-assing something with good reason is still half-assing, and the experience is still expectedly sub-par.
I'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.
Especially if the code is using a lot of structs.
Actually, Qt does support the native look and feel on every device I'm aware of (linux, win, mac and symbian). And with Qt quick you can even make any kind of UI you want using QML (a sort of javascript).
The only exception is Android maybe, but it's in an experimental phase at the moment ( look Necessitas at http://sourceforge.net/p/necessitas/home/necessitas/ )
The only exception is Android maybe, but it's in an experimental phase at the moment ( look Necessitas at http://sourceforge.net/p/necessitas/home/necessitas/ )
>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.
This is not actually the case with RubyMotion, since it compiles directly to native code and uses iOS-native UI. A RubyMotion app is indistinguishable from a native Obj-C app.
This is not actually the case with RubyMotion, since it compiles directly to native code and uses iOS-native UI. A RubyMotion app is indistinguishable from a native Obj-C app.
No. What I am saying is RubyMotion does not exempt you from understanding your environment.
That means multi platform frameworks need to be improved,that's all.
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.
Yeah, I may be a bit bitter.
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.
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.
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.
http://friendsdontletfriendsjqm.tumblr.com
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.
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.
So what is a good alternative?
I've used IUI for mobile web apps. It seems faster than JQuery Mobile. See their site below.
http://www.iui-js.org/
http://www.iui-js.org/
Are 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.
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.
I 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.
Yes. Don't use it. Not worth the performance hit.
There 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#issuecom...
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.
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.
I just want to echo want apike is saying. There are several comments here incorrectly stating that this much javascript doesn't matter. It seems pretty obvious that those commenters have no experience developing mobile web apps. Loading jquery is a huge hit, taking anywhere from .5s to 1.5s to initialize, depending on the device and what else is eating up resources at load time.
It'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.
That'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.
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.
Seems mostly academic, no? Do you think fewer people will download a 1.4MB app versus a 1.2MB app?
Zepto 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.
[deleted](1)
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.
jQuery Mobile already handles taps and swipes for you: http://jquerymobile.com/test/docs/api/events.html
Previous discussion: http://news.ycombinator.com/item?id=4063907
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.
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.
some of us prefer to see it as native vs web all over again ;)
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.
Can 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.
The only example of well-received custom widgets on my iPad is eBay.
Just look through the top apps and marvel at how few use the stock UI, even excluding games. Some examples from the top 100:
http://www.appannie.com/app/ios/itranslate-voice/
http://www.appannie.com/app/ios/camera/
http://www.appannie.com/app/ios/instaframe-pro-photo-frame/
http://www.appannie.com/app/ios/djay-for-iphone-ipod-touch-s...
http://www.appannie.com/app/ios/motionx-gps-drive/
http://www.appannie.com/app/ios/nick-jr-draw-play/
http://www.appannie.com/app/ios/itranslate-voice/
http://www.appannie.com/app/ios/camera/
http://www.appannie.com/app/ios/instaframe-pro-photo-frame/
http://www.appannie.com/app/ios/djay-for-iphone-ipod-touch-s...
http://www.appannie.com/app/ios/motionx-gps-drive/
http://www.appannie.com/app/ios/nick-jr-draw-play/
I'm looking through the top free iPhone apps in Germany and I can't see a clear trend. Also, I'm not sure how to prove or disprove my point - because being a top app is orthogonal to looking like an amateur effort. WhatsApp has long been #1 here, and while I welcome its stock navigation UI for usability reasons, I think their tacked-on timestamps are as "amateur" as their name.
In the top paid apps in the U.S. the trend is overwhelming. Think what you like about the aesthetics of those apps but they're the ones making money.
Well you said amateur, I thought that was about aesthetics. :)
I took the time to analyze Top Grossing US without games. I've gotten a lot of inquiries about HTML5 based apps recently, so this was interesting.
#3 MLB, stock; #5 Pandora, stock; #12 MotionX GPS, custom; #17 and #26 comics, slightly customized navigation bar & stock tab bar; #27 Zoosk, faux stock UI; #30 eHarmony, stock; #38 TeleNav, stock; #46 WhatsApp, stock; #52 iTranslate, custom; #68 Nike+ GPS, stock; #72 Camera+, rather custom; #74 MyCalendar, stock; #81 Pages, stock; #83 DC Comics, slightly customized navigation & stock tab bar; #85 Grindr, sotck; #86 Instaframe, custom; #88 Badoo, stockish; #90 Free Music Download, stock; #93, Palm Reader, custom; #96 TurboScan, stock; #97 iMovie, stock where applicable.
Some of the UIs are badly imitating UIKit, like Zoosk. They still often replicate the navigation concepts, UIKit shadows (skeuomorphism), widget sizes … - I don't think the stock look & feel is dead yet.
I took the time to analyze Top Grossing US without games. I've gotten a lot of inquiries about HTML5 based apps recently, so this was interesting.
#3 MLB, stock; #5 Pandora, stock; #12 MotionX GPS, custom; #17 and #26 comics, slightly customized navigation bar & stock tab bar; #27 Zoosk, faux stock UI; #30 eHarmony, stock; #38 TeleNav, stock; #46 WhatsApp, stock; #52 iTranslate, custom; #68 Nike+ GPS, stock; #72 Camera+, rather custom; #74 MyCalendar, stock; #81 Pages, stock; #83 DC Comics, slightly customized navigation & stock tab bar; #85 Grindr, sotck; #86 Instaframe, custom; #88 Badoo, stockish; #90 Free Music Download, stock; #93, Palm Reader, custom; #96 TurboScan, stock; #97 iMovie, stock where applicable.
Some of the UIs are badly imitating UIKit, like Zoosk. They still often replicate the navigation concepts, UIKit shadows (skeuomorphism), widget sizes … - I don't think the stock look & feel is dead yet.
By "amateur" I mean that I think the typical app consumer is getting pretty good at spotting stock UI and tends to equate that with a slapdash app, justified or not.
This is more pronounced on the iPad I think.
This is more pronounced on the iPad I think.
I think you're misunderstanding. Of your examples, all of them use stock widgets, except for the last two.
In the last two they replaced stock controls with custom ones, even where they didn't have to, and that supports your hypothesis.
But all of the others, however, are using stock controls for all the controls where there is a stock control, and only using custom controls where there is no stock control.
The ability to customize the stock controls has increased a fair bit and gotten more popular as its gotten easier. But these developers (at least, I can't speak for the whole appstore) are using the standard controls.
What is true is that they aren't using the blue-pinstripe look of the original iPhone anymore.
The reason this distinction is important is that its a whole lot harder to do a custom control (like a turntable) than it is to use a standard control, and its also very easy to take that standard control and make it just the right shade of grey, or make it look like wood, etc.
Thus customizing how these standard controls look has gone up dramatically, yes.
In the last two they replaced stock controls with custom ones, even where they didn't have to, and that supports your hypothesis.
But all of the others, however, are using stock controls for all the controls where there is a stock control, and only using custom controls where there is no stock control.
The ability to customize the stock controls has increased a fair bit and gotten more popular as its gotten easier. But these developers (at least, I can't speak for the whole appstore) are using the standard controls.
What is true is that they aren't using the blue-pinstripe look of the original iPhone anymore.
The reason this distinction is important is that its a whole lot harder to do a custom control (like a turntable) than it is to use a standard control, and its also very easy to take that standard control and make it just the right shade of grey, or make it look like wood, etc.
Thus customizing how these standard controls look has gone up dramatically, yes.
What is true is that they aren't using the blue-pinstripe look of the original iPhone anymore.
That's what I mean and that's why I don't think people should waste so much time trying to emulate that look down to the last pixel in Phonegap apps. Users don't care anyway as long as your app looks good.
That's what I mean and that's why I don't think people should waste so much time trying to emulate that look down to the last pixel in Phonegap apps. Users don't care anyway as long as your app looks good.
Oh, I guess Flipboard is also mostly customized. There's probably a stronger incentive to come up with your own stuff on a tablet where UIKit is not as helpful for the overall navigation. For example, the eBay phone app still looks like Apple could've built it.
The left side drawer in Twitter and Sparrow is amazing. Like it should have always been there.
I totally agree with this example. Both eBay for iPad and Facebook use that concept too, so to most users it will probably feel like a stock widget already. I hope it will eventually become one :)
It's not about the widgets - it's about how smooth the app works, and what it does. The fancy widget or two like accents (necessary like decor) can take a basic stock widget pile and allow the user to focus on what they're using the app for...
But the argument isn't just about native look and feel vs custom. This is native code vs some ported over stuff that doesn't run quite as well.
And 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.
> I think we all know how horrible Java apps feel on OS X, because it uses a slightly different UI paradigm (one menu bar).
When this is brought up, I point people to Cyberduck. http://cyberduck.ch/
When this is brought up, I point people to Cyberduck. http://cyberduck.ch/
Your point being that Cyberduck is not 'native', but people still like it because it gets the job done? Sorry, I'm not familiar with cyberduck but that's what I gleaned from looking at that site.
Cyberduck is a Java app. It looks decent and follows the OS X paradigm of a single menu bar at the top of the screen.
My point is it's possible to do a functional and native-looking app with non-native tools. But of course, not all tools are equal. I was just answering to Java on OS X.
My point is it's possible to do a functional and native-looking app with non-native tools. But of course, not all tools are equal. I was just answering to Java on OS X.
Wow. I use cyberduck all the time, this has to be the first app that's java that I didn't know was written in java either through generally sluggishness or horrid UI.
>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.
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.
[deleted]
This is a PhoneGap app that I just released myself:
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.
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.
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.
Here are some promo codes, please try it out:
TW7XME4JH6RN
NWWTRHHNMYPT
HKXELLNFFAJM
JY9WLFTR9Y7T
J4XTAFW9MA6K
4HEL349WWPKH
MLNKFM46KAXX
3AL9FJ7LWFW6
AH43J9KA6ERN
FH4RFWXMMW76
TW7XME4JH6RN
NWWTRHHNMYPT
HKXELLNFFAJM
JY9WLFTR9Y7T
J4XTAFW9MA6K
4HEL349WWPKH
MLNKFM46KAXX
3AL9FJ7LWFW6
AH43J9KA6ERN
FH4RFWXMMW76
[deleted]
Looks like you're getting some nice reviews. I do admire the UI. Great job!
> .. 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.
Seriously?
I'd rather write a web app in Ruby than C++ any day of the week.
You lost at "In my opinion any more than one codebase is too many"
Here'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.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)
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)
While dling: you have 44 five stars and zero four stars, which sounds like 44 good friends and zero good reviews.
"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.
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.
I 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-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.
> 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-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.
I'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.
Your point is well taken though, and thanks for the link.
It's more like 800-900ms. Here is a link to the jquery init time on Android: 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).
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).
People sometimes have slow connections, particularly BB users who feel no need upgrade to the latest connection speed. The app has to be completely downloaded before it runs, unless you put external references in your PhoneGap packaged HTML, I guess, but then it would only run online.
Additionally mobile browsers are often slow to execute, so loading a lot of JS can bog down your app. For a while there was a big stink about iOS only using their best JS engine in Safari and not web controls, not sure if that every got solved, but laggy HTML based apps is a big problem.
Additionally mobile browsers are often slow to execute, so loading a lot of JS can bog down your app. For a while there was a big stink about iOS only using their best JS engine in Safari and not web controls, not sure if that every got solved, but laggy HTML based apps is a big problem.
Here's the standalone vmouse I use. It can be dropped into any project alone whereas the jquery team's vmouse cannot. https://github.com/michaeldhopkins/jquery-mobile-abstract-to...
Can 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?
Because 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.
Simple is best.
performance 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.
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?
I'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.
I'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.
cool, thanks! what did you do for page transitions? we see that zepto handles the touch events and dom events.
I 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?
Any recommendations for JQM alternative in regards to UI/design components?
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.
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.
I would like to see a light-weight Javascript UI and MVC library that is recommended by Phonegap.
I'm wondering why nobody has brought up Sencha Touch yet. It's got a full MVC framework and easy to get up and running.
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.