The Problem With Page Builders

Content management systems (CMSs) are a good thing. They allow users with little-to-no coding knowledge to update the content on their site without involving a professional.

Before WordPress, Drupal and other modern CMSs took hold of the market, developers had a few options:

• Built static sites

• Create their own proprietary CMS

• Use one of the early flat-file or database-driven CMSs (like PHP-Nuke)

Each had their issues: static sites were a nightmare to update, proprietary CMSs very cumbersome and the open-source software wasn’t as flexible as modern equivalents.

Skip forward a few years, introduce a hefty dose of Javascript into the mix, and our CMSs have developed an ecosystem of drag-n-drop page builders that allow end-users to create the pages of their dreams. Or that’s the theory.

Design your own pages!

Page builders are not popular amongst developers. They’re often criticised for being slow and ‘locking content in’ (where the page builder uses shortcodes to build the pages and doesn’t remove them when it’s uninstalled – e.g. Divi).

The page speed can be mitigated by using one of the better page builders – I’ve seen plenty of WordPress sites using builders that load in under a second. The content lock doesn’t bother me too much either. The idea that users can quickly switch page builders is fanciful at best – this would only crop up during a rebuild when it would be factored into a wider project.

My issue with page builders is this: they set the expectation that the end-user/client will have complete control over page layouts when a website is handed over to them. This perception has become so pervasive that many clients expect this level of control as a basic requirement.

This creates several issues, both from a practical development point of view and the ongoing maintenance of the site.

Expectation ≠ Reality

Page builders offer many types of elements that end-users can drag onto the page. In an ideal world, the developer would style each of these elements so they would work seamlessly with each other, no matter how they were used.

In practice, this is impossible. Not only are features added and removed from page builders, but the builders can be extended with functionality the developer could never anticipate. On top of this, sites built with page builders tend not to have the budgets needed to allow sufficient development time to style every element.

The compromise is to limit development to the elements the end-user is most likely to use and document how to use them. Alternatively, a developer could build some template pages out for a client to replicate.

Even if this is resolved, there is a bigger issue: the responsibility page builders place on clients.

Learning design + code

Page builders are marketed as a quick and easy solution that allows users to create new page layouts with zero code. At a high level this is true, but it downplays the knowledge required to use page builders in an effective way.

Even if we assume an end-user is building page layouts that have been fully designed up, there are still lots of considerations:

• How do you make the layout responsive?

• Should an element use padding, margins or both?

• How is consistent spacing between elements achieved?

In truth, page builders assume all sorts of knowledge and rely on the user having a basic grasp of concepts like the CSS Box Model.

In reality, end-users are often designing new pages, too. This can lead to all sorts of mismatches in the choice of type, colour and use of whitespace.

Whether the user learns these bits of knowledge on their own or follows the documentation, they’ll need to remember it every time they update the site. Even step-by-step instructions won’t remove the potential headaches involved in creating these new layouts.

All-in-all, this can result in a frustrating experience for end-users.

Choice paralysis

One of the common fears about commissioning a bespoke website is how easy it will be to update or that the design will be ‘fixed’. That’s not unreasonable, but there’s a counter-argument to be made for reducing the amount of control end-users have over the design, especially if they value how their website represents their brand.

This isn’t about locking clients out of their sites, by the way, I believe they should always have full access, even if not via the account they use for day-to-day updates. We’re talking about the control of page layouts and other design considerations.

For all of its flaws, something like WordPress’ Block Editor actually provides a reasonable compromise. Designers and developers can build the site in a way that allows end-users to drag-n-drop pre-designed blocks to create new layouts.

In my experience, this works well. It’s a more editorial take on page building that gives users confidence that new pages will match the aesthetic and work.

Medium is another great example of this: users choose from a limited set of options and the content never looks too bad...whatever you think of those overlays.

Should you ever use page builders?

They certainly have their place: many smaller projects may not have the time or resources to plunge into something more bespoke. They’re also good for site owners who want to build a website themselves.

Page builders can also speed up development. In some cases, they might allow a project to achieve more than might otherwise be possible given the budget.

In these situations, they can be a strong option as long as the user is aware of the limitations.

Where possible, I’d strongly recommend building modules that can be pulled into pages: especially in situations where a developer won’t be on hand to develop new pages. This is a great halfway point that gives clients some control over the layout without breaking the aesthetic.