5 ms·

Mobile Web Apps Still Have Some Major Hurdles

71 points by bcardarella 15y ago

protomyth 15y ago
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.
quinndupont 15y ago
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.
- mattmanser 15y ago
  There's cared and there's has time/money. Be fair, it's probably the latter.
- bcardarella 15y ago
  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 15y ago
I built a mobile site (http://evocatus.com/m 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 15y ago
  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.
- huskyr 15y ago
  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).
jbail 15y ago
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.
- bcardarella 15y ago
  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.
- codedivine 15y ago
  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.)
- johnbender 15y ago
  "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 15y ago
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 15y ago
  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 15y ago
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 15y ago
  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 15y ago
    Exactly, for many use cases a mobile web application fits perfectly.
billpatrianakos 15y ago
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 15y ago
  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 15y ago
    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 15y ago
      I sure hope not as we actually build mobile web apps :)
maccman 15y ago
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 http://spinejs.com/mobile (disclaimer - I'm the author)
- huskyr 15y ago
  Will check it out for sure. Your MVC framework rocks!
catshirt 15y ago
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.
- bcardarella 15y ago
  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/ http://spinejs.com/mobile/ I've been looking through the docs and I'm impressed. Our next project will give this a spin.
- johnbender 15y ago
  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 15y ago
    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.
buff-a 15y ago
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.

71 points by bcardarella 15y ago

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.

quinndupont 15y ago

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.

mattmanser 15y ago
There's cared and there's has time/money. Be fair, it's probably the latter.
bcardarella 15y ago
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 15y ago

I built a mobile site (http://evocatus.com/m 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 15y ago
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.
huskyr 15y ago
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).

jbail 15y ago

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.

bcardarella 15y ago
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.
codedivine 15y ago
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.)
johnbender 15y ago
"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 15y ago

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 15y ago
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 15y ago

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 15y ago
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 15y ago
  Exactly, for many use cases a mobile web application fits perfectly.

billpatrianakos 15y ago

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 15y ago
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 15y ago
  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 15y ago
    I sure hope not as we actually build mobile web apps :)

maccman 15y ago

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 http://spinejs.com/mobile (disclaimer - I'm the author)

huskyr 15y ago
Will check it out for sure. Your MVC framework rocks!

catshirt 15y ago

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.

bcardarella 15y ago
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/ http://spinejs.com/mobile/ I've been looking through the docs and I'm impressed. Our next project will give this a spin.
johnbender 15y ago
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 15y ago
  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.

buff-a 15y ago

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.