We are debating between two approaches to displaying device contacts on a mobile app powered by jQuery Mobile.
We’re building for the iPhone.
1) On each keystroke, filter the contacts in native code (via PhoneGap) and pass only the matching contacts to the UIWebView.
2) On load, pass all contacts to the UIWebView and perform keystroke filtering within the web app using jQuery.
The advantage to #2 is after an initial delay, each search for contacts is more responsive. The downside is loading all the contacts, which seems wasteful.
The broader question is: at what DOM size will jQuery Mobile start to slow down? For instance, would creating 2000 LI elements (with strings about 20 chars long) impair performance noticeably?
Ultimately, I think you’ll find that doing the filtering in native code (option 2) is going to be much faster than even the Nitro engine in iOS can provide. jQuery Mobile has been using 400 list items as their test bed. Release Candidate 3 has taken massive steps to improve the performance of listitems. iOS and Android will both render a list of 400 in about 1.5 seconds. You can see the relative stats and breakdowns on JQMs blog entry about RC3
Let me throw out another suggestion. Call it, option 3. Do all filtering in native code where it is likely to geometrically faster. Then, as you are rendering out the listview, render it out as a prerendered listview. Take advantage of the jquery mobile CSS but don’t render the list using the javascript library. Just pre-render the content so you don’t have worry about massive amounts of DOM manipulations.
So, instead of rendering out…
Try rendering it out directly…