While it may be tempting to think that jQuery is just always on the page, that you don't have to think about it, that's not quite the case. The main reason that you see it on the page is that the Enable Skin Widgets option is checked in the Site Settings. If you turn that off jQuery will only be loaded when something requests it. If you're logged in, you may think that it's still there, but that's because the (older) IconBar control panel requests it. Once you logout, jQuery is only on the page if a module on the page requests it. To do that, call DotNetNuke.Framework.jQuery.RequestRegistration() from your module, skin, skin object, etc.
In the host settings, there are a few options in terms of how jQuery gets included on the page. You can reference the Debug version, if you're a developer (though, in general, I don't think that'll get you much benefit). You can also use a hosted version of jQuery. The two big options for that are the Google CDN and Microsoft's CDN. The benefit of using a CDN is that most people will already have a cached version of the file when they get to your site, so they won't need to have to latency induced by that initial download. For this reason, I recommend the Google CDN, since the Microsoft CDN isn't nearly as widely used. Google also allows you to specify a partial version of the script (meaning, you reference version 1.4 to get the latest version of the 1.4 script). However, because this could serve up different scripts, Google does not instruct the browser to cache the script for a long time using this method. Thus, the main benefit of the CDN is lost if you don't reference a specific version of jQuery, It also hosts some other interesting scripts, though that shouldn't strongly affect your decision to use it or not.
In DNN 5.0, the DotNetNuke.Framework.jQuery class was introduced to handle requesting jQuery on the page. In DNN 5.2.3, DNN started switching the protocol of a hosted jQuery script from http to https if it was used on a secure page. This works for the Google CDN, but not necessarily for CDNs. In DNN 5.4.2, the reference to jQuery was moved higher in the page, to cause less conflict with scripts that depend on it.
The biggest way that you can avoid inconsistencies in your scripts is to always use jQuery when dealing with the DOM. Even when you think something is simple, it's probably not quite as simple are you expect it to be (at least in IE 6, or some other, obscure browser). Jquery's purpose is to handle those inconsistencies, so let it.
If you're interested in an excellent platform for DNN Q&A, consider committing to being a part of the DotNetNuke Stack Exchange proposal. I honestly believe it will revolutionize how we help each other and get helped when developing, integrating, and maintaining DNN sites.
<ul>Brian Dukes </ul><ul>Engage Software since 2006 Chief Software Architect in charge of Module Development Microsoft Certified Professional Developer </ul>
<ul>jQuery - included? </ul><ul>Core - IconBar - Skin Widgets - Telerik ( Telerik.Web.CommonScripts.$ ) Modules - Console - Dashboard - Sitemap settings - Blog includes its own version - 3rd Party </ul>
<ul>jQuery - options </ul><ul>Debug Hosted - Google CDN - jQuery UI - SWFObject - WebFont Loader - Use a specific version - Microsoft CDN - jQuery Validation </ul>
<ul>ASP.NET AJAX </ul><ul>Guaranteed on the page starting in DNN 5.0 Use $find to interact with Telerik controls </ul>
<ul>Avoid Inconsistencies and Frustration </ul><ul>jQuery </ul>
<ul>Questions? </ul><ul>Commit to DotNetNuke's Stack Exchange: http://bit.ly/dnn-se </ul>