jQuery Goes Mobile

Share this article

An early alpha of the jQuery Mobile library was released a little over a week ago. Given the popularity of the jQuery library for traditional desktop web development, I expect most web developers will be very excited about this release. But what exactly is jQuery Mobile, and what are the cases in which you’d consider using it?

What’s in a name?

Firstly, the name jQuery Mobile is a bit misleading: rather than being a mobile version of the core jQuery library, it’s a set of interface components that you can easily plug into your pages. It sits on top of the same jQuery library you’d be using in your regular pages. In effect, it’s more of a mobile version of the jQuery UI library.

Okay, so what’s in there?

jQuery Mobile is essentially a framework for handling pages. These “pages” may be whole HTML files, external pages, or even sections within a single HTML file. The library then takes care of linking them up via Ajax using some funky transition effects. Within pages, jQuery Mobile provides you with an array of consistently styled interface components: toolbars, buttons, every imaginable kind of list, and form controls. Check out the Docs and Demos page for a complete breakdown of everything that’s included.

Progressive Enhancement All the Way, Baby

jQuery Mobile has taken an interesting and novel approach to the framework: all the work you need to do to use it will take place in your markup. Most interface components can be activated and made live without writing a single line of JavaScript. This is made possible by HTML5 data attributes. So, for example, to make use of the slider component, all you need to do is put the following in your markup:

<div data-role="fieldcontain">  <label for="slider">Input slider:</label>  <input type="range" name="slider" id="slider" value="0" min="0" max="100"  /></div>

Those data- attributes give jQuery Mobile the cues it needs to create a slider that looks like this:

jQuery Mobile’s slider control

jQuery Mobile takes a similar progressive enhancement approach to everything it does. The idea is that browsers that don’t recognize the HTML5 doctype or the data- attributes will just receive a plain vanilla web page, which is an acceptable experience for those users. That’s the theory, anyway.

We did tell you it was an alpha release, right?

Right now the framework is still very buggy. I was unable to make a simple external link work on my desktop browser (Firefox 4), and none of the links worked at all on my Android 2.1 device if I’d scrolled the page before tapping them. Given that one of the library’s key missions is to provide an acceptable but degraded experience on any platform it doesn’t fully support, these kind of breakages on supposedly A-grade browsers are a little worrisome. Moreover, I ran some tests on a colleague’s iPhone, and the performance was a long way from ideal: scrolling was much rougher than on a regular web page, transitions and animations were a little choppy, and some links failed to work reliably.

Going native?

While jQuery Mobile is certainly an impressive effort, I can’t help but feel that its applicability will be fairly narrow. Most mobile web apps will perform better without it by relying on the browser for much of their functionality, and apps on iOS will both perform better and look more native if they actually are native. Based on design decisions like the default inclusion of a back button at the top of every page, I’m guessing that the primary intent behind the project is to develop apps for eventual native deployment. If it was intended for web apps, surely it would be better to rely on the browser’s (or the device’s) back button, right?If you want to develop native-feeling apps for iOS that are also portable to other platforms using a framework like PhoneGap, then jQuery Mobile could be an interesting solution once the kinks are ironed out. That’s if you’re okay with your non-iOS users being served an interface that’s essentially built to mimic the default iOS behavior.However, if you intend for your app to run in the browser, it feels to me like jQuery Mobile gives you a lot of unnecessary whiz-bang effects, and might have an adverse effect on some of your users’ experience. There’s nothing wrong with a link that opens a new page when clicked; that’s what your users have come to expect. Adding in a sliding (or popping, or fading) Ajax load—just for the sake of “feeling native”—seems a little wrong. The same goes for replacing native browser form controls with JavaScripted custom versions; most users will be more comfortable with the form controls provided by their OS or browser. Why does your web app need an iOS-style on-off toggle, when you could just use a checkbox and save the cost of downloading all that JavaScript? (Of course, I do believe there’s a use for custom form controls not implemented in the current versions of most web browsers, like the slider above.)But maybe that’s just me. If you’ve already had a play with jQuery Mobile, what are your thoughts?

note:Want more?

If you want to read more from Louis, subscribe to our weekly tech geek newsletter, Tech Times.

Louis SimoneauLouis Simoneau
View Author

Louis joined SitePoint in 2009 as a technical editor, and has since moved over into a web developer role at Flippa. He enjoys hip-hop, spicy food, and all things geeky.

androidiphonejQuerymobile web
Share this article
Read Next
Get the freshest news and resources for developers, designers and digital creators in your inbox each week
Loading form