Except that jQuery Core is a completely different thing. You know if you're using jQuery UI Menu but not jQuery UI Dialog so you can decide to include them or not with a custom web-based builder just by clicking boxes.
The jQuery Core features used by all the plugins you collected to build your site are not immediately obvious. Did they use .replaceWith() for example, is it safe to leave that out? What about .load(), did they use that API? Oh, wait, there are two different things that .load() does, one is AJAX-y and one is event-y, if they did use it which one did they mean?
By having the full library there you don't need to spend lots of time tracing down these dependencies. And in JavaScript these are all dynamic, you can never really be sure you got the dependencies right until you find out you didn't.
That's why I strongly advocate that the average programmer should just use the whole standard jQuery core library unless you are in some spot where saving 10-20KB gzipped is so important that you're willing to chase down those dependencies yourself.
Frankly with the amount of plugins I usually use (0-2) this isn't really problem...
The point is, there are some great features and fixes tucked away in there and sometimes I only want say <5-10% of the library, I could write it myself but then I loose all the collective knowledge embroiled throughout.
For that reason I and a friend started a project called Rye[1] that is a light wrapper around the DOM and other browser APIs; it's made of small modules that you can pick as needed. Despite being < 6kb, it also favours readability over code size, so it's easy to spy under the hood.
Ender[2], a hybrid library/package manager, has a similar philosophy.
[1] http://ryejs.com
https://github.com/jquery/jquery#modules-new-in-18
As far as I know the core team is planning to continue the trend along with a builder at some point. For my part I've proposed a separation of the dom manipulation from the collection and argument handling:
Despite this, every time I start a new project that requires some DOM manipulation etc I lament at having to include the entire library just to harness a tiny aspect of it's power.
A delightful solution to this would be a similar degree of modularity as there is in, for example, jQueyr UI. I know there is a degree of modularity (https://github.com/jquery/jquery#modules-new-in-18) but this is reasonably high level and at this level the argument of using google's CDN and so encouraging a cache hit is still very strong. If you could strip both jQuery core and shizzle (I rarely/never use attribute selectors for example) right down to a hundred lines of so of what you really needed, this would be very very compelling.
I had a relatively brief investigation into the codebase a while ago with a view to how hard this would be to implement but didn't really have the time to follow it through. My conclusion was that it wouldn't be easy, anyone have any ideas/thoughts on this?