Over the course of the past 6 months or so, there’s been a lot of buzz regarding theme frameworks. It’s no wonder, with the influx of framework releases and their rising popularity. Suddenly more developers (and some users) are taking notice and trying to determine what they are exactly, how they should be used and to what end. Despite the arguments against frameworks, there are many good reasons for using one. The point may be lost to some however, if the purpose behind it is misunderstood.
So, what is a theme framework really?
Most developers already have a broad sense of what a framework is but in granular terms (as it applies to WordPress theming), a framework is basically a large-scale template (or outline), which presents a way of rapidly developing themes based on common axioms. Did you catch that? It presents a way. So a WordPress framework can mean different things to different people.
It may be a collection of modularized style sheets, scripts, or plugin support files set in a distinct hierarchy. It may be a minimally styled theme with hooks, custom functions or microformats. It may be a theme devoid of styling, but with a semantically rich set of classes applied to the markup. (Technically, even this is a framework.) Regardless of what’s included or discarded, one certainty is that each framework will have a particular style of organizing, coding and referencing the components within it.
Based on this explanation, we can at least deduce that frameworks are NOT:
- a one-size-fits-all theme (such a thing doesn’t exist in my book)
- a formula that every developer/project can adhere to
- an all-encompassing solution (that kind of thinking only kills creativity)
So what’s the big deal about frameworks then?
If you can concede the points above, only then will you begin to see the potential. There is no ONE framework that will fit every developer’s style or every project’s need. The idea of a framework was never intended to be a singular answer. Those who misinterpret it as such will never realize the value therein. If you recognize there are benefits to using one but don’t quite know what they are, here’s a few things frameworks can do:
- offer a stable, methodical way to approaching projects
- expedite repetitive tasks
- reduce the margin for error
- simplify the provision of customer/client support
- provide an easy, future-proof alternative to theme customization (i.e. child themes)
Sounds great right? I can’t imagine why anyone wouldn’t want those things… but not everyone has the ambition to create a framework and of course there will always be skeptics of the whole concept. The question is, could you benefit from a ready-made templating system? Yes, if one or more of the following applies to you:
- I’m a developer in need of a remedy for the obstacles and time-sinks that come with coding from scratch
- I’m a designer searching for a way to increase productivity or streamline my workflow when it comes to post-Photoshop development
- I’m a developer looking to adapt a framework to serve my own needs, improve my product line or enhance my support system for existing products
Wait! I’m a consumer and I just want to know what this has to do with me.
Well, you’re in luck. Customers may have the most to gain from frameworks. When you use a [child] theme built on a framework (such as Thematic, just for example), the author can provide updates and/or new functionality when it becomes available – and you won’t have to worry about losing or rewriting your customizations every time! If you doubt it, jump on Twitter and ask Ian or Nathan. They’re big proponents of protecting customer modifications.
I’m interested. How do I know if a framework is reliable or suited for me?
A surge of frameworks have already been released and I’m sure there’s more to come, but only you can make that determination for yourself. That’s one drawback of frameworks. You may not really know until you work with one for a while. Unfortunately, if you must experiment with several before finding something you really like, that’s a significant investment of time and a big deterrent – especially if you fall into one of the aforementioned categories.
I’ve never been deeply set in a particular workflow and I find the concept of using a framework very interesting, so I’m willing to investigate the possibilities of someone else’s ideas. I’ll adapt what is useful, reject what is useless, and create what is specifically my own. Perhaps I’ll release the result someday. For now, I’ll refer you to the following list of framework candidates:
Sandbox – Probably the de facto of theme frameworks… or at least it used to be. In the early days particularly, Sandbox lived up to its name by being the theme that everyone tore apart to learn from and build derivative works with.
Sandbox theme by Plaintxt.org
K2 – described as an advance template, K2 is perhaps the first to support sub-templates called styles (or what is now more commonly known as child themes).
K2 theme for WordPress
Thematic – The brain child of Ian Stewart, Thematic is establishing itself as the “go-to” theme. Quite a bit of ingenuity went into the building of this framework, and it continues to improve with each release. It’s also well supported, with a growing community of enthusiasts.
Thematic by Themeshaper
Theme Hybrid – With over a dozen custom page templates and widgets galore, Hybrid is another framework making waves (so to speak). Justin Tadlock is the developer behind it and like Ian, he has also established a strong community with equal support. Additionally, Hybrid has been translated into an impressive list of languages besides English.
Theme Hybrid by Justin Tadlock
WP Framework – On par with Ian and Justin is Ptah Dunbar, who created his own version of a framework. While it hasn’t been around as long, the author has regularly released maintenance updates.
WP Framework by Ptah Dunbar
Carrington – This framework is a bit different in that it’s designed specifically for use of WordPress as a CMS. It’s developed by a small but talented company, is very well documented and has a ton of actions and filters which can be employed. It’s a bit intimidating at first but I think given the time, a developer could really run with it.
Carrington by Crowd Favorite
Vanilla – While not necessarily described as a framework, it is based on Carrington and appears to be a lot of potential behind the idea.
Starkers – Developed by Elliot J. Stocks, this is mainly just a “naked” theme, which actually stemmed from K2. For those with simple requirements, this could be all the framework you need.
Whiteboard – Within the same school of thought as Starkers, this framework is another blank theme type.
Empty Canvas – Also falling into the blank theme category is the appropriately named Empty Canvas. While not described by the author as a framework at all, it could still serve as one based on what we deemed a framework to be in this article.
Thesis – Although marketed as a framework, the fact that Thesis is 1) a full commercial theme and 2) geared mainly for the end user who doesn’t know HTML/CSS – disqualifies it in my opinion. It’s also my understanding that it contains quite a bit of proprietary code. It would be difficult then, to determine where the framework “outline” ends and the developer specific code begins. That said, Thesis is still worth mentioning here because with it, Pearson has pushed the envelope of theme development and introduced other devs to some exciting new possibilities.
Summary
This article was not designed to advocate frameworks nor deny their usefulness. Every developer is different and has a unique way of approaching a task or completing a project. The intention was simply to inform and motivate those who seek to understand frameworks and what their cabapilities are, to debunk any misunderstandings and to showcase particular works which I feel could benefit a variety of developers who make their living with WordPress. I sincerely hope it was a helpful resource. As always, you’re invited to add your thoughts on the topic below.
