Software, Development, and WordPress

The Best of Times and Worst of Times of WordPress Development

One of the greatest strengths that’s offered to designers and developers who work with WordPress is the ability to use just about any client-side technology that we’d like. That is to say that for anyone who is working on building themes has the ability to chose from a seemingly endless number of frameworks, libraries, tools, and so on.

Off the cuff and in no certain order, we have technologies like:

The Best of Times and Worst of Times

When it comes to this kind of stuff, I can’t help but feel as if, as far as web developers are concerned, it is both the best of times and it is the worst of times (and Charles Dickens would be proud, right?).

The Best of Times, The Worst of Times

If you’re a web developer, this is you right now.

We have the ability to choose any set of technologies that we’d like to help us build out our templates and our front-end work and any number of preprocessors and dependency managers to help us organize our work in addition to keeping it all visible and freely available via sites such as GitHub.

Clearly, it’s the best of times.

But wait.

How do we know which set of technologies to use? Why is one responsive grid system better than an alternative grid system? And I know that WordPress developers have adopted Sass, but what if I like LESS? And I know WordPress uses Backbone.js, but do I have to incorporate it into my project? What about Bower or Composer? Why not use CodeKit to help wrap everything into a single package?


Then again, maybe it’s the most paralyzing, worst of times to be a developer.

The Worst of Times

When it’s the worst of times, it’s the worst of times.

How do we know what decisions we should be making in order to make sure that we’re making the best decisions for our projects?

Our Decisions and Debates Delay Us

For what it’s worth, I definitely think it’s worth trying to use the languages and tools that the majority of the designers and developers are using in WordPress – such as Sass, for example – not only because you’ll have the support of a large community who are also using the same languages and tools, but because you’re using the same things to build on top of core that’s already used in core.

But developers are opinionated people and what’s listed above may not necessarily be the most convincing reason to adopt a certain technology over another.

Debates and decisions take time.

Debates and decisions take time.

And that’s fine – this is open source – so we have the ability to choose the things that we like the most and continue to move forward with that. As long as we make sure that we stay compatible with the latest version of WordPress as well as whatever browsers our project is to support, then we’re good to go.

Above all else, though, the problem that many developers are guilty of – myself included – is letting the time it takes to make a decision over the toolset we’re going to use take longer than it should and ultimately get in the way of doing work.

When that happens, I think we’re going a little too far. The decisions that go into selecting our tools for building things should not hinder the process by which we actually, y’know, build things.

Don’t get me wrong: It’s a lot of fun to talk about software. I mean, it’s a lot of fun to debate what’s out there, to compare and contrast why we like certain things over others, and to even spend time tinkering with something new.

But when it gets to the point that we’re actually spending more time talking about building things than actually building things, I think we’re taking it too far.

With all of that said, the thing that I always have to remind myself – as well as those whoever ask for my thoughts on the topic – is that the tools that I’ve selected to use help me to be the most productive given what I’m primarily doing.

Right now, I’m doing most of my work with Foundation or Bootstrap along with Sass, CodeKit, JSHint, and some occasional work with Grunt. And yeah, like any programmer, I enjoy looking at the other tools that are out there, but I know from experience that if I spend too much time trying to make a new tool fit into a tool belt that already has everything I need, or if I spend too much time trying to convince other people why their toolset is superior to mine (which is something that really can’t even be measured), I end up wasting time.

Help Yourself, Help Yourself (Get Stuff Done)

As developers, we need to make sure that we’re always learning. That is, we need to make sure that we’re familiar with what’s available for us to use should the need arise, and perhaps we even need to write a couple of example projects with the tools that are available, but we don’t need to do so at the expense of providing solutions for our customers.

Ultimately, I think there’s a balance to be found between leveraging what works best for our work flow, what’s supported by the community, what’s supported by the browsers, and what contributes most to our productivity.

If it doesn’t fit that criteria, then perhaps it’s not quite ready to be thrown into our toolset.


  1. Ryan Hellyer

    I decided long ago, that using the most popular tools was the best approach. It makes you more employable, provides more opportunities to discuss what you are working on (or ask for help) and ensures that if you do make a bad decision, at least you weren’t the only one ;)

    If I were left to make my own decisions, I’d be using DropBox to deploy code, Less for CSS precompiling, Windows for development, raw JavaScript instead of a library and the backend would probably be custom built with Python.

  2. Paul Underwood

    Hi Tom
    Just wondering what your thoughts are with using composer with WordPress like this bedrock project Which places the WordPress core and plugins as dependencies in your code.

    There are obvious advantages to having your dependencies like this in terms of large development teams. But with WordPress auto updates your composer file could become out of date. Plus with WordPress so good at updating itself and plugins from admin area, do we even need composer to manage dependencies?

    What are your thoughts and how do you deal with this in your projects?


Leave a Reply

© 2020 Tom McFarlin

Theme by Anders NorenUp ↑