JavaScript library jQuery may have indirectly generated the single biggest wave of pollution the internet has ever known. In comparison, CSS hacks and vendor prefixes may be as harmful for the web platform as an organic banana skin left at the foot of a tree in some remote forest.
I'm about to go after pieces of code that needlessly extend jQuery.
Let's make friends.
On loosely tied public API
Here's a line of code that is, in about 90 per cent of the jQuery plug-ins whose source I've read, absolutely useless:
$.fn.myjQueryPlugin = ...
What most jQuery plug-ins do is just use jQuery to do whatever they have to do, and for those plug-ins, extending jQuery is neither useful nor necessary, especially since many of them do not even encourage, or even allow, chainability (which is one of the good things about jQuery, after all).
Unless you specifically need to inject your plug-in's methods into jQuery, why should you tie your public API so tightly to the almighty dollar? Consider the following ways to fire any hypothetical ohSoAwesome.js plug-in:
// 1: the jQuery plugin way$("#some-div").ohSoAwesome();// 2: the "vanilla JS" wayohSoAwesome.init( "#some-div" );
In terms of public API, the first line ties the ohSoAwesome plug-in very tightly to jQuery, while the second line is 'library-agnostic'; it uses jQuery, but it doesn't show. Here is the basic structure of that second plug-in:
!function ($) { var self = ohSoAwesome = { // Do whatever you want in here // including using jQuery } window.ohSoAwesome = ohSoAwesome;}(window.jQuery);
Using a library-agnostic API doesn't make it any harder for people to use your code, and it's no harder for you to market your plug-in either.
You know, that 'boom' we all love to flash somewhere in our documentation to make sure people understand how painfully easy it is to make our code work. Until now, we've always seen this kind of teaser:
Include ohSoAwesome.js. Fire it. Boom.
I know what you're thinking, dear jQuery plug-ins user: "Yeah, awesome, I want to use it. Boom." But, come on, wouldn't the following teaser be equally efficient?
Make sure jQuery is included. Include ohSoAwesome.js. Fire it. Boom.
"Totally."
I know. Painfully easy.
Be future-friendly; leave all doors open
When a plug-in is released, it's impossible to say what its lifespan is going to be, how successful it's going to be, and how widely it's going to spread across the internet. Imagine you're the owner of an incredibly successful piece of code. The way you coded your plug-in and its public API (or, to put it more simply, the lines of code that people type to use your plug-in) is filtered through the prism of jQuery. And one day you want, for whatever reason, to untie yourself from any dependencies.
Well, you're going to have a hard time selling that idea to your many users. Imagine telling them they now have to go through all the pieces of their own code to make it comply with your plug-in's new 'unleashed' API. The odds are that your fan base is quite literally going to melt down.
"It's scandalous." I know, dear user. I know.
Whenever possible, it's better to think in terms of composition and agreggation rather than extension. The looser the ties between pieces of software, the greater the flexibility and the freedom of movement for the developers.
And, obviously, the greater the success of your plug-in, and the greater the efficiency of your code in the long run. Oh, and the happier the user.
"That's important, man! I mean, it's an ecosystem we're developing in." Yes, you're completely right.
jQuery is a godsend, but comes at a price
jQuery is an incredible tool for kickstarting applications. It helps you achieve awesome stuff within minutes, and it's driven by a very dynamic and responsive community. It also takes care of dealing with differences between browsers for you, which is a relief in what are probably countless situations.
But ...
It has been proven that jQuery contains a lot of saturated fats that increase application loading times.
Browsers are evolving incredibly rapidly and, while it's still a bit too early to ditch support for older browsers that are responsible for a decent portion of jQuery's weight, there will come a time when querySelector will replace Sizzle, and CSS will be used in place of animation methods.
When that day comes, many of your jQuery plug-in's features may very simply be achieved without the help of a 'fat' library. When that day comes, Vanilla JS will be powerful enough to replace jQuery.
What will you do then? What if, in time, you refactor your plug-in until it doesn't rely on jQuery at all anymore? Because, I mean, we're dealing with a technology that's moving at the speed of light, here. And we are all very well aware that nothing lasts forever in that context. Including the awesome, almighty jQuery.
"There could be a web without jQuery?" Yes, dear user. As frightening as it may seem right now, that time will inevitably come. The only question is when.
Be future-proof: write plug-ins that use jQuery instead of writing plug-ins that extend jQuery (unless, of course, extension is absolutely necessary and meaningful). This will ensure that if jQuery ever becomes obsolete, the web won't have to keep on loading it again, and again, and again.
And again.
All that just because websites use pieces of code which have needlessly extended jQuery.
"Man, websites would totally load faster on smaller devices if that ever happened, or, I mean, on whatever device people are using in the future."
Yes. You got that right. And the beautiful thing is, we (the folks who write plug-ins) would just stop using jQuery. And that's all. No hassle for you, dear user.
"Yeah, 'cause that stuff exists thanks to people like me. You gotta think about us first." We do. Believe me, we do.
What to do, then?
If I convinced you that writing jQuery plug-ins is in fact an extremely evil practice, don't burn your work at the altar of library-agnosticism yet. Your jQuery plug-in is certainly awesome! And I mean it, as I myself am a happy user of many jQuery plug-ins. But it's time to stop spreading the dollar API all around all the time for whatever simple task our code is doing, as that will certainly be very counter-productive in our efforts to make the web move forward in the not-so-distant future.
Stop hurting that beautiful, ingenuous, innocent creature that the web platform is.
Unless you like to see unicorns suffer.
Yes, the moment has come to ready ourselves to cure our addictions to fat libraries, and to find ways to keep on using our existing jQuery plug-ins' APIs without any need to actually use jQuery.
"Dude, like coming up with a smart idea that makes people tweet about you all the time?" I guess so. I guess so.
