
You half assed it. That is why your PhoneGap application sucks. - sintaxi
http://sintaxi.com/you-half-assed-it
======
fleitz
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.

~~~
cageface
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.

~~~
gurkendoktor
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.

~~~
cageface
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/djay-for-iphone-ipod-touch-
scratch-mix-dj/)

<http://www.appannie.com/app/ios/motionx-gps-drive/>

<http://www.appannie.com/app/ios/nick-jr-draw-play/>

~~~
gurkendoktor
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.

~~~
cageface
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.

~~~
gurkendoktor
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.

~~~
cageface
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.

------
johnbender
"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
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...](http://carlos.bueno.org/2010/02/measuring-javascript-parse-and-
load.html)

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
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.

~~~
joemoon
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...](https://docs.google.com/spreadsheet/ccc?key=0Aq_a4WNAMuCEdDdjSlhyWXJaTkQ0TVJFc1k1RzlTTlE#gid=0)

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).

------
elliottkember
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.

~~~
sintaxi
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.

~~~
elliottkember
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.

------
pistoriusp
This is a PhoneGap app that I just released myself:

[http://itunes.apple.com/us/app/totally-editable-
calculator/i...](http://itunes.apple.com/us/app/totally-editable-
calculator/id529571185?mt=8)

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
Here are some promo codes, please try it out:

TW7XME4JH6RN

NWWTRHHNMYPT

HKXELLNFFAJM

JY9WLFTR9Y7T

J4XTAFW9MA6K

4HEL349WWPKH

MLNKFM46KAXX

3AL9FJ7LWFW6

AH43J9KA6ERN

FH4RFWXMMW76

~~~
steve19
Used AH43J9KA6ERN

Nice app. Simple, works. Just need to make it iPad compatible.

------
dmotz
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.

~~~
dmotz
Some promo codes if anyone's interested in trying it out:

LRXTYFWEMJXM

JMH34LFNX44W

3N7YXP7HN9P7

PF3RLT4PHWML

MWFHXK669M4L

~~~
jaxn
I redeemed LRXTYFWEMJXM.

I dig Quantified Self stuff so I am looking forward to playing with this.
Thanks for sharing.

------
johnyzee
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...](https://play.google.com/store/apps/details?id=webworks.gangsta)

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
Your game has nice music but ui is way too small on Galaxy note and lagging.

~~~
johnyzee
You 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.

------
sheriff
Could someone please recommend any PhoneGap-based apps that they consider
"best-of-breed?"

~~~
pistoriusp
You could try mine out, I put a lot of love into it.

[http://itunes.apple.com/us/app/totally-editable-
calculator/i...](http://itunes.apple.com/us/app/totally-editable-
calculator/id529571185?mt=8)

Here are some vouchers:

NLXEH6NE7W43

XL6AF63J7K9P

MNJKYR3YAN9M

3ARXXHX3HMYN

6WXJA97FL9LK

~~~
drivebyacct2
Not listed in Google Play? :( I would have even paid for it to try it.

~~~
pistoriusp
I'll be porting it this weekend; need to figure out that whole "fragmented"
display size issue.

~~~
drivebyacct2
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.

------
powrtoch
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?

~~~
devgeeks
<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.

~~~
skilesare
So what is a good alternative?

~~~
johncarpinelli
I've used IUI for mobile web apps. It seems faster than JQuery Mobile. See
their site below.

<http://www.iui-js.org/>

------
clarky07
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.

~~~
jcromartie
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.

------
gcarre
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/>

------
evilgeenius
> .. 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.

------
at-fates-hands
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.

------
erichmond
You lost at "In my opinion any more than one codebase is too many"

------
cbetta
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.

------
snowwrestler
If 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.

------
treelovinhippie
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?

------
evilduck
Previous discussion: <http://news.ycombinator.com/item?id=4063907>

------
panabee
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?

~~~
andyl
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.

~~~
cageface
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.

------
Zelphyr
The title is somewhat misleading. Its more of a discussion of why jQuery
Mobile sucks.

------
franzus
> 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
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.

~~~
potatolicious
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.

------
sparknlaunch
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?

~~~
mkmcdonald
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.

------
gfosco
You used PhoneGap.. that's why your application sucks.

~~~
kevincennis
So under no circumstance is it possible to build a high-quality application
using PhoneGap?

~~~
colinplamondon
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.

~~~
kevincennis
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.

