In a WordCamp I heard a developer say something along these lines:
“I include my own jQuery because it’s easier and I can control things.”
The moment he said this, I clamped my mouth shut and bit my tongue. It was not the subject of this presentation, and multiple other people in the room had already pointed out that WordPress has it’s own version. Afterwards, someone remarked she saw steam coming out my ears. All I said in the room was “We reject themes and plugins from the .org repositories for including their own copies of jQuery.” and then shut up. After all, I was in the room because I wanted to learn about something I didn’t know, and that wasn’t jQuery.
It’s sad that my major takeaway from that talk is too many people sacrifice sustainability for ‘ease’ and ‘control.’
You may think that if you force install your own jQuery, you can be sure a random upgrade of WordPress won’t break your theme. You have full control over the theme, after all. And you may think that you can make your theme or plugin faster if you compress all the JS together yourself, rather than having WordPress load a dozen separate files. Those thoughts are both true, but you’re wrong. You’re never ‘master of everything’ unless you only use WordPress core and the themes and plugins that you built. And even then, you’re still not.
While it’s perceived as easier and faster to write code if you assume you know the truths of your website and will always be it’s master, the fact is the assumption is plain ignorant. These days, it’s rare you’re ever the sole developer of a site. You may be hired to make a theme, I’m hired to make a plugin, and someone else is titularly in charge of both of us, but probably doesn’t know a lick of code while still being the driving force behind the website. Not to mention we’re not the webmasters of the site. That may be some intern nephew of the boss, who will take over once we’re done.
And that is exactly where using our own versions of scripts will get us into trouble.
You’re master of your plugin, or your theme, but you’re not master of the rest of the world. Even if you’re making it on spec for someone for a specific purpose to be used on a specific site, there’s no guarantee that it’s the only time and place your code will ever be used. There’s no assurance that then 10 other plugins you tested with today will never upgrade, or that they won’t add more. If you get hit by a bus tomorrow, there’s no promise your code will remain untouched. Basically we’re running on pure arrogance that not only are we crystal clear about the present, but we’re totally perfect about knowing the future. And that just ain’t possible.
So. How do I explain why including your own jQuery in a theme or plugin, instead of enqueuing the one with WP, is bad?
“Picture this. Your theme has jQuery 2.0. So it de-enqueues WPs and re-enqueues yours. My plugin is using version 1.7. I do the same thing. Bob’s plugin uses 1.11, HE does the same thing. Joanne over there properly uses WP’s. Which one of our jQuery files wins?”
The problem is that you’re emphasizing short term gains (speed of development, speed of site) over long term sustainability (regression conflicts, duplicate files). You’re making your life a little easier, and actually harming the website you’re trying to make because tomorrow, you will be gone and they’ll be trying to figure out why the site is so slow. Or why it’s breaking when they upgrade Jetpack. After all, you tested with Jetpack, right? You were selfish, short sighted, and just … wrong.
But it’s okay. You can learn to do things better. You can do it right with your code and fix those mistakes. You can let the wookie win, and let WP control what it’s supposed to control, while only augmenting what you must control. And you can do it all in a friendly, sustainable, updatable, extendable way. Which is how WP wants it.
Oh and how to I handle minification? I have a proxy service do it for me. In my case, Google’s mod_Pagespeed compresses and combines all my JS and CSS to make it one file that loads faster.