It's nice to see that they're putting effort into this, but the "True Fixed Toolbars" are still broken. That's been the biggest reason I've avoided the project so far. They're using css fixed positioning which is now better supported on mobile devices, but it produces an "uncanny valley" effect now. The "fixed" toolbars move up and down slightly as the page scrolls. That gives you 99% of the effect you're going for, but that 1% just makes it feel awkward and out-of-place.
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.
How does Sencha Touch compare to jQuery Mobile, in general? They are both open source, which is desirable, but I'm not sure which one will mature the most in the next year or so.
Sencha Touch feels a lot further along in development. They've been "feature complete" for a while, and most of their focus is on performance.
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.
I decided against Sencha Touch because it doesn't use HTML- you construct the entire site using their JS functions. So if you ever want to transition away from Sencha, you can't- you're locked in.
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.
With all due respect, I don't think this is a strong enough reason against Sencha.
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.
I think jQuery Mobile will dictate how your HTML looks like to a certain degree.
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".
I quickly build a mobile web app using jQuery Mobile and re-used a lot of code and functionality from our desktop web app. I had to disable some jQuery Mobile functionality but I had something working in less than a week. This wouldn't have been possible if jQuery mobile isn't just a wrapper over HTML and JavaScript.
I use Sencha Touch on a daily basis, and have used it since version 1.0 (v2.0rc is now out). Clients love it because it comes close enough to native performance for data presentation apps. I also enjoy writing apps entirely in JS. I have also learned a lot about JS reviewing the source code.
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.
Hi, I work on the project full time so maybe I can address this directly.
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.
Which device/browser are you referring to? I cannot duplicate the toolbars moving up and down slightly as the page scrolls in safari on a 3GS (iOS 5), with the latest RC demo.
Sencha and jQuery Mobile seem to be solving two very different problems. jQM delivers something that works across a variety of browsers that Sencha is not capable of serving to. Doing this will limit some of the solutions that can be put into place, for certain.
"Unfortunately, after a ton of work, we’ve determined that it’s not possible to dumb down page transitions enough to get acceptable performance in Android 2.x, even on a newer device like a Nexus S running 2.3."
It's incredibly frustrating to want, more than anything, to build a cross-platform mobile app that _feels_ native and still it's not a realistic expectation.
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.
Don't blame jQuery Mobile for that. It's a result of a bunch of time-based heuristics that sometimes don't work the way you expect. You can always override them (at your peril) by going for the immediate events like touchstart.
I think it's best not to try an emulate native iOS and Android apps because the experience will almost inevitably be subpar and lead to what I call the "mobile web app uncanny valley".
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.
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.
Yes, the .tap() stuff is a holdover from jQTouch. It doesn't work very well, with some things responding correctly (buttons) and others not (inputs/checkboxes).
I was talking about the virtual mouse events. It abstracts over touch and click events so you can bind to "both" by binding to "vclick" while still getting the faster responses.
26 comments
[ 4.9 ms ] story [ 74.1 ms ] threadThe 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.
[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.
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?
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.