Pros and Cons of WordPress Visual Editors

divi wordpress page editor WordPress Visual editors like WP Bakery’s Page Builder and Divi Builder by Elegant Themes are two of the more popular WordPress visual editors and the ones we see regularly on the sites we manage.

There are others but Page Builder and Divi in particular are very popular among commercial theme developers. These tools are often included as an integrated tool in popular commercial WordPress themes as well as being available as plugins.

These are powerful tools and do an impressive job of allowing non-developers to build unique web pages with complex layouts via a drag and drop interface.

The visual composer literally allows non-developers to control their sites with a WordPress plugin and often without having to hire a developer.

Bear with me as I get a little emotional…

I HATE WordPress Visual Editors!

developer frustrated with visual editors I don’t hate them because they suck, I don’t hate them because they don’t do what they say they do. In fact they are actually extremely impressive pieces of software.

I hate them because I am a developer. I hate them because they create limitations on the sites I work on. I hate them because they were not designed for people like me and I would argue they were not designed for people who hire people like me.

I would say I hate them because they make my life hard as a developer and they can make my interaction with my clients tough as well.

Ok, I’m back… Spoke to my therapist and she explained that WordPress visual editors aren’t worth the coronary I am on the verge of every time I have to wrestle them.

There are Lots of Reasons to Love Visual Editors

user loves wordpress visual editor These tools are designed to help non-developers layout relatively complex pages full of all kinds of content (forms, video, sliders, text, images, links… just about anything) without knowing or having to write a single line of code.

Like how Microsoft Word makes formatting text easy and doesn’t leave the user with plain text, these editors give their users an abundance of tools to control the format of their post or page.

With no knowledge of PHP, HTML, CSS, JavaScript or any number of other technologies an uncountable number of page layouts can be realized within a WordPress website. WordPress page editors have lots of strengths including:

  1. No need for a developer to achieve complex layouts
  2. A point-and-click interface for visual development
  3. All kinds of available modules to extend what you can do (add videos, sliders, forms, etc)
  4. Simple to install (just a plugin) or often integrated into commercial themes
  5. Built-in responsiveness (mobile device friendly)
  6. Cost-effective (many can be licensed for $50-$100)

Wow! They Sound Amazing… Not So Fast

I told you I hate these things. But aside from the emotional ramblings of an ol’ developer, they do have some legitimate drawbacks.

Visual Editors are Hard for Developers to Customize

developer writing custom code Pages built with such tools are limited to what you can do with the visual editor. When clients ask us to customize the styling, layout, or content of any element on the page, unless there is a module for that – we often have to say “no” or explain limitations.

If it is a styling issue we can end up with a slew of custom CSS trying to target just one single element.

This can be very frustrating for the site owner. If they were interested in the ease-of-use features and the advantages of not needing a developer to work with these tools, they probably would not have hired us.

Most of our clients hire us to maintain their sites, customize them, and basically come up with a way of meeting their requests…. They don’t like to be told “no”.

We don’t just say “no” but there is often a bit of compromise and negotiation of what can or cannot be done because such an editor is in use.

In other words, it is not uncommon for us to run into situations where we could easily accommodate a client’s request in a WordPress site that did not use such a page editor.

Websites Tend to Lose Uniformity and Brand

brand guide Power is not necessarily a good thing

We find that sites that utilize these editors often lack uniformity in their page layouts. Even if they had a nice template system upon launch they often lose this over time.

When we build custom themes for our clients we do so with a strict number of templates, content modules, and styles in mind.

This uniformity through the site gives it a professional feel, a good user experience, and a sense of purposeful design. If every page has a slightly different layout or style than the others, the site quickly starts to feel a little amateurish.

Sure, that is opinionated but I know several developers and designers that just cringe when they see a site that uses many different page layouts/styles with no real pattern.

Performance Can Drop Significantly

Slow things down a bit

chart website performance droping In a day and age when performance (site speed) is a primary focus, these tools can be slow and heavy!

In order to allow you to drop and drag your way through a page layout and then display that layout on the front-end, it takes a lot of scripts. I have seen these scripts and stylesheets double or triple the number of requests that have to be made to the server. This slows the sever, it slows down the browser and slows down the user’s experience.

Google gives page rank preference to pages that load fast. To put it bluntly, you could be hurting your page rankings by utilizing one of these editors. If performance is important to you then you really should think twice about using one of these tools as you are very much sacrificing one thing for another.

The Code is Ugly

Can a computer write code? Sure it can but it’s not pretty to look at.

developer shocked by ugly code

For a developer, there is nothing worse than ugly code. Sure, most of the world never sees it, but we know it’s there. We also know how it can affect performance, and we know how it can make our lives hard when we have to debug a style conflict, figure out why a module is not working, or tune browser compatibility issues.

Just look at what I am talking about:

This is rendered markup taken from the WP Bakery Page Builder:

(Just a simple box with title, image, text, and button)


</div></div></div></div></div></div><div id="pg-4978-5" class="panel-grid panel-has-style" ><div class="home-who-section three-rows panel-row-style panel-row-style-for-4978-5" id="home-who-section" ><div id="pgc-4978-5-0" class="panel-grid-cell" ><div id="panel-4978-5-0-0" class="so-panel widget widget_heading panel-first-child" data-index="9" ><div class="thim-widget-heading thim-widget-heading-base"><div class="thim-heading text-left "><div class="sc-heading article_heading " style="padding: 10px 0px 10px 0px;"><h3 class="heading__primary wrapper-line-heading"><span></span><span>BOX TITLE</span><span></span></h3><span class="line-heading" style="border-color: "></span></div></div></div></div><div id="panel-4978-5-0-1" class="so-panel widget widget_box panel-last-child" data-index="10" ><div class="panel-widget-style panel-widget-style-for-4978-5-0-1" ><div class="thim-widget-box thim-widget-box-base">
<div class="thim-box-simple image-at-top"
style="">
<div class="inner">
<div class="media" style="overflow: hidden;">
<a href="LINK"><img src="IMAGEPATH" alt="ALT"></a> </div>
<div class="box-content"> <div class="description" style="color: #000000;"><a href="LINK">TEXT DESCRIPTION</a></div><a class="thim-button readmore style3" href="LINK">Button</a> </div>
</div>
</div>

This is how I would write the same thing:


<div class="grid-box">
<div class="box-title"><h3>BOX TITLE<h3></div>
<div class="box-image">
<a href="LINK"><img src="IMAGEPATH" alt="ALT"></a>
</div>
<div class="box-text">TEXT DESCRIPTION</div>
<div class="box-button">
<a href="LINK">BUTTON</a>
</div>
</div>

This is the code for a single small box on the page, now imagine what an entire editor-generated page might look like!

It’s the Sign of a Cheap or Amateur site

Now that is just mean

amateur web developer Ok, this one is totally judgmental but I am going to say it anyway and it’s based solely on my experience.

When a site comes to me with one of these editors. The immediate thought is: “I hope they didn’t pay too much for this”.

To me, it’s a copout by a developer. By including one of these in a professional site it says that the developer didn’t do a complete discovery and/or bought a commercial theme and left a lot of the hard work to the client. I call these point-and-click developers and have little respect for them.

Who Should Use a Visual Editor

I think WordPress visual editors have their place in this world. If you are a small organization without a web development team or a web support vendor like FatLab, i.e. you plan to take care of your site in-house and are not a developer, these can be very powerful tools.

Budgets are tough things to measure in web development (given that you can get people to do the same job for five dollars an hour or hundreds of dollars per hour) – however, there is a place to draw a line: I would say that if your web budget is under $5k and you want to keep support costs down then such visual editors can be a powerful tool to have.

I will not take away from the claims these software authors make, these tools will in fact allow you to build complex page layouts with little to no coding knowledge. They can be very powerful.

Who Should Not Use a VisualEditor

Organizations that either have in-house web development expertise or work with a web support agency, like FatLab, to maintain their website may find these tools to be limiting.

Organizations that want the ability to customize how their site looks and behaves without the limitations of software created for the masses should stay clear of these.

And to be perfectly cold about it, if you have a healthy web development/maintenance budget you shouldn’t be using tools built for the masses, packaged in $50 themes, and/or sold for less than $100.

Can You Argue My Points?

I have no doubt that my statements might ruffle a few feathers. There are certainly use cases for such tools out there.

I will stand by the notion that for the majority of our client base (organizations with mission-critical websites and healthy maintenance budgets), such tools inhibit more than they empower.