WordPress should deprecate themes — a modest proposal

This post was inspired by Justin Tadlock‘s post on WP Tavern entitled Themes of the Future: A Design Framework and a Master Theme.”

Justin’s post touches on aspects of WordPress theming that I have contemplated over the past decade while working with WordPress. But some of my thoughts differ from Justin’s because — unlike Justin — I am not a designer nor am I a themer.

“Imagine if — starting with version 6.0 maybe — the WordPress team chose to actually deprecate themes, and then added modules and components as first-class extensions instead? “

Mike Schinkel

Instead I often wear the hat of a PHP/MySQL/Javascript developer who works on WordPress sites. But more importantly for this post, I also wear the hat of a frustrated end-user who has always struggled to build professional looking website for my own uses, since I have absolutely zero design skills.

ASIDE: For those of you reading this who know I am a professional WordPress developer/engineer and are curious how it is I can work with WordPress and am not be able to create an attractive design, the answer is simple. I always work on client projects with a team, which will include a great designer and/or front-end developer.

IOW, my expertise is back-end development and the architecture, maintenance and devops for complex mission-critical WordPress sites. I leave making sites attractive to other people who are great at that kind of stuff.

My frustration related to WordPress theming has stemmed from the state of theming in WordPress and how it feels like many themes are viewed by their creators as works of art, and less like a functional layout designed to provide website owners a layout that meets the (business) objectives for their the website.

As a non-designer, I have tried god-knows how many themes. Ultimately however I have thrown away every. single. one. of. them. I either built a theme from scratch when I had a designer and/or front-end developer on the team, or more often, given up on launching the site.

In my experience any given theme does at best only 85% of what is required for its use-case, and I don’t have the design or CSS skill to finish the other 15%, hence my frustration. Not to mention the fact that (IMO) the more attractive a theme is, the greater likelihood that its code will be a complete mess of spaghetti that is almost impossible for anyone other than the original author to modify.

(Almost) all themes for WordPress are monoliths that end-users cannot maintain themselves, except for those with a myriad of settings (which are typically frowned on my WordPress thought leaders.)

But even though themes with a lot of settings can meet a higher percentage of any given end-user’s needs, the more settings a theme has the more complex they are and the slower-to-load they are. Worse, said themes locks a user into never being able to update their theme without a herculean effort and/or paying a king’s ransom.

Personally, I have never found a theme that is 100% useable without some significant HTML+CSS customization and/or PHP/MySQL/Javascript customization. And even the best themes use development approaches that require a going onlarge time investment in content maintenance because the themer made easy coding choices rather than build functionality to allow managing content with less effort. Examples include using categories to group content where a custom taxonomy would be better, and a custom post would be best.

Just the other day one of my clients asked me for help: “We need help setting up a new WordPress site, and we have picked out a theme.”  I told this client that whenever tells me they “have already picked out a theme” it causes an immediate feeling of impending dread for me.

In this particular case I recommended they use a page builder instead of a theme. But not because page builders are a good solution but because they give enough control for an end-user to complete a site without having to bring in the high-paid and temperamental developers and/or designers.

But “high-paid and temperamental” is not a slur! I too am high-paid and temperamental; I just know that few use-cases where WordPress is used can justify the fees of a high-paid person to complete a site.

Returned back to Justin; he writes about “needing more designers in the conversation” — to which I agree with — but in the next sentence he discusses minutia about class naming which just sends designers and front-end developers down a path of so much bikeshedding. Better to focus on the high-level goals rather than the lower level details.

Justin also states that if “you put 20 designers in a room and ask them to discuss design frameworks, it could be a recipe for fisticuffs.”

Which is almost certainly true, but what he does not mention, or possibly does not recognize, is that once a framework is put in place everyone pretty much just falls in line and starts using it. Take a look at Custom Post Types, the Customizer, and even Gutenberg. If WordPress were to implement a design framework into core — and many people would piss and moan about it at the time — almost everyone would fall in line and start using it within a year after release.

But I do not think that a adding a design framework is the right approach. Or should I say I do not think a design framework would be sufficient.

Instead what IMO is really needed is for WordPress to embrace the web components standard and forget thinking about themes altogether.  Rather than selecting and installing yet another theme what would be 1000% better for the end-user would be a pallet where they can select components — and composite components a.k.a. “modules” and then assemble their site with those components however they need it.

Rather than look for a theme that has all the features one needs — which I have found always limits the choices to zero — a site owner could look for the components and modules they need and then assemble their site from those modules. They could pick a header, a footer, a home-page hero, a set of article cards, a pricing module, and so on.

This is basically the same concept as the existing page builders, but with a standards twist; read on.

Existing themers could innovate by creating palettes and families of components designed to go together, and WordPress could possibly even create a marketplace for those components so that end users could buy different components from the different developers that they can be sure are designed to work together based on shared design “schemes.”

Frankly I think themers who sell themes would make a lot more money if they sold individual components and modules instead of full themes. And I believe most site owners would be super happy to pay a lot more for a collection of modules and components — I know I would — because they would be getting exactly what they need, and not 50-85% of what they need after which they have to invest a king’s ransom of money and time to complete the final 15-50%.

Justin also wrote “Themes would lose their personality and we would live in a world of cookie-cutter designs” if WordPress were to introduce a theme standard into code. But I say that is just fear of change talking. Constraints are your friend, and constraints can supercharge innovation.

What we have unfortunately seen since the dawn of WordPress is lots of innovation in theming, but most that  “innovation” has been duplicated 1000 times over, each time by a different themer, and in a manner that is completely incompatible with what the other 999 themers implemented. None of those themer’s work can be used in combination with the work of any others.

A user can’t take the home page of one theme and the pricing page of another theme. If the theme they like does not have all the components they need — and when does a user ever find a theme that meets all of their needs? — they are pretty much out of luck.

Themes are all silos, and never will any two meet. Theming in WordPress has been like the biblical Tower of Babble where no themes can speak to each other, so we have not been able to build much beyond the themes that exist.

Imagine if — starting with version 6.0 maybe — the WordPress team chose to actually deprecate themes, and then in their place added modules and components as first-class extensions instead? WordPress itself could provide the canvas on which to place components and then WordPress could manage displaying them. 

If WordPress core were to deprecate themes and embrace modules and components there would be no cookie-cutter designs; it would free designers to build self-contained user experiences within modules — and those modules could be mix-and-match — and then the sky would be the limit because themers would not have to deal with all the non-creative minutia required to build a fully working and fully workable theme?

But let me address the elephant in the room; Gutenberg Blocks.

I did not speak to Gutenberg Blocks because I have no experience as a developer with them. But what I understand — which could very well be an incorrect understanding — is Gutenberg Blocks are complex and have not really been designed to be used when Gutenberg is not generating and/or orchestrating them.

My guess is that Gutenberg blocks are almost certainly not designed to the web component standard and are implemented using a set of fragile CSS conventions and Javascript frameworks. Which is an architecture that will quickly become legacy as the state of the art in CSS and Javascript development evolves, as they do.

I also question if WordPress core will be able to maintain the same level of backward compatibility that it has maintained prior to the Gutenberg era. Methinks the complexity of ever-changing Javascript and the Gutenberg implementation will make robust backward compatibility nigh impossible in the coming year.s

But what about all the existing page builders? The problem with page builders is that their modules/components/blocks are all proprietary (AFAIK?)

Their modules/components/blocks also work in the context of the page builder but not designed to be developed and/or used without the page builder. I don’t mean to say they do this to lock people in, only that the architect a flexible framework would IMO be an order of magnitude harder than just getting a page builder to work with proprietary markup and CSS.

So ideally WordPress would offer a framework based on web components standards that could support a page builder UI — or many different page builder UIs, each from different vendors — but could also support hardcoding of the components into pages for those who like to version control their websites.

Well, this turned into quite a rant. Once I started writing it just flowed, so this has clearly been a pent-up frustration in me for years.

I know even the thought of deprecating themes will send fear and loathing shockwaves across the WordPress theming ecosystem. But please, before summarily dismissing the idea with a knee-jerk, contemplate the possibilities of delivering modules and components designed to be mixed-and-matched instead of churning out yet another theme that can never be used in conjunction with the work of any other themer.

4 Replies to “WordPress should deprecate themes — a modest proposal”

  1. Hi Mike,

    Interesting idea. I think for anything to work on the scale of WordPress you need an architect who has done it before. As a developer you know that often there is a trial and error, revision cycle and solutions come together over time. There was some of that with Gutenberg … which is probably why there are inconsistencies for theme builders.

    I wonder if something as simple as standardized class names would provide more interoperability between themes?

    I am a bit surprised by your deep frustration with modern themes and perhaps there are some misconceptions. Lots of options (i.e. in the Customizer) might slow things down when using the Customizer because of all of the JS controls, though many themes have now worked beyond that. Themes like Page Builder Framework (or Astra, Generate Press, etc) offer plenty of Customizer options, but load quickly when the site is visited.

    Keep thinking outside of the box.

    Regards

    1. Hi @David McCan,

      Thanks for the comment.

      My concern with standardized class names is they would require the developers to actively opt-in instead of just redoing it the way they prefer. And that assumes that the developer pays enough attention to even know there is a new standard. My belief is the only way to address change like this is for core to only work correctly when the developer follows the new standard.

      As for my frustration, my post probably over-emphasized the complexity and performance as a problem and under-emphasized lack of capability/flexibility to achieve the site goals. And often it seems that the things I want to achieve are a common UX around the web but are very difficult to accomplish with any given theme.

      That said, once bitten twice shy and I have not tried to set up a new site of my own for several years, although I will need to do that in the near future. What I will probably use is Mobirise — which is the best website layout tool for non-designers I have ever found — and it does not even support WordPress so I will basically build the site with Mobirise and then write a theme based on that HTML & CSS that it generates.

  2. Gutenberg blocks are simpler than you think they are. Also, welcome to the same realization I had about 18 months ago. 😁

    A block is basically a user interface to create HTML. Doesn’t matter what the HTML is. Can be anything. Can have styles, or not. Whatever. At the pure form, it’s a JavaScript based “form” to create HTML to be inserted into the post content. The post content itself ends up being straight HTML. No JavaScript needed to display it.

    So. Yeah. That’s where it’s going. If you want to make a block that creates custom web components, nothing preventing that as far as I know. Everything produced still ends up in a post content as HTML. Feasible, certainly.

    1. Hey @Otto,

      Thanks for the comment.

      I think maybe we are talking two different things about the blocks. It seems you were talking about how the content is stored in the post — as HTML — and I was talking more about the Javascript implementation of the blocks whose purpose is to ultimately store that HTML.

      I was also talking about CSS and how — based upon articles like this — it appears Gutenberg requires that all block’s styles to be good citizens and follow conventions to ensure they do not clobber other blocks. But if core where to embrace web components then HTML & CSS would be sandboxed per this article (emphasis mine):

      “What’s truly amazing about these new elements is that they fully encapsulate all of their HTML and CSS. That means the styles that you write always render as you intended, and your HTML is safe from the prying eyes of external JavaScript.”

      As for creating a Gutenberg block that creates custom web components — absolutely that is possible — but that that is a bit of a moot point because doing so would not address the reason I proposed them. Web components need to be first-class in WordPress core or the blocks that are not web components do not get the benefit of sandboxing. An analogy might be the difference between installing a firewall on a server and installing a firewall around an app for a single port; sure the one app is protected but protecting that one app does not stop hackers from compromising the computer on which the app is running.

      But let me say this; I am not against Gutenberg. Ideally Gutenberg will be the way forward and will be able to possible embrace web components as a near future enhancement as Gutenberg has far more interia that any potential alternative. And maybe a new feature version of Gutenberg will embrace web components as first class in which case any debate we are having on this will likely be moot.

      BTW, the reason I am paying attention to this now is I am a leading a team of WordPress developers and we are re-architecting ~10 sites to use a shared plugin and we want to implement everything as components rather than design and build pages as they always have. We’ve looked at a lot of solutions, and the one I propose here is the one that we identified as the best solution currently available without switching to full single-page app or using Gatsby. Of course getting getting WordPress core to adopt components is not part of our plan — it would be foolish to expect that — but it would be great if we did not have to reinvent so much of the wheel to get a fully componentized infrastructure for the needs of this organization.

      Bottom line, I just want standardization of a solution that works without more complexity than absolutely necessary. Gutenberg is a step in the right direction, but the jury is still out if it will be able to take us all the way, or not. Time will tell I guess.

Leave a Reply

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