First we had Twenty Ten. Then came Twenty Eleven. Then came the potential of a new default theme every year.
This week, the core team announced the development of Twenty Fifteen, yet another default theme that will ship with WordPress core.
I might be in the minority, but I think this is a pattern that needs to stop. We don’t need a significant re-structuring of default themes every single year. We need leadership in the theme development space.
Default Themes
In 2005 Kubrick launched as the new default theme, then didn’t change for five years. It became a punchline for the project. With Twenty Ten a new pattern started, with every single year having a new theme, naming it by the year. Twenty ___. This gives the theme an expiration date and it doesn’t have the pressure to be the end-all theme for the ages, because it’ll be replaced in the next year rather than in five years.[ref]Why Default Themes Change Each Year[/ref]
When the first Twenty X themes started shipping, I was excited to see what appeared to be an annual iteration on theming best practices built directly into WordPress core. When Twenty Eleven was shown to be such a deviation from Twenty Ten, and subsequent editions proved to be wholesale rewrites rather than iterations, I lost my confidence in the pattern.
WordPress itself doesn’t rewrite year after year. We add features, deprecate older code, and iterate on new learning, best practices, and performance optimizations. The WordPress of tomorrow is the same as the WordPress of today, only better.
The default theme of tomorrow, however, has absolutely zero ties to the default themes of today, yesterday, or last year. This is a major disappointment.
Leadership
The worst feedback I’ve gotten in the past is when new clients look at a site design or a premium theme and immediately say:
I don’t know. It looks too much like WordPress to me. I want something more unique.
The thing is, they’re keying in on the typical header, content, sidebar, footer layout that just about every blog-style site has. In the past, we took Kubric and made some tiny changes to the design before shipping a site. Multicolored backgrounds, 3D corners, multiple sidebars. There were a handful of tweaks that came stock, but no one really moved outside the box until new themes came along.
Rather than create a new theme from the ground up every year, the WordPress team should focus on one theme. One theme that adds in new features as they’re baked into core. One theme that grows and evolves with the core codebase over time. One theme that demonstrates best practices and helps lead the way for new themers and developers getting involved.
It doesn’t need to be all things to all people; no theme ever could.
But we can take this default theme and spin child themes off it. Look at the variety of designs on the StudioPress site to see just how far developers can take child theming using Genesis as a base. Look at the variety of designs on CSS Zen Garden – designs built on the same markup and only differentiated through CSS.
There is so much more we could be doing with themes if we didn’t scrap the default theme every year and reinvent the wheel with a new release. We decided long ago that kind of development cycle wouldn’t work with WordPress itself, so why do we follow it with the default WordPress theme?