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:
- Any number of jQuery plugins
- …and so on forever and ever.
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?).
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.
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.
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.
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.