A few minutes ago @BradLawryk asked me on Twitter what the difference between jQuery and jQuery Mobile was. Are they the same thing? Do they work together? Etc. I thought it might make sense to quickly explain how jQuery, jQuery UI, and jQuery Mobile relate to each other. This is my opinion of course so please feel free to chime in.
At a basic level, jQuery is a JavaScript library that enables you to quickly perform common tasks. I like to describe jQuery as a way to find stuff on a page, load stuff via Ajax, and then work with that stuff. That's a gross simplification, but to me, that's what jQuery provides for me. You can find out more at jquery.com.
jQuery UI is a library that works with jQuery. Any jQuery UI page is going to load jQuery first. jQuery UI provides support for widgets and user interaction (think drag and drop for example). You do not have to use jQuery UI to do widgets. In fact, there are about 5 billion jQuery plugins for various widgets. (Give or take a few billion.) Personally I always go to jQuery UI first just because it's easiest and I like the way it does things. You can find out more at jqueryui.com.
jQuery Mobile is a library that works with jQuery. Any jQuery Mobile site is going to load jQuery first. jQuery Mobiles makes it easy to create a mobile-optimized version of your web site. You can find out more at jquerymobile.com. Like jQuery UI, there are other alternatives to building mobile friendly sites with jQuery. Frankly though I've yet to see anything as friendly as jQuery Mobile. I'd go as far to say you can build something nice in jQuery Mobile even if you've never written a line of jQuery or JavaScript.
That's it. Obviously there's a lot to all of the above, but I just wanted to write something short and sweet that helps clarify the relationship between these 3 tools.
Archived Comments
So would it be safe to say jQuery would be to Javascript what Zend is to PHP?
I don't know Zend, so I can't comment. Obviously you can do JS w/o jQuery, but jQuery's tools make so many common tasks soooo much easier. If you haven't used jQuery at all, consider these sessions on jQuery:
http://www.carehart.org/ugt...
Would it be safe to say that JavaScript is a case-sensitive programming language with mehtods that are a mix of lower and uppercase characters, for example getElementById()?
Um, well, I think JS could be described a bit broader than that. It _is_ case sensitive. It does have methods, variables, etc.
If I were to tell my wife what JS is, I'd say that it is a language that allows for web pages to have dynamic interactions.
Would you tell her that if you wanted to get the value of something, that instead of saying Val(X) like every other programming language you've ever used for the past 30 years, that instead you would have to write
function VAL(str) {
var f = parseFloat(str);
return isNaN(f) ? 0 : f;
}
Heh, no, I wouldn't. Also, I think your comment is misleading. Your code isn't just getting the value - it is getting the numeric value of something that may or may not be numeric. It's not fair to imply that JS is lacking anything here (imho).
Thanks Ray for being so level headed.
I'm just blowing off a little steam and poking fun the way people do when standing around the water cooler.
Heh I've gotten mad at -ever- language I've used - even ColdFusion. Hard not to get into "fights" every now and then with the things you love.
So if you want to have your site available on a computer and on a mobile device, you need your basic logic and then the presentation pages specific to the type of device, right? Your "browser" pages would be written using jQuery and anybody coming from a mobile device would get pages written in jQuery Mobile.
Seems like a lot of extra work, but I can see designing the base functionality so that just the presentation-specific items are built using the appropriate toolset.
Do you have experience/recommendations on how you have handled the dual-coding issue?
@paulCarney - keep in mind that jQM 'sites' are going to address at best 30% of the mobile market in the US. And even that 30% starts to break when BlackBerry 5 - which yes, some consider as a smartphone, enters into the equation. So it's no longer a question of 'dual coding' if you need to address the entire mobile market - you're now into XHTML-MP to build at least a minimal experience for fliphones.
If you're trying to hit Android, Win7, iOS and new BlackBerry - jQM is a great choice and you'll have something prototyped in a few hours.
@Paul:
If you're using an MVC framework to build your web app, you should only need to create mobile specific views. The controllers and models would be shared between the mobile and non-mobile versions.
Check out the "skinning" example app for FW/1:
https://github.com/seancorf...
That app isn't mobile, but uses the same concepts. You would just need to add some mobile detection code and select the skin based on that, rather than on a url/form variable.
@cfgurney: Are you sure about the 30%? Last time I checked iOS+Android was around 50% by itself - and that's not counting for the % of BB that works well in jQM. Also keep in mind that jQM breaks 'very' well (in terms of people still able to read/use your site).
@Paul: I think Mike does a good job answering your question. A properly MVCed site will NOT be a complete rewrite for mobile. I think there is some room for debate on if you should have 2 sites or 1. Personally I think 2 sites because I believe that you can offer a streamlined experience on mobile. What I mean is - I think what you want to offer up to your users may change if they are mobile.
Keep in mind - I've been a "mobile developer" for 2 seconds. I'm still working to figure out what's best. I think we _all_ are. There's going to be a lot if experimentation and a lot of mistakes...which I think will be fun. :)
My 2 cents: surely Mike is right, a site can be displayed differently from the same model, but i think that some functionalities does not make sense on mobile: imho a complex multitab form to compile a complex order or invoice surely will never be properly rendered on a smartphone; on the other hand a snapshot info, i.e. how many products i have in order, can be usefull along the way.
what i'm try to say is that imho mobile and desktop are not two different way to see the same things, but are additional.
Thanks, @Mike - that helps understand some of it, but at @Salvatore points out, the ideas I struggle with are that the presentation and subsequent processing (what fields may be available, etc.) go beyond he presentation layer and affect the processing layer. I still think that desktop and mobile are different enough that I am having difficulty figuring out how to reconcile it.
Paul, imho the way to reconcile desktop and mobile is to evaluate what do you need from a desktop session, may be all features, and a mobile one, may be a limited and simplyfied set.
I don't think it's an issue of "mobile" as much as "touch friendly". jQuery Mobile is a "touch-optimized" Web Framework for Smartphones & Tablets (according to their front page.) I'm creating admin tools for a client's Windows 7 tablets using jQuery Mobile & Chrome because it provides a clean, consistent UI that is extremely touch friendly.
Windows 7 tablets? Did you mean Windows 8?
Nope. I meant Windows 7 tablet, the Acer Iconia Tab W500. (We'll be testing Windows 8 Developer Preview soon.)