JQuery Mobile 1.3.0 Released | Hacker News Reader

JQuery Mobile 1.3.0 Released

jquerymobile.com

45 pointslaurent12345618 comments

It looks great - in theory - but for some reason the performance seems to be dismal. I put together a site using an older version of jqmobile about a year ago and was impressed how smooth and quick the widgets worked, even on a 1G iPad.

I just went through the demo site on my iPad 3 and it just seems terrible - slow, improper rendering on a bunch of elements, stuttering transitions, etc.

Is anyone else finding this? Perhaps something is amiss on my iPad, but my impression is not great so far...

It's broken in chrome on desktop to...

I don't have experience with jquery mobile - but dojox.mobile from dojotoolkit gave me some very nice results and i've built some nicely performing applications with it. You might want to look into that.

An older version of jqmobile used some kind of FastClick technique, but it was causing too many compatibility issues on android devices. Projects like these need to strike a fine balance between usability and device-awareness, but there are a number of exposed options in the library where you can optimize for specific devices.

JQuery Mobile is horrible for mobile applications, IMO.

The intrinsic stylesheet, with its rounded corners, box shadows and text shadows results in extremely poor rendering performance in mobile browsers. This can be rectified with work, but it demonstrates to me that their contributors are not at all concerned with performance. Its markup is node heavy (a single LI turns in to 5 elements). Considerations are made for desktop browsers, yet it is proselytized as a mobile framework.

Developing with it is cumbersome; the selectors you thought would work do not, because your element has been munged and wrapped with numerous other elements. Triggering "create" more than once sometimes wraps elements a second time because some widgets don't check their classes properly to know they've already been marked up. The only way to know the widget has been created is either checking for known classes or attempting to access one of its methods in a try/catch.

Some widgets respond to "refresh" - some don't. Some parts of widgets respond to it, some don't. This makes partial view updates almost, or completely, impossible. I have been slowly replacing JQM's functionality with backbone views and it is working much, much better.

If you use jQuery Mobile in your mobile application, I advise you do so with an exit strategy in mind.

I tried building an app with jQuery Mobile and the performance was horrible. Whole sets of features didn't work. I spent more time trying to get things working right than I did building the actual functionality. I had a lot more success in Kendo Mobile.

If jQuery Mobile wasn't backed by the jQuery project, nobody would use it because it isn't that good. It's slow, buggy, and broken. Maybe this release fixes that, but I doubt it.

I endorse that. Wanted something lightweight to service some lage number of static pages on android and jQuery M performed just too bad.

Last time a tried using JQuery Mobile for an Android 4.0.3 HTML5 app, button presses didn't work consistently/correctly and the performance was terrible. Also there is still that whole JQuery dependency thing. Until the Android Webview's robustness increases or JQuery/JQuery Mobile improve support for the Android webview I will stick to my Zepto + MV* Framework + Custom Transitions stack for Android HTML5 development.

Is there a "standard" way of detecting mobile devices and loading jQuery Mobile along with your site's mobile JavaScript instead of the desktop version?

Right now I'd do it like this:

  Modernizr.load({
    test: Modernizr.touch,
    yep : ['jquery-mobile.js','mobile.js']
    nope: ['jquery-ui.js','desktop.js']
  });

With the advent of touchscreen laptops, this method is becoming less reliable.

Yup. Realised that after I posted. A way to tell if it has a HW keyboard attached would be useful. Although the user could prefer either method, and what do you do if they detach the KB?!?

Could anybody with experience building mobile webapps comment on jQuery Mobile vs Sencha Touch?

It seems like if you are not building with responsive HTM5/CSS3 you may as well use a JS library for better UI. These are the two biggest names I have seen and it is difficult figuring out if either one is worth the time.

I was working on making a mobile web app a few weeks back and after quickly deciding that a js framework would be better than a responsive site (lots of widgets, built-in ajax functionality and push-state) I tried both jQ mobile and jQ Touch[0]. Both are quite similar in most respects(learning curve, widgets, etc.) However, if you're looking to completely overhaul the look then jq Mobile, IMHO, is not that great. I found the themeroller[1] to be clunky and difficult to use and would've preferred writing css. jqTouch, on the other hand, is quite customizable (allows SASS based theming).

[0] - http://www.jqtouch.com/

[1] - http://jquerymobile.com/themeroller/index.php

There's nothing that prevents you from writing CSS for JQM. The ThemeRoller is simply a setup tool intended to make it easier for the masses. I've actually found there's very little customization needed based on the JQM structural base CSS.

See: http://code.jquery.com/mobile/1.3.0/jquery.mobile.structure-...

Sencha Touch is derived from jQtouch code base and is really fast compared to jQueryMobile. jQM is slow but is easier to start with than Sench Touch. But Sencha Touch really is a great product.

Sencha and jquery mobile have slightly different techniques.

With Jquery your app is an HTML page with your own markup which is then styled and functionality is added to your elements by the framework. I find it more designer-oriented compared to sencha.

With Sencha your app is usually just a single div and everything is done through JavaScript. I find it more programmer-oriented. It has been a couple of versions since I used sencha seriously but that is how it was at the time.

Can't compare with Sencha Touch, but the one app I built with jQuery Mobile started out okay, and seemed to be saving us time at the prototyping stage. We also hoped it might save time later by reusing the same codebase on both iOS and Android.

The reality was that though it helped while prototyping, it required workarounds to do anything more complex than the token tabs+list-view/sub-view style app, and we ended up disabling all of jQuery Mobile's transitions and effects in order to get it to be performant (BIG difference there!). In the end, I'd say the costs outweighed the benefits in our case.

Next time, I'll just use one of the more general-purpose JS frameworks and custom style the UI myself.

I've used both on apps that have been released to the various app stores. I've used jQuery for years so logically I thought jQuery Mobile would make the most sense. I used version 1.2 and it was just mediocre. It'll get the job done. There were definitely some hurdles. I liked being able to design my interface in HTML with CSS.

My experience with Sencha was completely different. It was very hard getting started as I had to relearn the Sencha/ExtJS way. I began to like the way each page/panel is "described" as JSON in a JS file. It's a completely different way of skinning a cat. Things like stores/models/views/controllers are baked into the framework. Support was absolutely abysmal. I think there were a couple of guys on their dev forums that actually knew their stuff. Quite a few "it works fine for me" type answers. Things blatantly left out of the docs which may be fine for normal users, but was extremely painful for a newbie.

In the end, I really liked the results from Sencha far more than anything I'd ever done in jQuery Mobile. I will say, my app in Sencha was extremely "templatey" which means it looked like a stock iPhone app... nothing custom at all.

Reply on news.ycombinator.com