4 ms·

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 nee

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

by jbail 15y ago

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.