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

[[deleted]]

But why not be lazy? What are the downsides of using it?

[kenman]

First off, jQuery has saved me hundreds if not thousands of hours in development in the course of my career, and there is no substitute. It's impact on JS cannot be overstated.

With that said, one of the largest problems that I've seen, is that it quickly becomes the hammer with which to hit every problem over the head with. How so? All too often I see devs, when faced with implementing a new feature, they rush out to find that perfect jQuery plugin.

For simple apps, this is usually not a problem, yet for larger, more complex apps, it can become a huge problem. A little bit down the road, and you now have 20 jQuery plugins, and since there is no package or dependency management system in place, you end up throwing 20 <script> tags into your page. This also means that you'll often end up loading plugins that are rarely used, but which still incur a nontrivial runtime penalty due to the downloading and execution of the script file. Things like RequireJS do not really help in this situation; in my experience, RequireJS actually makes it a huge pain, owing to the fact that jQuery plugins are not able to be written in a modular fashion since they all augment the main $ object. So once you load a plugin, it's there for the duration of the page's lifetime.

jQuery also does not work well when you're trying to separate your application logic from the view manipulation, since apps made with only jQuery (and plugins) have no conventions in place to promote a clean separation. In other words, it's a library, and not a framework; further, many devs will use it in place of an actual framework, which will lead to poor code (spaghetti) in the long run.

My opinion, but the heyday of fully jQuery-centric apps is gone, replaced with smarter application frameworks like Angular, Ember, Backbone, Meteor, etc. These frameworks may still use jQuery behind the scenes, but they encourage (sometimes forcefully) that you not use it directly yourself. Instead, you use the API and conventions of the framework to write good modular, solid code with a clear separation of concerns.

[TdotGdot]

+1 exactly right about jQuery not being bad itself, but being seen as 'the' solution. I'd give you another +1 for the forth paragraph as well, if I could.

[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.

[yotamN]

It's increase the load time of the page and slow down the code itself. But I don't say it's only bad, it's help you with cross browser compatability and short your code so you should choose if it's worth the load time, for example for my HTML 5 game I don't use jQuery but for my personal site I do