JQuery Mobile 1.1.0 RC1
jquerymobile.com
jquerymobile.com
[at the bottom] http://www.sencha.com/blog/sencha-touch-2-raising-the-bar/
Generally Android's stock browser performs really poorly where css animations are concerned.
The Sencha touch team had this sorted out over a year ago. There's really no excuse to not have this feature, or to have a broken implementation. Hopefully the jQuery Mobile team gets it sorted out eventually.
I think the tradeoff is in the learning curve. jQuery Mobile is probably easier for most developers to pick up and get going right away. Sencha Touch could take a bit more work for you to get up to speed with (but they're doing a better job of documenting their API).
To answer your question: I think within a year jQuery Mobile will be lucky to get to where Sencha Touch is now. That should give the Sencha Touch team plenty of room to improve and be a significant improvement over jQuery Mobile for most projects.
To me, the biggest downside to jQuery Mobile is the problems with the fixed navigation. They're relying on the browsers to render that, and it's not where it needs to be (even iOS 5, which finally supports fixed headers/footers is a bit off). Other than doing a full javascript re-write of that, they're only hope is that browser makers fix it, and people upgrade. It could take a while for that to happen, if it ever does. I wouldn't wait around for it.
While I'm not that happy with jQuery Mobile, it does use HTML for layouts. So you can abandon the library without losing all your work. Indeed, I'm starting that process myself right now- custom building something more suitable to my needs, and copy and pasting HTML to bring my existing UI work along with me.
Just because jQuery Mobile lets you use HTML, it doesn't mean that it's easy to swap it with some other library. I think jQuery Mobile will dictate how your HTML looks like to a certain degree. If you ever decide to change the library, I think you will have to re-do the whole UI anyway just like Sencha.
I am not saying that there can not be other reasons to not use Sencha, but in my opinion, this one is not.
Oh, absolutely. But it uses standard elements a lot- so a textbox is an <input>, a dropdown is a <select>, and so on. It depends how much you depend on their UI defaults, but in my case I've found it a very simple process to bring the UI over. It needs some CSS tweaks to look pretty again, but the rest "just works".
The biggest downsides of Sencha Touch I see are: 1. Initial load. The framework is pretty large, even compressed, but CDN, gzip, and cache.manifest files help
2. Device support. Right now they they only support Android and iOS, but this fits the majority of my target.
3. Learning curve. Coming from a jQuery background it took awhile to understand their approach.
I love jQuery for desktop dev. When I tried a previous version of jQuery mobile the experience was not as good overall as Sencha Touch. Looking at the release notes for JQM 1.1, I will be giving it another try.
Sencha uses a javascript scroller to provide the fixed headers and footers. There are two very important reasons the jQuery Mobile project is avoiding this implementation:
1. It doesn't feel native. Sencha has done an enormous amount of work to make sure that the scrolling is efficient and they deserve a lot of credit for their hard work but the physics are different for every platform. 2. To implement scrolling regions on Android you have to `return false` on `touchstart` which breaks the use of form elements in the scrolling region. We, as a project, all agree that's not acceptable.
I'm still pushing my team forward on using jQuery Mobile. I was hoping, praying, that the biggest UX issues would be solved by the time we were ready to launch our app. Unfortunately, it doesn't look like that will be the case.
My biggest issue is one that seems minor on paper, but is infuriating as a user. I'm talking about the 200ms tap delay that is prevalent inside any Mobile Safari instance. I've seen dozens of "fixes" for this issue published in jQuery Mobile builds, but here we are, at March of 2012, and apps still feel incredibly sluggish due to this tap delay.
I'm going to have my devs take a hard look at the behavior to see if they can code up a bespoke solution, but golly, I was really hoping we wouldn't need to waste our time.
Could you prevent the tap delay with onTouch-events?
$('.fastLink').bind("vclick", function (e) {
$.mobile.changePage($(this).attr('href'), "slide");
e.preventDefault();
});Mobile web apps that are advanced websites used through the browser are perceived as useful when they are. However when they try to emulate the look, feel and behavior of a native app, the app falls victim to an uncanny valley where the app feels like a poorly made native app and those feels of negativity overwhelm the experience of utility in many cases.
It is incredibly difficult to pull off a solid mobile app. The only two that I've used that really feel right are Twitter and Facebook. All the others have been subpar.
jQM should try to be a great mobile web app framework and less like a native app emulation framework. Embrace what it means to be a web app instead of trying to disguise it.
I'm not sure if that means you already know about it, but the virtual click infrastructure was built for this specific purpose.
[1/4 of the way down] http://jquerymobile.com/demos/1.0.1/docs/api/events.html
Just make sure you don't use the virtual click events with elements that move as the browser will fire it's post-touch click on what's there when the time comes.