jQuery Forum

It depends on exactly what you are trying to do. Are you trying to make the site cross-platform? Are you targetting specific devices such as iPhones/Android phones? Are you going to deploy this natively with phonegap? All those are questions you should think about.

Thanks for the reply.

By modifications, you mean I have to write some custom code ?

Keep in mind just what jQuery Mobile is and is not.

It is not a complete application framework for webapps, nor can you use it to create  native app. (You need something like PhoneGap for the latter, and you will need to use additional HTML5 technologies to create the former.)

It's purpose is to normalize the UI (CSS and Javascript library) across multiple browsers, whether standalone browser, webapp, or native app that uses a browser control.

For some reason I was under the impression that using JQM's CSS/JS library (ie. applying selectors to elecments) and restructuring HTML code, the sites would automatically resize to a mobile friendly version. 

That's exactly what it does. It works on all platforms. The issue is that it sacrifices performance for being broadly cross-platform. (and in some cases functionality, see slide transition)


-- Kevin

@ppetree,

Well I'm actually looking to make both - mobile sites and apps.

You do not need to go to raw JS/CSS to get good performance out of jQuery Mobile. But you won't get it "out of the box", either.

A good strategy is to consider JQM widgets as prototyping tools. As you develop experience with your app or site, replace the most speed-critical parts with your own custom HTML/CSS. In particular, heavily-used lists, for example.

You also need to deal with flaky transitions and the iOS click delay.

The best transition, really, is no transition. The "none" transition is fast. If you can deliver pages fast enough, then the "none" transition will generally provide a better user experience than any other. In a native app, there usually is no problem delivering pages quickly. I use the Rhodes platform, which is programmed mainly in Ruby - a notoriously slow language - and a sqLite database using a property-bag scheme. None is this presents as big a performance problem as do transitions and listviews. Take out the transitions and listviews, and you can write native-performing apps in Rhodes.

I think that users generally prefer no transition, but if you can't deliver the page quickly enough, they get impatient. A transitions gives them something (generally, useless, though) to look at while they wait. And the thing is, they actually have to wait LONGER. But the transition fools the user into ignoring the delay before the transition starts, as long as it isn't too long. With a "none" transition, it is obvious if you are slow delivering a page.

So, if you are using JQM for a website, you need to work on improving latency - carefully select your server location(s) or use a CDN. Try to minimize round-trips. If you are developing a native app, I think generally it is not a problem, though.

So, what is left to use JQM for?

Forms generally aren't large. Constructing a form generally is not a big performance hit. Content pages generally aren't a big problem. Listviews and transitions are huge bottlenecks.

Part of the listview problem is unreasonable expectations by developers. If you are trying to scroll lists of hundreds of items, you are asking for trouble. It's a bit hard to accept, since iOS (and, presumably Android) has a very efficient native implementation for lists, that can very seamlessly scroll lists of any length, getting data directly from a database. Given the roundabout way that you have to scroll the same list using HTML/CSS/Javascript/JQM, it's amazing it works at all. You have to get it all into the browser or go to extrodinary trouble to manage unseen list items. Contrast this with the elegant native methods that simply make a callback to your code to get the next or previous item.

Keep your lists short.