If you’ve spent much time developing WordPress sites, you’ve likely encountered a staggering number of choices for where to begin. Different developers have different styles and preferences. I know some folks who like to just grab Twenty x (-Ten, -Eleven, -Twelve…) and chop it up. Others prefer “boilerplate” starter themes (like Blankslate, Underscores). Lots of developers love using a framework (like Thesis, Genesis, Hybrid Core) as a parent theme upon which to build. Some people like to literally start from scratch and write every single template file by hand. All are valid choices, and all have pros and cons. I won’t give a sweeping endorsement of any particular choice, nor will I get into anything technical here, but I’d like to share a few reflections from my experience with these methods of developing for WordPress.
What’s Your Goal?
Okay, so this should be beyond obvious, but during initial planning stages, you really need to determine your intended user experience (and target market), what functionality is needed to provide that experience, and what features or sections the site should entail. Will you have a blog? Are you displaying a list of products for sale? How about an extensive multimedia area with audio and video? How much social interaction should the user have on the site?
Once you’ve really narrowed down what you do want out of the project, you can start thinking about what you don’t want. Does your e-commerce store really require an RSS feed? Do you actually need a portfolio display template on a tech spec site? I like to streamline my code and focus on just what’s needed, which brings me to my next point.
Excess; in computing: superfluous or dysfunctional files, code, or elements.
I love the word cruft. It’s one of those words that, spoken out loud, sounds like what it means. One of the things I’ve come to realize from creating child themes is that along with the flexibility of quickly developing with one-size-fits-all frameworks comes a lot of code that you aren’t going to use at all for your particular project. So what? That’s not the worst thing ever. But depending on the framework, you’re sometimes talking about thousands of lines of code in functions, styles, and scripts that don’t need to be parsed.
There are loads of “blank” starter themes and boilerplates that include zero styling and just the minimum functionality needed to display the loop and proper markup, leaving you free to build out only the features you absolutely need. I sometimes prefer this route, especially if I just really don’t need a lot of the stuff that comes with it, and I can easily hand-code my own widget areas, post types, page templates, and so on to fit exactly what the project calls for.
Power and Flexibility
On the other hand, you could certainly argue that the power and flexibility of a framework system is more than worth any of the “excess” code. We’ve all said “if I only had more time, I could ___.” In terms of project management, that means to me that frequently, efficiency and quick delivery are far more valuable than anything gained by a meticulous approach to hand-coding elements of the site that the end user may never see anyway.
Sure, you might not need a particular website feature right this minute, but the ability to swap in features and functions with a quick
add_action(‘before_header’, ‘that_function_you_didn’t_think_you_were_ever_going_to_need’); is pretty useful, especially when you’re busy. Furthermore, many of the popular frameworks have great documentation and vibrant discussion/support forums full of folks who are eager to lend a helping hand.
Extensibility, or, What Does This Lever Do?
On one hand, depending on how extensive the documentation available may be and how much you know about the framework you’re using, building out features using all the built-in filters and hooks may become second nature. Many theme frameworks have benefited from the work of dozens to hundreds of contributors over the years, and can provide rich functionality out-of-the-box for all sorts of integration with social platform API’s, SEO optimization, data structuring, and lots of things that could take one person a very long time to put together.
On the other hand, especially if you already have lots of your own code snippets and plugins that you like to use, and a markup structure that you are happy and familiar working with, you can build your own theme from the ground up with every bit of functionality that you need, comment your code accordingly, and be confident that when it comes time to grow your site, you’ll be 100% at home with your own work, and able to extend the code in a natural, fluid way.
Trying Something New Is Good For You
I’ve frequently seen endorsements of various frameworks calling one or another the be-all, end-all, best-ever tool for developing WordPress themes. I can definitely relate to that level of loyalty to something that works extremely well for you. But I also have to say that for me personally, half the fun is in finding yourself in slightly unfamiliar waters and devising a great solution for the task at hand.
Yeah, it’s smart to have something very consistent to rely on at times, but it’s also a great challenge to take yourself out of your element from time to time, whether that means using a theme with a set of action hooks you aren’t familiar with, coding a whole theme from scratch, or just drinking tea instead of coffee. It’s up to you!
No Wrong Answer
Of course, as I said at the beginning, I’m neither endorsing nor opposing the use of frameworks or boilerplates. I’ve had success with many different methods of developing WordPress sites, and I think it’s always better to have more options in your tool kit than to limit yourself to one way. In the end, it comes down to what works the best for you. Experiment and find out what you like! Hopefully this offers a little food for thought for your next project.