> jQuery as a library has now become huge

  > So if you can cut down your cold cache loading times by not
  > including the full jQuery library, that's probably a win

jQuery 1.11.3 is 38.4 KB when minified and gzipped.

jQuery 2.1.4 is 34.1 KB when minified and gzipped.

I'm all for eliminating unnecessary bloat, but it's not as if a jQuery download is a huge amount of data to fetch. While jQuery is not a framework, most front-end JS frameworks are the same size or bigger and don't receive as much attention for being bloated.

If you can get by without jQuery, or if you have a very large number of mobile users and first-load performance is mission-critical for your application, or if you have a large percentage of users from countries with slow or intermittent internet connections, then sure, avoiding jQuery makes sense as a priority. But for most applications, jQuery is a smaller download than a single medium-resolution highly optimized image, and it can be cached forever.

Loading over 30 Kb of minified/gzipped Javascript over a 3G connection on a mobile phone is very problematic, as the bandwidth is poor, the CPU capacity for decompressing and parsing is poorer than on the desktop, so the latency can many times be measured in seconds, therefore loading over 30 Kb of stuff that you don't need gets to be a tough pill to swallow. Also the argument of caching is often brought up, but in my tests this can be very non-deterministic, as mobile phones are pretty aggressive in their used storage. JQuery is supposed to be cached, yet in our A/B testing the load times and consequently the conversion rates improved greatly after we dropped JQuery.

Your comparison with "a single medium-resolution highly optimized image" doesn't hold for mobile phones. On mobile phones users expect latency when loading images, but not when loading the UI. Another problem is that JQuery is not the only commonly used library. You add Underscore, you add Angular, or whatever libraries du-jour we have and pretty soon we are talking about 100 Kb of stuff or even more that is rarely used as a whole.

Of course, my use-case is about having really simple interfaces augmented by Javascript and meant for mobile phones. Well, for complex interfaces I think bringing in JQuery as a dependency may be worth it, but then again, I then start thinking that JQuery is not enough. It's because I want more, I want a virtual DOM that's saner by design, I want to work with immutability, I want much better performance without unpredictable behavior (like what you get with Angular) and I want to only pay for the features I use. JQuery is incompatible with React and is incompatible with Google Closure in advanced mode.

While I tend to agree in some respects, mainly in application memory inside the browser in mobile (RAM is still relatively small 2-4GB on many phones), the actual compute power is pretty capable on even modest smart phones for the past year+ (given a roughly 2 year turnover on phones for most), it's less an issue.

I also agree that jQuery isn't the end of what gets added... once you add a few additional libraries it gets very big, very quickly... I'm working on a project now that is loading about 19 jQuery plugins in addition to jQuery, as well as a handful of both bootstrap and jQuery-UI extensions, and the payload of a relatively simple page is coming in over 2MB (even if most of that caches, it's really big for a first hit).

People tend to start with a kitchen sink, then add not only the rest of the kitchen, but the barn as well without a thought or consideration to the final result, and the payload that goes with it.

It sounds like you've done the work to validate the fact that 30Kb is too much for your use case.

However, let's be clear here: most people who complain about the size of jQuery are doing so without any basis whatsoever. And even if people are measuring, they may not be measuring the right things. If not using jQuery causes you to reduce your Ajax usage, and reload entire pages as a result instead of only reloading the content, the end result is a slower site.

I totally agree and I exposed my use-case - really simple interfaces augmented by Javascript and served to mobile phones, so JQuery was basically unneeded, taking it out improved latency and thus it improved conversions. But of course, most people don't measure and most people need the features in JQuery to work reliably and to behave well cross-browser, in which case 30 Kb cached by a CDN is a steal.

> I'm all for eliminating unnecessary bloat, but it's not as if a jQuery download is a huge amount of data to fetch. While jQuery is not a framework, most front-end JS frameworks are the same size or bigger and don't receive as much attention for being bloated.

Remember size isn't as much of an issue when it's less than 100kb (though 3G or less networks that will still be painful). The biggest issue is yet another file for the browser to fetch. Synchronously or asynchronously the browser will still open another connection to the server to grab the file which results in further latency before your application really starts up.

I thought the biggest issue is once that file is downloaded it has to be unpacked, parsed, and executed in the browser that at the same time is trying to decode JPEGs and reflow the layout. It's why pages take 20 seconds or more to load.

Less javascript means less cycles burned executing boilerplate framework factories means faster page loading means longer battery life means you can keep that two year old phone that's not quite so fast instead of throwing it in the trash.

jQuery causes global warming. (tongue-in-cheek of course, but not entirely)

> The biggest issue is yet another file for the browser to fetch.

There's no reason you can't concatenate jQuery with the rest of your JS.

> There's no reason you can't concatenate jQuery with the rest of your JS.

True and most applications should really do this. In reality I've seen far too many production system still including sometimes over 50+ files.

For comparison, the site I work on serves up thousands of content images. I just did a quick scan across our media directory with a bash script, and the average image size was 78.0 KB

This explains it pretty well. I always have to argue with other developers to not break IE8. The comeback is always that it represents less than 1% of our sales, I argue that the 1% of sales is still more than their salaries.

As much as I'd love to stop keeping track of IE8 bugs, for a lot of sites this isn't possible. And, IMHO, this cavalier attitude is what causes many websites now to work "best" (read: only) in Chrome. It's true that a lot of sites (I'm thinking Webapps) don't need jQuery at all, and a lot of sites can get away with just using Sizzle, but 28kB is a small price to pay for the utility functions, cleaner AJAX API, event binding registry, etc. If you don't need them, by all means don't use it.

The "back to their roots" thing inspired this useful reference website: http://standardjavascript.info

I would add that a lot of the time, your browser-set is very small. For mobile apps, many of which use web views for at least some functionality, you're writing to one or two versions of WebKit only.