Why is Gutenberg still so terrible?

Warning: may contain ranting. May be incoherent at times. May be coherent at times and say mean things that cannot be unsaid.

Gutenberg is still terrible. That is the realization I’ve come to (in October 2021). WordPress is on the doorstep of making WordPress as a CMS “all about Gutenberg” with the eventual release of the FSE (Full Site Editor) that uses Gutenberg to edit site templates including headers, footers, page and post templates. In other words the same confused and inconsistent nightmare available to us from Gutenberg in one area of the site, can now be used to create frustration and inefficiency everywhere. Thanks WordPress!

I want to point out a couple of things before proceeding with this rant. First off all I’m not in the camp of people who took one look at Gutenberg and immediately said I don’t like it, turned it off, went back to using Classic Editor and haven’t looked at it since. I’ve genuinely tried to like Gutenberg. I’ve setup demo sites with the latest Gutenberg and tried out the full site editor. I learned how to create blocks using React and the NPM block create package. In fact when working on Saber Commerce there was a moment I told someone else in the industry who builds addon plugins for Gravity Forms, this is the way of the future. So what changed? Why am I now fairly firmly in the Gutenberg bad camp?

The main reason I don’t like Gutenberg is simple really. I used it. As somebody who likes good software (like my favorite software ClickUp), I fall in love with a good UX. I enjoy using good software. And generally, I avoid using any software I don’t like the look and feel of. I want every piece of software I use to be a comfortable place to work, because to some extent software interfaces is my office even more than where I sit. What I see on my screen, that’s my working environment. So I want a good working environment. Unfortunately Gutenberg doesn’t manage to get the formula right, at least not for me. I’m going to try in this article to get to the bottom of why, because honestly it’s sometimes hard to put into words. The bottom line is I built a large landing page for a client using only Gutenberg, and it was one of the most painful experiences I’ve faced in 17-years as a site developer. Then a couple weeks later I was training someone who has joined our team in a site editing and admin capacity, and I wanted them to learn both Gutenberg and Elementor. This person is smart, tech-savvy, but does not write code. She has some design background, and is very fast and learning software. After a few lessons in both Elementor and Gutenberg, this individual was able to produce sections in Elementor that looks professional grade, even solving responsiveness issues and demonstrating the ability to match a rendered design with 99% accuracy. Meanwhile in Gutenberg she was getting stuck on the most basic first steps, and nothing useful was ever produced. Now could we push through and eventually teach our trainee to handle Gutenberg and produce something using it? Sure. It would just cost us 10-times as much time and money to do the training, and then the result would be we could spend double or triple the time going forward to produce a vastly inferior result. This is given that when using Gutenberg as it stands today, matching professional designs without some custom code is nearly impossible. It takes only a few clicks on the front-end to find at least some flaws that cannot be fixed without custom CSS.

The way it’s always been for me with software is I want to use whatever is the best available. With project management I fell in love with ClickUp last year, made the switch from ActiveCollab and never looked back. It’s just better. And when I find somebody using Trello or Notion.so I just feel sorry for them, because it’s like I’ve got an M16 and their trying to get the job done with a pellet gun. This is exactly how I feel about Gutenberg versus Elementor. There is just no question that Elementor is better. And it’s not just a little bit better, it’s massively better. Let’s examine a few key ways it’s better:

Gutenberg Lacks Design Accuracy

Elementor is accurate. Elementor actually loads in the WP Admin as you can see if you look at the URL when you load a page into Elementor. I think it uses iframes to show us the front-end view. Whatever the magic behind it, Elementor has achieved 99% accuracy. It is very rare, almost never that the rendering from Elementor differs from the actual view on the page. And if it does, there is usually an obvious reason, and it often involves a dynamic widget, a flaw in a 3rd party widget or even just the width of screen difference caused by the Elementor editor being open. And some of these things are unavoidable. Plus the goal isn’t perfection. I can go days, maybe even weeks of working in Elementor and never see a single case of design inaccuracy. Compare that to Gutenberg where I will see design inaccuracy within the first 10-seconds of opening it. By nature, sadly by design, Gutenberg is simply not accurate, ever. It’s 100% inaccurate. Perhaps the people behind Gutenberg will argue well it’s not meant to be accurate. But isn’t that like saying this car isn’t meant to be capable of stopping when you press the brakes? Remind me to come up with a more fitting analogy here… the point is even if the makers of Gutenberg wish to tell us that the purpose of Gutenberg is different from Elementor or that it’s not meant to be measured this way… I’m going to keep measuring it this way because these tools are competing in the same space. And one tool is 99% accurate and the other is at best 10% accurate, on a good day?

Gutenberg Provides Poor Contextual Awareness

I hope I’m using the term “contextual awareness” correctly here, but if not I will try to explain what I mean. As a user when I’m in Elementor I know where I am and what I’m doing. So I feel comfortable. There are some secondary options in Elementor where I might be sure where something is, or exactly what the options will be, but I never feel entirely lost. And I’ve seen beginners to Elementor figure out most options on their own. That’s because Elementor provides really good context awareness. It’s fairly obvious from the screen where you are and what the options are. Gutenberg in this area is not all bad. The main controls are fairly obvious and with just a small amount of practice a user can get fairly familiar with what they’ll see if they choose for instance to switch between page and block settings in the right side panel. Where Elementor begins to show the roughness around the edges is when you actually use the body of the editor.

Plus signs everywhere. While it’s worth giving credit to Gutenberg for the concept of nested blocks, something that many people in the Elementor space have asked for in the past… and this is one area where Gutenberg could really excel… right now anytime you have a block loaded that has nesting, you’ll have an “appender” which is either a small plus icon, or a block based version of that. I think the block based appenders work fairly well like those used in columns, but the small icons look so “flimsy”, and they have the tendency to sit randomly in different positions on the page. And because some parent block containers add content at the end of themselves, the appender for an inner block can end up sitting within a few pixels of the identical appender which is for the outer layer. This is a confusing thing to write about, better demonstrated with an image. Now how should this be handled? How should an editor handle nesting and providing the controls for nesting? I don’t have the answer to that, but it would be a good idea generally that when building software if you can’t do something well, don’t do it at all. And I think that’s exactly why Elementor was hesitant to provide nesting, because they didn’t want to create a confusing mess of a UX, better to ship something good with limitations than to ship something that promises the world but just feels like trash. Using nesting blocks in Gutenberg is quickly a painful experience, aside from the appenders appearing in a dozen places it’s also not clear where we are in the editor. Meaning it’s not clear when we click into the hierarchy of blocks, are we clicking the grandchild block or the parent block or the outer block?

In general I always feel as if working in Gutenberg requires me to “figure out where I am” instead of the software providing that intelligence for me. In other words instead of Gutenberg saying clearly “here you are” instead I have to check the tree list… squint at the screen to try to see the 1px blue lines around the selected block… scroll up and down the page in hopes of seeing the selected item because when I pick it from the tree list it might still be off-screen. By the way the tree list is a life saver in Gutenberg, in fact without it I would almost find the block editor completely unusable. But as me and another editor user discussed in a conversation recently… in Elementor we don’t even use the equivalent “list inspector” very often. It’s a rare day, because it isn’t needed. Whereas in Gutenberg, I found it to be the more reliable and faster way of finding blocks and selecting them. This is because when I’m working in Gutenberg I try to avoid ever clicking inside the editor because the editor body (where the actual design content is) is so flimsy and prone to jumping around that I try not to disturb it. Click to fast and Gutenberg just explodes. This is of course an exaggeration… but I’m not alone in feeling that way. That as soon as you interact with blocks… a lot of different things tend to go wrong. Like you can accidentally grab and drag something and end up nesting it. You can accidentally end up selecting a parent or a child block very easily. It just never feels as if we the users are in control, instead Gutenberg has it’s own ideas about how to produce garbage of it’s own. In this sense Gutenberg is more like a garbage waste grinder unit than a design tool.

Gutenberg Lacks a Therapist Option

Anyone who is forced to use Gutenberg for more than a few minutes will suffer trauma. Yet the Gutenberg editor doesn’t have any option to get a therapist to provide a counseling session. I just feel like as a help and support option, Gutenberg should come with a button where you can be connected directly to a therapist who specializes in page builder and design editor related frustrations. Somebody who understands that the point of a page builder is to save time compared to learning to code and then coding… but with Gutenberg it would honestly be much faster to just learn HTML and CSS and then learn enough PHP and learn theme building.

You might think I’m joking about this. Well, about the therapist button I am joking. But about learning to code being faster than using Gutenberg? Not really. It depends what the goal is. Let’s imagine your goal is to produce junk that has no value in the marketplace. Then sure you can just drop blocks into the page, press publish and you’re done. It will look like junk, it will never make a penny, mission accomplished. But what if you’re goal is a professional grade site that does need to compete in the market? Well then yes, learning to code HTML, CSS and PHP and then learning enough about theme development to write custom templates… would still be faster than achieving the same result in Gutenberg. A crash coding course could be completed in a few months, a couple of hundred hours of study and practice. Whereas the time needed to build something useful in Gutenberg, well it’s all that and more because you will still need coding skills to produce anything useful in Gutenberg anyway. After all you can’t ignore the flaws in the mobile design. You can’t ignore the lack of spacing many of your blocks will have due to the lack of consistency in design options. You also can’t just change your design to not use all of the background features that are missing when compared to Elementor or other page builders. In other words, if you’re not willing to compromise quality, get your code editor out because Gutenberg requires code for it’s blocks to render in a way that is even remotely consistent with professional grade sites.

The fallacy that Gutenberg’s quasi-HTML output is a user editable storage layer

Gutenberg uses HTML, mainly HTML comments in fact, as it’s storage layer. And on many occasions I’ve seen people involved in the Gutenberg project speak about how great it might be that users can now edit template files directly just by editing the HTML content. Well as somebody who has over a dozen years of experience writing HTML, let me point out how flawed that idea is. You see writing HTML is fine, but one of the reasons for using a page builder is because it’s so repetitive and often adds little value to write the same HTML tags over and over again. The idea that users will be able to, or want to, edit the output from Gutenberg is just stupid. It’s just a theoretical concept that has no basis in reality. The output from Gutenberg is barely recognizable as HTML at all. A lot of the important data is stored as comments. Editors will tend to show those comments as light grey blocks of… comments… because it’s not meant to be code that you edit. The indenting and the spacing of the Gutenberg output is also not consistent with how humans normally write HTML. Bottom line for me is I would not wish having to edit a large Gutenberg page manually by editing the quasi-HTML Gutenberg output.

The defacto standard for moving data around these days is JSON. Elementor stores it’s output as JSON. This works very well programmatically. Of course it’s not user-editable. But that’s okay, because that’s the entire point of having Elementor to begin with. The Gutenberg idea might be nice in theory but all they’ve done is create a less workable format. Inventing a vastly less useful format for it’s data storage instead of using a much more widely accepting and tested existing format is just a sign somebody early on in the Gutenberg project felt the urge to create something even if it was something less useful and less reliable.

Similar Posts

Leave a Reply

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