I want to believe, but every time I try their menus on my iPhone 4 I'm disappointed by jerkiness and delay. In particular if you scroll down on the demos page and click a menu item, you see
1) the page *jerk* to the top
2) a loading dialog with a spinner over the whole page
3) a *nice* smooth animation into the new page
Then when pressing the back button:
4) a nice smooth animation to the *top* of the screen
I've lost my place! Actually navigating a hierarchy with this is painful, slow and disconcerting.
Can anyone from the project comment on what the technical reason for this is?
If you think it's bad on the iPhone 4, imagine how bad it is on a 2 year old Samsung Moment running Android 2.1. I've spent a lot of time trying to make basic touch interaction halfway responsive on older phones (read: anything but the newest phones), and all my efforts (which include trying jQuery Mobile, Sencha Touch, and jQTouch, as well as a bunch of from-scratch CSS and JS work) have been met with failure. I've concluded that, if you really care about and are paying attention to the details of user interaction in your app, the current state of native-feeling web apps just isn't there yet. The issues I've encountered are split about 50/50 between slow JS/rendering performance and non-standardized DOM event behavior.
1. I don't believe their site/demos are running the latest version of jQuery mobile (weird, I know).
2. Secondly, the resetting behavior can be easily handled now with the addition of beforechangepage by setting the current scroll position before transition and using $.mobile.silentScroll to update on page re-entry.
Sigh... Yeah, just evaluated this, Sencha, M-project and a bunch of others on Android 3.2 tablet and decided to stick with the native UI.
There is enough jerkiness and little things that make it annoying to use. Heck, Sencha ended up displaying a big giant white blank rectangle covering most of the screen. And these are their own demos (!).
- pushState support for clean URLs
- beforechangepage event (for apps that generate HTML server-side)
- Support for iOS 5's true fixed toolbars & better transitions
One of my issues is the "fixed" toolbars moving around or disappearing while navigating. Glad they've improved this, even if it's only for iOS5 and the platforms that support overflow properties natively.
I've always found this an unacceptable part of their library. It's not impossible, and not even especially difficult (it's just some viewport adjustments). Sencha Touch got this right a long time ago. Fixed toolbars should be fixed, the whole point of using a library like this is to abstract away the individual device implementation details. Waiting it out, until the manufacturer implements it just seems lazy and unprofessional, especially since it was an easy fix that just never got implemented.
When we evaluated Jquery Mobile, it just seemed to fall short of promise. It seemed to be too inflexible for "skinning" and added more bloat than using plain jquery with Mobile Boilerplate which turned out to be lighter and faster.
14 comments
[ 2.7 ms ] story [ 49.8 ms ] threadCan anyone from the project comment on what the technical reason for this is?
1. I don't believe their site/demos are running the latest version of jQuery mobile (weird, I know). 2. Secondly, the resetting behavior can be easily handled now with the addition of beforechangepage by setting the current scroll position before transition and using $.mobile.silentScroll to update on page re-entry.
I suspect this is a testament to the difficulty of cross browser/device mobile development in general.
There is enough jerkiness and little things that make it annoying to use. Heck, Sencha ended up displaying a big giant white blank rectangle covering most of the screen. And these are their own demos (!).
http://html5boilerplate.com/mobile/