

JQuery Mobile 1.1.0 RC1 - johnbender
http://jquerymobile.com/blog/2012/02/28/announcing-jquery-mobile-1-1-0-rc1/

======
w-ll
"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."

~~~
johnbender
You'll note this problem is not isolated to jQuery Mobile:

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

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

~~~
melling
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.

~~~
kmax12
Sencha touch is way ahead in my opinion. just check out the kitchen sink demos
of Sencha: <http://dev.sencha.com/deploy/touch/examples/kitchensink/> and
jquery mobile: <http://jquerymobile.com/demos/1.1.0-rc.1/>

~~~
duko2
sencha's kitchensink page completely fails to render in my Opera browser.

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

~~~
johnbender
> I've seen dozens of "fixes" for this issue published in jQuery Mobile builds

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.

~~~
mvkel
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).

~~~
johnbender
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.

------
deepkut
Typo: our scrolling feels 100% native because is _is_.

