WordPress officially released their block editor, Gutenberg, at the end of 2018 with WordPress 5.0 after spending over a year in development. I waited almost 4 months before updating client sites to WordPress 5.0, and when that time came I made sure to retain the Classic Editor in every single site.

Now, I understand why WordPress developed Gutenberg. With today’s existing visual builder themes and plugins (for example, the Divi theme or the WPBakery’s Visual Builder plugin), and a host of online site builder applications (like Wix and Squarespace), WordPress needed a visual editor to stay relevant and prominent in the website creation market.

Problem #1

The first problem I have is not with Gutenberg itself, but with the decision to completely scrap the traditional Text/Visual editor with the release of WordPress 5.0.

It is my opinion that Gutenberg is a content creation tool aimed at designers and “savvy” website owners who don’t know how to write code. These are the same people who are currently using WordPress themes built exclusively on visual builders (like Divi), and people who are using Wix, SquareSpace and other online website builders. I, however, have a hard time believing this population represents a majority of WordPress users.

Gutenberg is a problem for those who lack the technical prowess of anything beyond word processing applications like Microsoft Word or Google Docs. Having to develop a new understanding of a “block system” that isn’t familiar or used elsewhere alienates users and distances them from being able to perform simple work on their own site.

In my opinion, a well-designed WordPress website should mean that an individual wanting to create posts or update pages shouldn’t need any technical knowledge beyond a simple word editor. Content development beyond that should probably be done by someone with the appropriate skillset.

I say this because one of the things I pride myself on doing for my clients is creating websites that they can, to an appropriate extent, manage on their own. I want my customers to feel comfortable updating content on pages, creating blog/news entries, and interacting with customers via comments. I like to automate as much as I can for them, like featuring latest posts on the homepage or easily managing staff profiles. I’m not so keen on the idea of customers, for example, being able to make more advanced changes to their homepage. Why? Because should they make a mess of things, it directly impacts the first impression their customers will have upon visiting the site.

I may come to find that Gutenberg makes it easier for me to create and manage elaborate homepage design and functionality, but even then I’m not sure I would want my clients attempting to do it themselves (unless they really, really wanted to). The majority of my clients want to focus on running their business rather than learning a new tool to write and manage content on their website.

Problem #2

The second issue I have with Gutenburg is what it does to the HTML code in order to properly display the different block elements. A simply written page of content, in the traditional editor we’re all used to, has very little extraneous markup within the HTML code.

For example, let’s take a look at the following screenshots. We’ll see a simple layout of a left-aligned image and some inline text, followed by a paragraph:

Created using the Gutenburg block editor.

Created using the Classic editor.

The first page was created with Gutenburg, and the second page was created using the Classic Editor along with some custom CSS classes. There are some minor differences, but the CSS could be tweaked further to make these look nearly identical.

Looking at the Gutenburg editor versus the Visual Editor, I can’t say I prefer either. Neither properly replicate what is seen by the user viewing the site:

The Gutenburg Editor

The Classic Visual Editor

My biggest concern is the amount of markup Gutenburg injects into the code in order to handle its display. Let’s take a look at the code being used by both Gutenburg and the Classic Editor.

Viewing the Gutenburg Code Editor

Viewing the code in the Classic Editor

In the Gutenburg code editor, we see a multitude of characters commented out (everything between the <!– and –> characters), along with some non-standard ways of setting classes on elements. In the Classic Editor, there is hardly any markup at all, and the HTML code that we do have is intuitive and easy to decipher. There are only a couple of identifiable classes for handling the layout of the content, which is done via the website’s stylesheet.

The primary downfall I see to the Classic Editor approach is that the user cannot see how the content will look in the post editor – they will need to use the preview button to view the content in a temporary preview page on their site.

But this inconvenience pales in comparison to the nightmare Gutenburg (or any other visual editor) is going to cause you should the need arise to switch to a different solution or platform in the future. This is because visual editors use their own unique set of identifiers (code) to manage the display of their visual elements.

If you have built a website using Divi or Elementor (for example), you won’t simply be able to move your content over to a different solution. When you try, you’re going to be left with an unmanageable amount of code discrepancies that the new website won’t know what to do with (and you’ll have to manually edit to make work).

The same goes for websites built on a platform such as Wix or SquareSpace – you can’t just export your content and dump it into a new system. Someone will have to take the time to copy and manually edit everything to work in the new system.

Therein lies my biggest concern with using Gutenburg for designing and managing pages within WordPress. It unnecessarily restricts users to using Gutenburg in the future, making change difficult.

Problem #3

My third concern with Gutenburg is that the extra markup needed to handle the different blocks is going to have an (admittedly small) effect on page load speeds. The more information a webpage has to send to a users browser, the more time required. While this time difference may imperceptible to websites using high-quality hosting and/or to users on high-speed internet connections, most websites are on low-cost hosting solutions and most people are using their mobile devices to surf the web.

So if page speed is becoming more and more important in the world of search engine optimization, why would we be encouraging the use of systems that increase the amount of data a browser has to download?

In Conclusion

Fortunately, there are folks maintaining a plugin aptly named “Classic Editor” which provides the option of disabling Gutenberg and reinstating the Text/Visual editor that has been at the core of WordPress since the beginning. When I updated client sites to WordPress 5.0 I made sure to install this plugin as well. I don’t want my clients logging into their websites to create a post or edit page content and finding a completely foreign system where the text editor used to be.

While I’m not against Gutenberg, and I understand the importance of it for WordPress in today’s website development market, I wish it wasn’t something that was being forced. Allow us, the community of users, to choose which style of editor we’d like to use. Gutenberg is great… for some. The Visual Editor is ideal for others. Give us the choice rather than making it for us.