Theme Composition vs Frameworks

Posted on April 1, 2014 by

For a long time, theme frameworks have been the primary alternative to building things from scratch in WordPress, and to a lesser extent, starter themes. There is a better way.

Starter Themes & Frameworks

Starter themes work on the paradigm of adding and replacing. You’re given a theme that represents the ‘halfway’ mark and add what you need to it, and replace the parts that don’t.

Frameworks are essentially extended starter themes that provide you with a way of doing things, and a sizeable API and library through which to do them that’s intended to save you time. Examples include Genesis, Hybrid, _s etc..

These ways of creating themes I will term development from foundations.

The problem here is that what you want to build doesn’t always fit the foundations provided. You have to kludge your theme to fit into the frameworks way of doing things, and make do with the trade-offs and design decisions that the framework made, trade-offs that were made for the generic case, not yours.

Theme Modules

Some have tried to get around this by trying to implement module systems. A starter theme comes with a large number of component modules which are then selectively included via a module loading mechanism.

While this is an improvement, it’s an incomplete form of the actual solution. This is because the module loading and bespoke module collection is a very loose albeit more flexible form of foundation, and one is still limited by which modules are available and their inclusion.

Composition Rather Than Framework

The alternative, is composition. Instead of building on top of something, take parts that already exist, and assemble them lego style. This way you write the glue that binds them together, rather than creating pieces to fit into predefined slots, and you can assemble them however you like.

To aid me in doing this I’m going to rely on the power of Composer, though tools such as git submodules or svn externals could be used.

In my scenario, I pick and choose packages that provide things I like, and then bundle them into my theme. I then initialise them in my functions.php and let the tools do the rest.

Imagine I did the following:

require: {
    "rarst/meadow": "*", // TWIG based templates
    "scribu/theme-wrappers": "*", // scribus theme wrappers
    "tomjn/theme-common-styles": "*", // a class or two that add some styling I use a lot like the left align images etc
    "tomjn/youtube-white": "*", // I like white youtube embeds, here's a class that adds those
    "humanmade/Custom-Meta-Boxes": "*", // maybe I like their metabox API
    "cftp/responsible": "*", // adds a responsive tester to the admin bar
    "foobar/gridsystem": "*", // some css/less grid system
    "icit/wp-less": "*" // a LESS stylesheet plugin
}

Followed by a brief bit of code in functions.php to set those up

<?php

// autoload all our things
require 'vendor/autoload.php';

// set up Meadow for TWIG templates
$meadow = new \Rarst\Meadow\Core;
$meadow->enable();

WhiteYoutube::start(); // something like this for example youtube class

\tomjn\common_styles::add(); // add in common style stuff

// etc...

Then I can immediately start using things such as using index.twig instead of index.php, or en-queuing LESS files directly. Composer will load it all auto-magically so I don’t have to require and include files.

Or you may have no interest in any of those and decide to pull in completely unrelated libraries, perhaps one that provides helper functions for loading images etc The point being that you can pick and choose what you want and how much you build yourself, without being forced to do it one way or another.

A real world example is Rarsts’ Hybrid Wing theme:

	"require"    : {
		"php"                : ">=5.3",
		"composer/installers": "~1.0",
		"rarst/hybrid-core"  : "~1.6",
		"rarst/locate-vendor": "~1.0",
		"twbs/bootstrap"     : "~3.0",
		"pimple/pimple"      : "~2.0",
		"rarst/meadow"       : "dev-master"
	},

Here he pulls in Twitter Bootstrap and Meadow for his front end templating, then locate-vendor, the hybrid-core framework, and pimple, to structure his themes internals. He can also specify the versions that he wants.

Going forward, this is the only reliable way of doing things. Frameworks will always have disadvantages, unnecessary baggage, and complexity of some sort weighing someone down. Instead, assemble what you need and glue it together instead of trying to make what you want fit into pre-prepared slots.

22 thoughts on “Theme Composition vs Frameworks”

  1. Sounds interesting, but what’s missing is ease-of-use. I’m quite happy to take something like _s as a starting point, get my php-hands dirty and hack away to achieve what I need, so I’m not a complete novice by any means, and yet the details (rather than the concept) of what you wrote went straight over my head, and I’d need some persuading that it was worth learning what looks like a lot of new and unfamiliar stuff…

    Reply

    • In the lego analogy, a framework and starter theme is like a half built lego café, it’ll always look a bit like the original lego café but there’s only so far you can hack around the original design to make it do what you want, at which point you’re disassembling the original and rebuilding it anyway. Maybe this lego café is great but the main door is in an awkward position and everything else depends on that to work.

      Instead if you got given a box of generic lego, and could go grab prebuilt sections and assemble them however you want, then you can still save time and no longer have to do things a set pre-determined way. You decide where to put the rooms, and place blocks to connect them together, a connecting wall here, a set of stairs there, hey presto done.

      How you get those pieces though is up to you, a lot of people manually download things into place, some use version control to pull in remote stuff, I use Composer. It has it’s advantages and it’s a powerful tool, but you don’t have to use it yourself.

      Reply

  2. This is a bit of the direction the Hybrid Core framework has been moving in. The first order of business was to create a modular system so that devs only needed to use things that they needed. Now that many of these modules are self-contained scripts, it could potentially open us up to more flexible options like allowing devs to simply pull the pieces they want to use into their projects. There are some modules that are already completely separate with their own repos and can work just like you propose.

    Of course, this all comes down to everyone’s own workflow and so on. Personally, I like pulling the entire framework into my theme project because I typically use most of the features (which makes sense because the framework is written by me for me). Others might want just pieces of it. That’s something I’m excited about and hope that I’ll be able to offer more of because Hybrid Core is essentially a collection of different theme scripts that I’ve written.

    Reply

    • Your Hybrid Core is really interesting. I like the way you use “theme-support” to include necessary files. This is kind of “autoload” but more WP-specific.

      Anyway, I like your work very much and take some parts of that, include in my themes!

      Reply

  3. Pingback: Theme Composition Vs Frameworks | Multipop

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.