This is the first post in the series JavaScript in WordPress. Be sure to read the final article, too!

JavaScript in WordPress

One of the challenges of building projects on top of WordPress is that there are well-defined coding standards specifically for PHP-based components. There are even some guidelines for HTML, and the CSS guide is under construction, but there appears to be very little in way of coding standards for JavaScript in WordPress.

I’m certainly not going to be defining those standards here – that belongs in the Core Contributor Handbook, right? – but I am doing to be sharing my thoughts on JavaScript in WordPress and some of the things that I do in order to make sure that my projects and that my team’s projects are maintainable over time.

Wait, Why Coding Standards?

There are several reasons that developers should be using coding standards many of which boil down to the following:

  • It defines an expectation of how the code should look for any developer that touches the code
  • It maintains its readability overtime
  • It provides guardrails for new and experienced developers for knowing the proper way to format their code when introducing (or maintaining) existing features
  • It ultimately looks like the same developer wrote all of the code

Overall, it eases the maintainability of a project over time. At least, that’s what it’s supposed to do. Speaking from experience, this is absolutely possible when you adhere to it.

That’s half the challenge.

JavaScript in WordPress

So what’s up with JavaScript in WordPress? Prior to getting involved with WordPress and the WordPress community, I was doing a lot of work with vanilla JavaScript, Prototype, and eventually jQuery.

Generally speaking, I’m a big fan of the language and do my best to continue to keep up with everything that’s going on with the latest updates to it, and with the changes coming down the pipeline for JavaScript and jQuery especially since it’s part of WordPress.

Anyway, at the point that I came on board with working with WordPress, the Coding Standards had been officially defined, but – like so many developers – immediately began to notice a problem: That is, theme and plugin developers are abusing JavaScript in WordPress.

  • They deregister the version of jQuery that ships with WordPress
  • They call noConflict on jQuery
  • They don’t properly import their scripts
  • They write their scripts out inline rather than external files
  • …and on.

Now, I say this to be constructively critical – not to put anyone down – but it’s a well-known, often discussed problem and it’s not going away any time soon.

What’s The Biggest Problem?

Aside from the points mentioned above, I think that a lot of developers who jump into WordPress wouldn’t consider themselves to be well-versed in JavaScript.

Instead, they’re comfortable including code, modifying things here and there, and mostly comfortable copying and pasting. This, of course, breeds more of the same problem.

Ultimately, I believe that it boils down to this?

JavaScript isn’t seen as a first-class citizen to WordPress developers and it should be. It’s just as important to behavior as CSS is to presentation.

One of the beautiful things about open-source software is that everyone’s invited. The problem is that there’s no one check your skills at the door.

So Can We Do Better?

In short, I think so. Though I do believe there’s a bit of a WordPress Gold Rush going on right now, but there are also people who genuinely care about becoming better WordPress Developers.

And sure, we can document coding standards, do peer reviews, and criticize people on Twitter all day long, but until we actually help people understand what they are doing wrong and why it’s a bad practice, then they’ve little incentive to change simply because they don’t know any better.

But as I said in the beginning, I’m not here to define the coding standards for JavaScript in WordPress – just simply offer what I’ve found to be useful.

So in the second post in this series, I’ll do exactly that.