Building themes “from scratch” is a waste of time
I frequently hear WordPress developers boast about how they refuse to use any sort of starter theme or framework when building out their sites.
I’ve even heard it morphed into a component of a deluded sales pitch: Well I build my themes from scratch, that other person uses a *scoffs* framework.
This is a strange thing to brag about.
When you say “I build WordPress sites from scratch” you’re basically telling people “I love wasting time and am too prideful to use tools to make me more efficient.”
If you’re one of those people, hopefully this post will convince you to adopt a workflow that incorporates some sort of starter theme or framework component.
By the way, you’re not actually building it from scratch
If you wish to make an apple pie from scratch, you must first invent the universe.
This is one of my favorite quotes of all-time, because it perfectly illustrates the absurdity of claiming to build anything “from scratch.”
Where exactly is the “from scratch” line drawn?
Copying and pasting code snippets and functions from other themes? Writing your own CMS? Developing your own programming language? Building your own web server software? Operating system? And on and on until the proverbial “universe” is created?
No matter how you slice it, nobody makes anything from scratch. For this reason alone, you should stop claiming you do. But this is just a peripheral concern.
It’s inefficient and unsafe to not use a framework
I doubt anyone who claims to build sites “from scratch” are actually using their own custom-built CMS written in their own custom-built programming language, etc.
In the WordPress world, they’re probably just starting their themes with a basic <!doctype html> and plugging in WordPress functions as they go.
You may have been able to get away with this in the early days of WordPress, but theme development has changed greatly over the years. Users have grown to expect themes support certain things.
A boneheaaded example would be a theme not including a wp_head() hook before the closing </head> tag. Without it, the compatibility with many plugins would be dead in the water.
The list adds up when you’re building a theme for public release, and have to support a baseline of core WordPress features.
Poorly coded themes, as “from scratch” themes tend to be, can very easily become an attack vector for hackers.
For example, a translated string may not be properly escaped, giving the opportunity for a malicious translator to insert nasty code on a user’s site.
It’s an unlikely scenario, but why leave it to chance?
All right, you convinced me, what should I build from?
I prefer Underscores. The Sage theme is an interesting choice. Many swear by Genesis.
Some like to combine one of the above with the front-end framework of their choice, like Foundation or Bootstrap, into their own personalized starter theme that is better geared towards their particular clients.
This post isn’t really about advocating for any particular starter theme, framework, or workflow. It’s more about convincing you to find one that works for you and sticking with it.
If you want to stop wasting time doing repetitive theme development tasks, it’s best to start now.