When building things for the web, we normally refer to “the stack” as the set of software that we use that powers an entire application. Generally speaking, this usually consists of three things:

  1. The database
  2. The application layer (or the server-side programming language
  3. The front-end

Today, there are many different types of data stores available: We can use anything from a traditional database to using a document-based database system, or some type of abstraction provided by another service like Amazon.

For the application layer, we can have Rails, PHP, .NET, Python, and who-knows-how-many-more. And for the front-end, we generally use HTML/5, CSS/3, and JavaScript (and variations thereof).

But if a stack usually refers to a set of languages, tools, or technology that goes into building something, and each area of an application can be further divided into subsets (like with the front-end), does it make sense to have terminology for each of these areas as well?

The Traditional Development Stack

Technically, we do have terminology for each of these areas – they’re listed above – and those who work on all areas are generally referred to as “full stack developers.”

But what if you’re primarily a front-end developer, or an application layer developer, or any-layer developer? When referring to each part of the stack, we usually say that we have a set of tools, frameworks, libraries, or dependencies that we use.

Open The Jar

That makes sense, too. I mean, we don’t want to start overloading terms that generally refer to the full application in the context of part of an application. This is why we have terms like backend-developer, application developer, front-end developer, and so on, right?

Just as we generally have a set of predefined technologies that go into a stack (such as IIS, Microsoft SQL, and NET or Apache, MySQL, and PHP, or Apache, Java, and Server Pages, and so on), what if we were to have a set of common technologies that we use to create WordPress themes?

What’s a WordPress Theme Development Stack?

Though when thinking through this in the context of building WordPress themes (which are predominately for the front-end), does it make sense to have a pre-defined set of tools that you typically use to get your work done?

This is not to say that I think there should be a single set of tools that we all use to build themes – not at all – but for each project, rather than choose yet-another-CSS-framework or yet-another-JavaScript-library, what if we were to, say, spend a year building themes with nothing but a single set of tools?

What would it look like if we were to focus solely on a small set of technologies with which we use to assemble themes for a year?

For example:

And we can take a little bit further and say:

  • Templates will be creating with vanilla PHP (or maybe with something like Timber?)
  • All documentation will be written in Markdown (which variant?)

Maybe we’ll tie it all together with something like CodeKit, Gulp, Grunt, or some other build tool.

Granted, there are far more options than what’s listed above that are available for us to use. These are primarily shared as an example of what could be used. It’s not so much about the specifics of the tools that we choose, but the set of tools that we use and how they interact with one another.

During a time where there are a near-impossible number of things to learn and to use, the idea of doing deep dive with a handful of technologies in an effort to become an expert in each and to assemble a number of products using each tool seems like a novel idea.

It's Not Impossible

Well, it’s not impossible. About as possible as this, I guess.

So say that for one year, you had to pick a stack of technologies with which you’d be building commercial WordPress themes (versus those for contract work). What technologies would you choose and, for fun, why?