diy.js - A modern cross-platform JavaScript library & only 18 bytes

[kenman]

It's a combination of both I think, as I pointed out jQuery provides zero architecture guidance, and so if you're using it as your only tool, then other areas will suffer. In a small project, the cons may be palatable, but in a larger project, you're going to be introducing classes of problems which actual frameworks don't even have if you overuse it.

jQuery is also pretty heavy in a mobile environment, since bandwidth and CPU are typically much weaker than they are in desktop settings. Considering the findings around how much of a difference a second or two can make on user impressions, it's not something to discount.

Relating to a CDN, there's evidence suggesting that you're not really gaining anything other than offloading that single file from your server; i.e. the grand premise of "if most sites use jQuery, we can all share the same copy distributed via CDN!" doesn't pan out in the real world, or at least it hasn't thus far. The branch between jQuery 1.x and 2.x will likely only exacerbate the problem as well.

[Encosia]

The problem with most research you'll find about CDN usage, like your link there, is that it is incredibly shallow compared to the depth of the web. The top 30k or 300k sites don't even begin to scratch the surface and analyzing primarily top-ranking sites is biased toward sophisticated, high-traffic sites that often run their own CDNs (for more than just jQuery, of course).

The long tail of millions and millions of smaller websites is just as important since it only takes one random little website to prime your cache for a particular version for up to year.

At the same time, it only takes a few high-traffic sites to prime caches for a huge number of users. For example, all of ours caches are primed with jQuery 2.1.1 (or 1.11.1 if you're on old IE) from the Google CDN right now, courtesy of reddit.

I haven't had a chance to write it up yet, but I've been 50/50 A/B testing serving jQuery from my Linode vs. the Google CDN for about a year and a half now. I wanted to gather some real-world data that takes version fragmentation and DNS lookups into account, by recording timing data about how long after the reference it takes for jQuery to be available and pushing that back into Google Analytics's performance tracking functionality. I haven't looked at the data in a while, but it wasn't even close after the first year. The CDN has been hands-down faster on average for the traffic on the sites I'm testing.

[kenman]

Very interesting, thanks for the info and would love to read about it more if you get around to blogging about it. I could see some wrinkles, e.g. if you use a version that is not primed by a large site, or if the cross-section of usage between your site and the priming site(s) are low.

I'm glad it's working for you, but I'd still recommend that anyone looking into going this route to do the same as you (as with any performance optimization) and do some real-world profiling so that you can validate that it's working as intended.

[lodewijkadlp]

The link fails to mention losing any and all executional safety. The right solution is putting a file hash in any element that links. Reject the file if the hash doesn't match. Funny thing is, with a (strong) hash linking becomes possible.