This article explains what WordPress frameworks are, and why I generally recommend against relying on them.

In this article, I’ll be looking at WordPress frameworks, including WordPress theme frameworks as the most common category, as well as plugin-based and other kinds of frameworks.

I’ll define what I mean by “WordPress framework,” explain how a framework is different from simply a tool in WordPress, and outline the issues I find with WordPress frameworks that cause me, in general, to recommend against relying on them.

This isn’t an “always/never”-type article: frameworks have their strengths, and their place in the WordPress ecosystem. However, I do consistently have the same kinds of problems, for the same reasons, with WordPress frameworks, and I do steer clear of them when I can. I’ll even make it a point to use only part of a framework I like (for example, Beaver Builder but only the page builder), just to avoid getting roped further in.

My goal is to give you a chance to consider the strengths and liabilities of WordPress theme frameworks and other frameworks, and how you want to approach them in your own WordPress work.

What I Mean by “WordPress Frameworks”

A “WordPress framework” is a piece of software that tries to solve a bunch of problems at once within the WordPress ecosystem.

To define “WordPress framework,” let’s start by defining “framework.” I mean that term in its broadest sense: a framework is a piece of software that tries to solve a bunch of problems at once through a single, central system and approach.

So a framework is like a Swiss Army knife: a corkscrew and a file and a tweezers, not sold separately but all coming off a single common base. Need to do something—anything? Reach for your Swiss Army knife. That’s the idea of a framework.

Adding in the WordPress piece: a “WordPress framework” is a piece of software that tries to solve a bunch of problems at once within the WordPress ecosystem.

What this is different from is a WordPress tool: a piece of software that tries to solve one problem in the WordPress ecosystem.

So that this doesn’t feel too abstract, let me give you some examples.

Examples of WordPress Frameworks

I’ll break these examples down into two categories: WordPress frameworks that are reasonably well-built and okay for what they do, and frameworks that, in my humble but also extremely well-informed opinion, are not.

Good and Okay Frameworks

Some frameworks are good or okay: you can see why someone would benefit from them, why someone put them together the way they are, and so on. A few names in this list include (in no particular order):

• Genesis.
• Jetpack.
• WPMU Dev.
• BoldGrid.
• The Beaver Builder ecosystem, which includes Beaver Builder, Beaver Themer, and more.
• Elementor Pro, which combines the basic Elementor page builder and a feature called Elementor Theme Builder.

Not-Great and Bad Frameworks

And some WordPress frameworks are not great. Some are even bad. Not much more to say about this, but here are a few examples in the not-great to super-not-good range, specifically in the very common category of WordPress theme frameworks:

• Divi theme plus Divi Builder.
• X Theme.
• WPBakery page builder plus an “everything” ThemeForest theme (such as this one).

There also exist many older and less well-maintained theme frameworks that were good at one point but have fallen by the wayside—as well as entire approaches to getting around the basics of WordPress development (such widgetizing everything you can imagine) that no longer exist. That frameworks age out of existence like this is one thing that makes relying on them tricky.

WordPress Theme Frameworks, and Other Kinds

WordPress theme frameworks are the most common type, because the market most often sees themes as the “thing you buy” to “do WordPress.”

In the list above, you’ll notice mostly WordPress theme frameworks: ways of approaching WordPress that use the theme as the starting unit.

In general, this is because—despite the logic that a theme should handle only presentation and not data to prevent theme creep—the broader marketplace is still most likely to see a theme, rather than a plugin or something else, as the “thing you buy” to “do WordPress.” As a result, most “do WordPress”-type framework solutions have been theme-based.

There are exceptions, though: Jetpack and WPMU Dev are plugin-based frameworks that are designed to solve many or most needs a WordPress site might come across. Elementor and Beaver Builder started as page builder plugins and grew from there. And BoldGrid originated as an all-in-one WordPress development solution offered by the hosting company who developed it, InMotion.

Whether it’s a theme framework or something else, the common thread with any WordPress framework is that it finds a way to enter early in the user’s website setup journey, with the logic that “this is how you do WordPress.”

Not All Complex Tools are WordPress Frameworks

Just having a wide range of functionality doesn’t make a tool a “framework,” in the sense I mean in this article. Below are some complex tools that still aren’t frameworks:

• Yoast, which handles a wide range of SEO tasks on a WordPress site.
• WooCommerce, which enables a full-featured e-commerce experience in WordPress.
• Beaver Builder—just the plugin, not the plugin-plus-theme—which greatly improves layout creation in WordPress.

Each of these tools is a significant addition to a WordPress site, but each one has a specific job to do in WordPress. They’re the way you do something in WordPress: it wouldn’t make sense to market them as simply “a better way to do WordPress,” full stop. That’s the difference between a tool and a framework.

Common Properties of WordPress Frameworks

By their nature as projects that try to solve a lot of things at once, WordPress frameworks tend to share some similarities. In general, WordPress frameworks:

• Describe themselves in very general terms, as the best way to summarize the range of things they try to do. A tool’s quick description might be something like “Quickly regenerate your image thumbnails.” A framework’s might be “WordPress + Framework = Awesome.”
• Replace one or more existing parts of WordPress, in favor of their own way of doing things. Tools usually add things to WordPress that weren’t there before; frameworks generally add and replace.
• Carry a training burden, to get you up to speed in the many facets of their own way of thinking about WordPress. A relatively complex tool (such as Yoast) might carry a training burden, but a WordPress framework is almost guaranteed to.
• Are very difficult to turn off, because you lose a ton of things all at once.

Let’s look at two examples to see these properties in action:

Jetpack

What it is: An all-in-one plugin shop by Automattic designed to make WordPress better.

How it describes itself: “The ideal way to experience WordPress.” Offers “always-on security,” “built-in performance,” “code-free customization,” and “effortless marketing.” “The best way to WordPress is with Jetpack.”

What existing system it replaces: The WordPress plugin repository.

Training burden: Learning to connect to Jetpack using a WordPress.com account, use multiple plugins with separate configuration requirements, debug interactions between Jetpack plugins and other parts of WordPress.

Turn it off and: A potentially wide array of things break at once, from Google Analytics to image optimization to WooCommerce shipping. These things can break even by deactivating and then reactivating the plugin, as doing so can prompt Jetpack to demand that you reauthenticate with WordPress.com.

Divi

What it is: An integrated theme-plus-page-builder.

How it describes itself: “Divi takes WordPress to a whole new level.” “You’ve never built a WordPress website like this before.” “Divi is more than just a WordPress theme, it’s a completely new website building platform.” “Divi isn’t just a WordPress theme, it’s a complete design framework that allows you to design and customize every part of your website from the ground up.”

What existing system it replaces: Various plugins: user role management, mailing list management, marketing automation.

Training burden: Learning the Divi builder’s way of conceptualizing layouts, and the places various theme options.

Turn it off and: Your entire site collapses into a mess of shortcodes. You also lose whatever data you may have added to Divi, from user roles to A/B testing to social media links to whatever else.

We’ll return to these examples through the rest of this article.

Advantages of WordPress Frameworks

Frameworks simplify a large and diverse technical topic into a single, less technical approach.

WordPress theme frameworks, as well as other types of WordPress frameworks, have one advantage: they simplify a large and diverse technical topic into a single, less technical approach.

Without Divi, creating a WordPress website is an intricate job that involves choosing a clean, simple, well-fitting theme, knowing which of a number of narrowly useful plugins meet your goals for the site, making a good relationship with a WordPress page builder, and—yes—even knowing PHP. The documentation for each of these things is spread all over creation, and there’s no good way to know which pieces of knowledge you may be missing.

With Divi, everything is centralized into the Divi way of doing things. The documentation is all within Divi, and the knowledge you need is limited to what Divi teaches.

So the value proposition of frameworks is clear and palpable. If I wanted to build a WordPress website in a weekend with no training—and didn’t really care how it worked under the hood or whether it’d be stable or extendable into the future—then Divi or a framework like it is probably close to the best decision I could make. (To be more specific, the Beaver Builder ecosystem would be my recommendation for people in this position, as it fills a similar role to Divi but is coded much better in my opinion.)

Again, it’s not hard to understand what makes frameworks attractive. Let’s look at the tradeoffs.

Liabilities of WordPress Frameworks

WordPress theme frameworks and WordPress frameworks in general carry significant costs to go along with the range of problems they aim to solve. Let’s look at many of the main ones.

The Framework Recursion Problem

WordPress is, itself, a framework for web development. What happens when you nest frameworks?

To understand this problem, let’s step back a bit and realize that WordPress is, itself, a framework for web development: that is, for creating better, more easily administered websites.

To show that WordPress is indeed a framework, let’s look at WordPress through the lens we’ve developed.

What it is: The world’s most popular content management system (CMS).

How it describes itself: “WordPress is open source software you can use to create a beautiful website, blog, or app.” “Beautiful designs, powerful features, and the freedom to build anything you want. WordPress is both free and priceless at the same time.”

What existing system it replaces: HTML, with database-backed PHP templates.

Training burden: The contents of WPShout and lots more.

Turn it off and: You lose everything.

In other words, just by working in WordPress we’ve already taken on a framework, a way of doing things: the WordPress way.

Now, what happens if we nest frameworks? What if we’re now committing to “the Divi way of doing things the WordPress way”?

We start to run into framework recursion:

Symptoms of framework recursion include:

• Problems that have multiple, competing solutions—there’s the framework way, and the framework-framework way. The framework way to manage user roles is with a plugin designed to do only that, but the framework-framework way is with a Divi theme feature. Which is better? What happens if you turn both on at the same time? This is an important source of the confusion that marks many WordPress projects.
• Being prevented from understanding the working of the framework itself because of the heavy overlay of the framework-framework. What is a theme for? How is that different from what a plugin is for, or what a website is for? How should the WordPress template hierarchy work? These things are significantly more difficult to understand working in Divi or the X Theme—or even in Genesis—than they are in vanilla WordPress.
• Suffering a blurry understanding of the difference between the framework and the framework-framework. Where does one begin and the other end? I uploaded an image through Divi. Do I still get to use that image if I get rid of Divi?

Fundamentally, framework recursion is about the unsteadiness that results when you stack all-in-one solutions on top of other all-in-one solutions. This unstable stacking is at the root of the other framework liabilities discussed below.

The Silo Problem

If you invest deeply in a framework, one result is that you will be limited to one way of thinking about problems.

If you invest deeply in a framework, one result is that you will be limited to one way of thinking about problems. A framework says, “Here’s the approach you’ll take to every problem you come across.” Even if that works, you lose flexibility.

I know what I’m talking about here: once again, WordPress is a framework, and to work as a WordPress developer is to have one’s technical world limited. As a WordPress developer—as distinct from a full-on software engineer, or from someone, like David, who is both—I see constantly how that job description makes it easy to accept limitations in the scope of my technical knowledge, and in the types of problems I’m able to solve.

Working almost entirely within WordPress has given me enormous powers on most kind of website projects. But it’s also made it very easy to stay ignorant on many topics in full-on software development: the kind they used to build Uber, or, for that matter, Uber’s fleet of self-driving cars.

In my opinion, WordPress development is siloed enough without further siloing oneself into one particular approach to it.

Since we’re in WordPress already, the question becomes whether you should be paying a double tax: to limit yourself to being, say, a Divi or Elementor implementer—someone who looks at WordPress only through a Divi or Elementor lens—rather than a full-on WordPress developer.

If I were just starting out, that would be tempting, but having learned WordPress the hard way I’m grateful for the expanded scope. To be limited, within the already limited world of WordPress, to solving only framework-accessible problems is to be restricted from working fully comfortably even within WordPress. WordPress development, in my opinion, is siloed enough without further siloing oneself into one particular approach to it.

The Cruft Problem

Did you ever download an “all-in-one” ThemeForest theme with 20 homepage options? Much like certain kinds of fast food, that seems good until you buy it.

A website only has one homepage. The moment you set up the theme, 19 of those homepage options become cruft: code that is there, but serving no useful purpose.

Cruft is not neutral; it’s bad. Consider that the theme developers had to code the homepage as a massive “if”-statement between those 20 theme options. Your theme will be bulkier, slower, and harder to work with because of the 19 homepage options you aren’t using.

Frameworks are a great source of cruft—stuff you don’t need but can’t get rid of—because they try to do everything at once.

Frameworks are a great source of cruft—stuff you don’t need but can’t get rid of—precisely because they try to do everything all at once.

WordPress itself has a fair amount of cruft. Do you remember the “Press This” bookmarklet, or post formats? In addition to the features nobody uses, some parts of WordPress are situationally cruft. For example, for a simple website with only static Page content, the entire “Post” post type—with its Category and Tag taxonomies and so on—is cruft.

We accept these unneeded parts of WordPress because the bulk of WordPress is so useful in a vast majority of cases. But what about if we now add framework-frameworks? On a given project, do we really need Divi’s:

• A/B testing feature set (when we have better-designed tools for this)?
• Proprietary contact form builder (when we have Gravity Forms)?
• “Over 800 pre-made website layouts”?

These things are sitting in the theme and builder whether we need them or not, making it bulkier and harder to work with: more convoluted theme template files, worse performance, more space on the filesystem and database. This is because frameworks do everything.

Now: what if you’ve got Divi and Jetpack? What if you’ve got the Divi Builder and Jetpack on a Genesis theme? What if you want to use the Divi theme but the WPBakery page builder?

If these solutions were simply tools—like Yoast or WooCommerce—mixing them wouldn’t seem insane. But they’re frameworks, and using them together is not at all fun to imagine because of the massive cruft collisions that would result.

The Lock-In Problem

That frameworks are difficult or impossible to turn off is definitely Not a Good Thing.

As we’ve mentioned, you can’t turn a framework off without losing everything. This is definitely Not a Good Thing, for reasons you could describe in a number of ways.

Each of the frameworks listed above wants your money in one way or another. When you stop paying, you will slowly lose access—most commonly, because when your framework updates your framework-framework doesn’t.

If you’ve ever worked on a site that uses the old Visual Composer, you know that this is to have your sadness compounded. WordPress will update fine from 3.x to 5.x, but buying a new premium license just for the privilege of breaking a Visual Composer site is a testament to the liabilities of framework-framework development.

Frameworks: Do They Really Make the Drame Work?

Again, I’m not saying “No frameworks, none of the time.” But I really do try to stay away from all-in-one solutions when feasible. In the approach I try to take, WordPress itself is the framework: the Swiss Army knife whose various tools solve my needs in web development. I learn each of those tools deeply, use them for what they’re good for, and that’s it: no framework-frameworks needed.

I hope that’s helpful food for thought, and that as you choose how you’d like to approach WordPress development, you have a bit more of a conceptual… you know… framework.

Thanks for reading! As always, if you have any questions or thoughts, leave them below, or we’d love to hear from you in our Facebook group.