Blog
Oct 27

Do You Really Need jQuery & Friends?

jQuery. Say that one “word” and any developer worth their salt will have an opinion on it. If you don’t know what jQuery is, then this article ain’t for you bro (“bro” is unisex by the way). If you’ve been stranded on a desert island and need your memory refreshed, jQuery is the most popular DOM manipulation JavaScript framework on the Internet.

Sorry to disappoint the haters but this post won’t be firing any shots at John Resig and co. because I love jQuery! With all the cross-browser “look at me” brawls that are still going on today, it cuts through all the good, bad, and ugly implementations with a heavenly API #JustSaying.

If you’re not a developer and have read this far, help us devs out by upgrading your web browser to it’s latest, greatest version. Serve yourself by getting a generally faster and much more secure Internet experience. Down with IE8. I thank you.

As I proceed to give you what you need, here are a few things to keep in mind when starting or continuing a new or legacy project that “might need” jQuery:

  1. I believe in site performance and using only what you need. If you don’t need it, scrap it. If you’re listing The Big J as one of your scripts and only use one or two functions, then there’s probably a better way to do it with plain old JS. Most would agree that jQuery is not supposed to be the Alpha and Omega of libraries. As a beginner I took it up to get accustomed to the API. As with all things programming, you should have a thirst to learn more and delve into the source code to find out how something is actually done.
  2. Abstracting code away from base languages (high-level languages (HLLs) lessens the burden on our already saturated brains, but it may hurt performance. You need to weigh up the cost to benefit ratio of having a marvelous API vs a high performance application. The more functions, objects, and “classes” that you have, the greater the overhead. Simple proportionality really. As you can gather, overhead is bad… in most cases.
  3. Holler at YouMightNotNeedjQuery. The end.

Just to prove that I really am a dev, I’ll include some code snippets. I haven’t included a lot of code examples thus far compared to my last post, so it’s about time that we head to that happy place:

$( document ).ready(function () {
	// AWESOMENESS
});

Now you might ask “what’s wrong with the example above?”. Nothing… if you’re using one version of jQuery and only jQuery. As soon as that condition becomes false, problems may arise.

Conflicts, Conflicts, Conflicts. That’s why so many modern frameworks that export to $ have some sort of noConflict method as defined below:

// Define export jQuery no-conflict method to $j
var $j = jQuery.noConflict();

$j( document ).ready(function () {
	// AWESOMENESS
});

Instead of using the noConflict method as per the example above, you can do this in jQuery:

jQuery( document ).ready(function () {
	// AWESOMENESS
});

Make sure that you use jQuery throughout the // AWESOMENESS! or stick to DRY principles:

jQuery( document ).ready(function ($) {
	// AWESOMENESS
});

This allows you to use the normal $ sign within the // AWESOMENESS. That’s how the Grown Up kids do it.

To all the “friends” that I failed to mention (Dojo, Prototype, et al.), you can do better. Bye for now.