Theming the Drupal Way: Is Custom Wrong?

It seems to me theming in Drupal is broken up into two camps - those who use a contributed base theme (Zen, Omega, Fusion, etc.) and those who write their own custom themes.  Although I don't have statistics (and would love them if anyone does), it seems to me the most common approach is to use a base theme.  Now, I don't believe in a one-size-fits-all solution to really anything on the web, and I will quickly acknowledge the diverse needs of companies/persons that lead to decisions surrounding a theme.  But, I just want to take a moment to speak to the pros/cons of each and my personal decisions regarding this in the hopes that it might aid someone in making the decision.

Pros and Cons

Contributed Base Themes

Custom Themes

I've tried to keep these descriptions simple enough, but in case they warrant further detail, I will quickly explain.  Listed above are the largest pros/cons to each with what I believe to be the most important factors in bold. First of all, contributed themes tend to come with all the perks inherent to open-source software.  They often have been through the communal gauntlet, which holds them responsible for semantics, accessibility, advancing technologies, etc. Also, there is typically great support given they are often popular themes in the contrib space. The flip side of that coin though is that they are obviously going to be multi-purpose by nature. Drupal serves a massive array of website/app needs, therefore any "plugins", including themes must be heavily agnostic. This means the theme can accomplish a lot but it also means that it likely has a large code base and learning curve possibly unnecessary for a given project.

Personal Experience

Warning: What follows are ONLY my own experience and opinions.  I do not believe they are 'gospel' nor are they set in stone. So take it easy on me, and I would love constructive feedback. :)

When I started working in Drupal theming, I quickly decided against contrib base themes for all the wrong reasons. My un-Drupal-educated eyes took one look at Zen, for example, and thought, "What the hell is going on here? Why do I need all this?" Two things went into that reaction, one vaugely applaudable and the other just downright ignorant. The ignorant reaction came out of a lack of understanding in terms of what was going on in the actual theme logic. While HTML/CSS/JS made some sense to me, the Drupal-specific parts were in large part foreign to me at the time.  It seemed massively cluttered for my needs, which leads to the vaguely applaudable point. I like my code footprint to be as tiny as possible. Particularly when it comes to front-end technologies, I don't want clutter.  I don't want it visually when I am working, nor do I want it affecting load times. Still today, I remain constantly on the prowl for new ways to limit this, and I believe that is a valid challenge more than ever with the rampant rise of devices on slower connections.

While I've come a long way in understanding the benefits of all that logic (and now enjoy much of it's power), I still find myself running into the same wall in terms of code size/footprint. Not only do I want themes to be small on load, I want the code base to be small as well when working in the theme and doing bug fixes. Even if the code isn't run when an option is not selected, I still want every piece of code to matter and be used on a project. If I'm consistently not using it, I don't want to have it in the theme layer when I or my team is trying to troubleshoot.

This is why in both Drupal 6 and 7, we ended up crafting custom themes to use as a foundation on most projects (not in the traditional base theme sense but as a starting point). Not only are they tiny in footprint, but we can gut them as needed per project so that they always are as small as they need to be depending on modules, etc.. Ideally, nothing is loaded that isn't being used. But, let me go ahead and state the worries that remain constantly in the back of my mind in choosing this approach.  The onus is on me and my team to stay abreast of best practices and to support these themes over time. There is no wider support team constantly working on new features and fixing bugs, there is no audience pushing us on accessibility issues or advances in technology that affect the code.  It is fully our responsibility to maintain the quality of these themes. 

But here's the "devil's advocate" argument to that (I like to talk to myself): the onus is always on us anyway. A base theme can only take so much off your shoulders in terms of support and quality. It is still only the bare bones foundation for your project, and if you're like us, the majority of your code will still be custom and require knowledge of best practices, advancements in technology, etc. anyway.

And this for me is the key dividing line between modules and themes in Drupal. I struggled for the longest time to justify this view of base themes in light of the fact that I feel pretty much the opposite about modules. When it comes to Drupal core or contrib modules, I believe in relying on what is provided and not hacking against it.  I don't mind that Webform, for example, often has a lot of unused code when I use it. If I were a programmer and were constantly hitting the limitations of these core/contrib modules, I might feel differently I guess. But for me, I use only modules that I really need and I think twice about using one that will only give me 20% of the functionality I need in a unique situation.  And that is what contrib themes sometimes feel like - 80% of the weight for 20% of the functionality.

Point and Click versus Coding

Another reason I have moved away from some base themes is the GUI interface.  As a Front-End Developer by trade, I want to understand and try the technologies at play in a theme and tend to be much faster coding than operating through an interface.  Although I love that Omega put Drupal on the map early in the responsive design movement, this is one of the major reasons I personally steer away from it for most projects.  Responsive design is not that technically difficult. I realize this is a broad statement, so bear with me. Accomplishing a responsive design involves adding very little knowledge on top of your front-end toolbox that likely wasn't already there before.  Also, the basics of responsive design are very quick to implement (e.g., media queries). The major difficulties in responsive design are more often in scope and project management, not coding (although there is obviously the long tail of learning involved in being an expert on anything). So for example, it takes me .5 seconds to implement a media query breakpoint in a design from code snippets and since I'm already in the code, it is more work (and weird/awkward) to enter an interface for that simple action and then leave to return to coding. This is obviously specific to my style, but hopefully it helps clarify and understanding of point-and-click control versus a theme that is mostly not controlled through a GUI.

HTML5 and Responsive IE

Another point of contention for me is assumptions. While I'm making some points against base themes, let me just go ahead and state what my favorite one is - Zen. The latest release of Zen is such a powerful representation of the Drupal community being on the forefront of Front-End Development. It is mobile-first, responsive, uses HTML5 elements and even has Sass/Compass usage built-in. It is such a strong base theme and has been for so long, I have the utmost respect for John Albin and the rest of the support team. It also is much less interface-driven (see point above) and in line with how I theme.  However, it makes some assumptions that I don't (at least not yet). While these are options that can be turned off through the interface, it by default provides HTML5 elements in markup and responsive design and turns on javascript to make older versions of IE play nicely with those two technologies. Again, this is personal preference, but I prefer not to punish the worst browsers at parsing javascript with extra javascript.  Although I do build mobile-first in my responsive themes, I tend to serve a "desktop" version to older versions of IE instead of making them using responsive technology. The same rules apply for HTML5. I love what the new elements offer, but I don't think it's fair to force old IE to understand the new elements (again, personal opinion). My main point in bringing this up though is not to argue supplying these files vs. not but to point out that when I use Zen, I'm not using a lot of what it has to offer in these areas. I immediately disable these and therefore am leaving a lot of code in the theme that is not being used.

Closing Thoughts

Maybe the most important point I can make here is that this whole conversation is based on your needs and your client's needs.  If I were anyone but a full-time Front-End Developer and I wanted to get a cool responsive site going, I would likely use Zen, Omega or one of the other responsive base themes.  Because I probably wouldn't have the desire to learn how to code that kind of functionality (similarly to how I feel about modules, I guess). Likewise, for enterprise clients (or anyone) requiring some level of access in-house to theming resources but who maybe doesn't have a strong FE developer on staff, it might make sense to use it too.  I should also note, in case I sound in any way disrespectful towards those who created/support those themes, that I stay abreast of what those themes are doing constantly and have the UTMOST respect for their creators.  They have provided much of the foundation for my own custom themes and provide a constant source for inspiration and technique evaluation. In many ways, they are the litmus for Drupal themers everywhere to measure by.

So, with that said, here's the general advice I will offer.  If a base theme works for yourself/your projects and the pros outweigh the cons, absolutely use one.  If you don't need specific functionality required by a theme and/or you are very familiar with front-end technologies, I challenge you if you haven't already to write custom themes and even custom base or starter themes for projects. If nothing else, you may be surprised by how much you can actually remove from the standard templates and files.  Who knows, maybe one of us will end up creating a new contributed base theme ourselves!