

Mobile Web Apps Still Have Some Major Hurdles - bcardarella
http://reefpoints.dockyard.com/2011/11/10/mobile-web-apps.html

======
jbail
_Closing the performance gap on jQuery Mobile is going to be a watershed
moment for mobile web application development._

I've worked with jQuery Mobile and I need to disagree. jQuery Mobile doesn't
add much to mobile web app development. It's just a UI toolkit that offers
boilerplate styling and page navigation/transitions.

I'm not trying to take away from the usefulness of jQuery Mobile for some
people, but it doesn't bring a lot of excitement to mobile web.

You touched on the real watershed event in mobile web development though ---
which will be hardware accelerated WebGL and hardware accelerated CSS3
animations. When that happens, it'll be a whole new world for mobile web apps.

~~~
johnbender
"jQuery Mobile doesn't add much to mobile web app development."

Hmm, I think you've glossed over the rather large set of browser quirks that
the library addresses for you. Here are few choice examples off the top of my
head:

1\. Touch and Click events: Different platforms and hardware will fire
different events. The vmouse additions unify the two possible event sources to
make handling easier for developers

2\. (push|replace)State: iOS 4.x and some desktop browsers have critical bugs
in their implementations that are handled for you where possible.

3\. Orientation values on orientationchange events: Different browser
implementations fire this event at different times relative to the actual
screen size. It doesn't solve the timing issue but it does provide the right
orientation value for use regardless.

If you're only implementing for iOS you might be right, but if you have a
large set of target devices it does provide a lot of value.

[EDIT] I should point out that I agree completely with the article. I'm
actually rather tired of people selling html5 as the end-all solution for
mobile app development right now. There are a lot of hurdles yet to overcome.

------
satjot
I agree with most of your points. The one thing I would add is that Apple and
Google will continue to innovate on their OS so they are always a few steps a
head of web apps. For example, once Siri is open to developers, voice
interaction with apps will be something that continues to make a native iOS
app better than a web app.

It'll be a cat and mouse game for years to come.

~~~
bcardarella
This is an excellent point that I forgot to mention in the article. The native
APIs will always be ahead of the mobile web APIs. The MediaCapture stuff is
still just a working draft whereas that functionality has been around on
native since day 1.

------
agentultra
Native apps will have an advantage for a while still, but I think the
direction we're heading with this technology is pretty obvious.

This is the same battle we had on the desk tops in the 90s.

This time I don't think it's going to take the web a decade to catch up.
Hopefully.

I really think that HTML5/Javascript is going to replace most native apps on
mobile. It's not going to happen tomorrow or next year... but four years?
Three? It seems like that could be possible.

~~~
satjot
the question for people like us developing for mobile is what is best for our
users today - and the answer is native (in most cases). and as you mention,
it's probably the right answer for a few years to come.

note: there are a bunch of apps that I've come across that are just 4 views of
static content and no interactive functionality. those should definitely stay
html5/javascript.

~~~
bcardarella
Exactly, for many use cases a mobile web application fits perfectly.

------
quinndupont
I've always liked the idea of PhoneGap, especially because it lowers the
difficulty of native (C++) development significantly. But, it's a dangerous
tool. I've seen far too many unambitious companies produce PhoneGap apps that
are just a wrapped up version of their mobile site. Even simple things like
offline (possible in HTML5 if the developers cared) don't get implemented.

~~~
bcardarella
Offline mode is definitely something we're trying to be better with at
DockYard. Backbone.js has made this much more easy. We can have the models
persist to local storage or remote depending upon the state of the connection
(which is easily determined with PhoneGap) Our background is working with web
applications and working in offline mode is somewhat of a mind-warp right now.
But a feature complete application should have it. You never want to lose
data.

------
agentgt
I built a mobile site (<http://evocatus.com/m>) and lesson learned: JQuery
Mobile while incredible easy to use is absolute performance crap.

I really really wish I used Sencha Touch.

~~~
bcardarella
I started out with Sencha Touch. The performance is much better, but
developing in Sencha Touch is a nightmare. Maybe if I was building the JOSN
objects with CoffeeScript it would have made life easier. But tracking down
the syntax errors for these super nested JSON objects is not something I
recommend.

What I would like to see in jQueryMobile is a way to pre-enhance my multi-page
applications. Then you can turn off dynamic page enhancements and everything
should be fine.

------
catshirt
i've been working recently on implementing "native" functionality on mobile
web- scrollview, pull to refresh, native-style transitions, etc. jquery mobile
falls disappointingly short in all these areas, and even others that it
supposedly supports.

however, look at the google plus mobile site for a nearly flawless mobile
experience. it's most certainly possible. to this end, i have a lot of faith
in jquery mobile. if it is possible, they are one of the most qualified teams
to deliver it.

that is of course, not to say that mobile web doesn't have it's hurdles.

~~~
johnbender
Aside from the scrollview and transitions which are mostly a function of
hardware acceleration or lack thereof, what other areas is the library falling
short for you?

~~~
catshirt
first i'd like to say i am perhaps being over critical, i think it's a
fantastic library (framework). i just realize how intensely better it could
be. my biggest pet peeve is that it is indeed a framework, not a library. i
really wish they had taken a route similar to jquery ui- and not try to force
so much on you. this is for another post though.... as far as your question
goes:

i don't think it's true to say scrollview and transitions are a lack of
hardware support. again, on my iphone 3gs and 4s the google+ app is flawless
in both of these areas. jquery mobile is subpar. the scrollview is obviously
forgivable since it is still experimental. for what it's worth, i still think
it's a far superior choice to iscroll.

the first issue i'll bring up is their fixed header and footer support. i
think it's a decent solution for the tools they have available, but i'd never
use it myself with it's current behavior. i do realize this is probably a
consequence of scrollview support though.

another problem they've yet to solve is url bars dropping down while
navigation. i understand given the circumstances, this is a difficult problem
to solve without going against jqm's principles.

i am also not particularly fond of how their active states trigger on scroll,
this is obviously not desirable.

my argument is not that there is much that is missing from jquery mobile, like
i said i have a lot of faith in the project. stuff like url bars, active
states, and page transitions may only be the last 10%- but that last 10% is
crucial for the final polish of a real release.

~~~
johnbender
Thanks for your expanded response. Each of the items you've listed is
important and all of your concerns are high on our priority list (I work on
jqm full time for Adobe).

My original question was poorly formed. I only meant to imply that transition
quality is mostly a function of hardware acceleratio. Scrolling isn't
necessarily, though it can play a roll there through hacks like translate3d.
Both the 3gs and 4s have hardware accelerated transforms, which is why
transitions look so much better on an iPhone. Additionally if we could target
_just_ the iPhone it would make our transitions nearly flawless, but getting
them to work in as many places as possible makes this difficult.

Headers and footers are a pain point right now without a doubt, but there are
specific reasons we don't use scrollviews (mostly due to the fact the
returning false on touchstart in Android breaks inputs).

In any case, I'd just like to thank you again for taking the time to respond,
and let you know that we are _acutely_ aware of all of these issues.

------
maccman
Spine Mobile strives to give a native experience with web technologies
(CoffeeScript, CommonJS, MVC & Spine). It's worth checking out if you're
looking into jQuery Mobile: <http://spinejs.com/mobile>

(disclaimer - I'm the author)

~~~
huskyr
Will check it out for sure. Your MVC framework rocks!

------
buff-a
_Perhaps Adobe's announcement that they are abandoning Flash in favor of HTML5
for mobile will be seen as the turning point when mobile web application
development begins to be a serious contender to native._

Adobe AIR works right now.

------
protomyth
I keep thinking of various Smalltalk implementations and how the non-native
widgets and lack of hooks into the OS make it a hard sell. It seems like Web
Apps are having quite a lot of the same issues.

------
billpatrianakos
Native wins on the points in the post for sure. Native functionality, storage,
and background processes are important but not always necessary.

I work in web development with most of my clients needing simple brochure
sites with a small minority wanting a web application. From my experience I
think that people really underestimate the power of a web app. Even my
brochureware clients ask if they need a mobile app and there are tons more who
are potentially flooding app stores with unnecessary app like that. My one web
app client asked about a mobile app and I said he didn't need one. It's if all
you want to do is CRUD it's not worth the time, money or energy. So yeah, the
post is right but as usual, I worry about the people who read this who may
believe they need a native app when really they need a few media queries.

~~~
bcardarella
I wasn't discounting web apps, we believe and want to work towards this
future. The point I was making is that mobile web apps won't completely
replace native apps any time soon.

~~~
billpatrianakos
I know, and I totally agree. I honestly have no qualms with what you say. One
point I wanted to make was just that inevitably there will be people who read
this as something that endorses the idea that they personally need a native
app even though that's just not anywhere in there. It's not your fault, its
just something I notice. Tons of people come to me and say "I read this
article about x and now I want x too" regardless of whether it makes sense or
not.

~~~
bcardarella
I sure hope not as we actually build mobile web apps :)

