Mobile Web Apps Still Have Some Major Hurdles | Hacker News Reader

Mobile Web Apps Still Have Some Major Hurdles

reefpoints.dockyard.com

71 pointsbcardarella28 comments

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.

I can see your point. I was referring to how dead simple it is to build a nice, professional looking application with jQuery Mobile. It is very easy, requires very little mark up. When the performance gets there I think you'll see a flood of applications just because of the very low barrier of entry to use jQuery Mobile. The jQuery Mobile team has also gone through a lot of effort to ensure the highest amount of cross-compatibility with difference mobile platforms. A goal that, at times, sacrifices performance on higher-end platforms for the sake of ubiquity.

Developing more sophisticated mobile applications with hardware accelerated canvas and CSS is going to be awesome and definitely will allow mobile web apps to compete directly with native apps. But the barrier for entry will be much higher.

Not sure about CSS3, but RIM has promised WebGL on Playbook/BBX soon.

(Sure, it is not a popular platform, but just pointing it out.)

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

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.

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.

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.

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.

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

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.

There's cared and there's has time/money.

Be fair, it's probably the latter.

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.

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.

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.

Right now there really isn't an 'obvious' choice for mobile development. jQuery Mobile doesn't cut it (and needs the mother library, which is really not developed for mobile). It seems you need to roll your own solutions.

What i would really like to see is a library that does more or less the same thing that jQuery ('desktop') does for mobile: provide cross-browser library functions that you need all the time, and automatically picks the best option on that platform (such as CSS3 transforms for animations).

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.

I keep telling myself jQuery Mobile is not 1.0 yet.

A nice alternative suggested in these comments is Spine Mobile http://spinejs.com/mobile/ I've been looking through the docs and I'm impressed. Our next project will give this a spin.

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?

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.

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.

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)

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

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.

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.

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.

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.

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.

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

Reply on news.ycombinator.com