A few weeks ago I made a comment on Twitter about how underpriced every WordPress page builder is and one of the more exciting replies was from WordPress founder Matt Mullenweg:

It’s no secret that I’ve been a vocal critic of the Gutenberg project. To me, the vision of “for everyone” is an impossible vision that more or less guarantees that the block editor experience won’t be fantastic for anyone.

Beyond just the workflow experience, though, I can’t get interested in any dev tool or workflow unless one major thing is accounted for. Maintainability.

Building and maintaining a website are two very different things. In my estimation, creating a site that’s not maintainable is not an accomplishment. If you check one essential box (publishing), but fail to check the other (maintainability), you’ve failed as a developer.

This is why I’ve been equally critical of page builders like Elementor, Divi, and Beaver Builder. These page builders encourage users to build websites that aren’t easily maintainable because they don’t provide the necessary functionality to ensure maintainability.

If you’re not sure what I mean by maintainability, here are some videos you can watch:

• PB101: L07 – CSS Variables & “DRY” Development Principles
• PB101: L08 – DRY Development With Classes & Global Styling
• PB101: L12 – Styling With Color (& Scalable Color Management)
• PB101: L14 – Proper Dynamic Content Management in WordPress (CPTs, Custom Fields, Loops, & More)
• BEM 101: How to Make Web Design Organized & Scalable
• Utility Classes vs Custom Classes: How to Build Maintainable Websites Like a Pro

Since this is a topic of mandatory importance, I pressed Matt on the concept of maintainability with Gutenberg.

This is basically Matt saying, [You can build custom, maintainable websites with Gutenberg] “…since the release of the Twenty Twenty-Four theme.”

That intrigued me. Perhaps the block editor was further along than I previously thought.

So, I decided to try it by seeing if I could replicate “Feature Section Victor” from my Frames library. It’s an intermediate-level layout with feature cards that reveal an image on hover.

This is a layout that I can build from scratch in Bricks Builder in under 15 minutes and that almost any modern page builder can handle with ease. But what does the workflow look like in the Block Editor?

Is the WordPress Block Editor really “for everyone?”

I’m not new to front-end development. I’ve been building websites since I was twelve and using WordPress since 2005. I have had a successful agency for years and have published hundreds of hours of front-end development training videos.

The thing I’m definitely new to, though, is the Block Editor. All of my work is done in page builders. Namely, Bricks Builder.

My goal was to record myself trying to build Feature Section Victor. If the Block Editor is “for everyone,” then a front-end developer with tens of thousands of hours of experience should be able to use it without issue, right?

You’d think so. But it didn’t go so well.

Why I want the block editor to succeed

Contrary to what many believe, I want the block editor to succeed. I think WordPress is a more robust platform when it has a capable native builder attached to it. I also believe that having so many different page builders with so many different workflows makes things more difficult for the average user and more difficult for clients to find capable agencies using sustainable tools.

If the block editor ever manages to check all the essential boxes, I can see myself using it. I can see myself switching over to it, even. Doing everything natively in WordPress feels better from a philosophical standpoint.

The execution has to be there, though. I’ll never switch based on a positive outlook alone. Or philosophical visions. Or any other nebulous mumbo jumbo.

I love Kirby Smart’s line, “You’re either elite or you’re not.”

That’s how I treat page builders. You’re either elite or you’re not. And right now, as is true with most things in life, there is a toddler-sized handful of elite page builders.

If the block editor wants to be in that category at some point, the Gutenberg team has a lot of work to do.

Issues I knew I’d run into

I did some prep work to familiarize myself with the native blocks and Site Editor. I didn’t want to go in 100% blind, but I did want it to be a “first build” situation, so I refrained from actually building anything. I just wanted to get a lay of the land.

Here are some of the significant issues that I knew I’d experience:

• No stylable classes. The Gutenberg project doesn’t seem to believe that one of the most fundamental tools in web design – classes – are important.
• No unique semantic elements. There’s no section element, for example. So there’s no way to define global styling for a specific semantic context.
• Poor HTML flexibilty. Groups can’t be converted into unordered lists or list items, for example. This makes building with semantic HTML next to impossible.
• No CSS Grid. You’re forced to use inferior flexbox controls for all layouts (unless you do what I did and write custom CSS).
• List view issues. The list view not staying available at all times has been a problem since list view was introduced.
• No partially-synced patterns. This is coming, I know. And I’m stoked about it. It’s the only thing that provides an important level of maintainability. Alas, it’s not here yet.

That’s not all. There’s a laundry list of other missing items that are essential to professional work that I didn’t even get to because the section I was building didn’t happen to require them.

Issues that surprised me

There were a few issues that I didn’t expect to run into during the build:

• Custom CSS is only available in the Site Editor, and the experience is atrocious. Keeping two editors open at all times is a bad workflow and a no-fly zone for people using single monitors or small screens. Additionally, the fact that the CSS editor lacks every fundamental feature, down to the lack of tab indent support, tells me that the Gutenberg team doesn’t ever want to see you writing CSS. The minute you take your coat off, they crank up the air conditioning. The message is clear, “Go somewhere else.”
• No element-based custom CSS. All custom CSS has to be global, it seems. You can’t attach CSS to specific elements on specific pages and certainly can’t attach custom CSS to classes placed on elements. This is a tremendous limitation.
• Some of the default styling is way too specific. I had to use !important on three separate occasions during this simple layout build. Not only that, I had to spend a bunch of time wondering why things weren’t working because it never clicked in my brain that the CSS I was writing was being overridden. Why? Because there’s zero logical reason for why it would be. Default styling should have zero specificity to allow the user total development freedom.
• There is no way to share the pattern I made. While I can save the pattern I built to the pattern library, the fact that it required custom CSS in a separate stylesheet makes it unshareable. This defeats the purpose of the pattern library. I build custom layouts in Bricks, add them to Bricks’ pattern library, and push them out to thousands of users without issue every single week. This is not currently possible in Gutenberg.
• Most of the controls are unintuitive. The block spacing dial was set to “0,” but there was still spacing until I touched it. Everything requires too many clicks. Too much stuff is hidden and abstracted away. Fundamental names are changed, which requires experienced developers to relearn basic terminology. I could probably keep going.
• No width controls on any elements. Seriously? Wait. Seriously?
• “Content Width” vs. “Wide Width.” I still don’t know what “wide” is for. The only thing that matters in web design is content width. Beyond content width, users should be able to set a custom width value on any element. I can’t think of a single use case for a “wide” element unless it’s designed to break out of its parent container. However, I’ll defer to someone who finds this feature valuable – please explain why it exists so I can get in on the secret.
• Group vs. Stack control changes. It seems to make zero sense that I lose the “inner blocks are content width” setting when I change a Group to a Stack. The whole “Group, Row, Stack” concept is nonsensical in the first place. In web design, everything is a box. Any box can flow in any direction. We don’t need separate elements that can all behave like each other, and we certainly don’t need different elements that lose or gain fundamental settings when their flow direction changes. What does the flow direction have to do with whether or not an element is full width or content width?
• I couldn’t align my text to the left on mobile devices. The intro content is centered on the desktop, but the design calls for it to be left-aligned on mobile. Since there are no breakpoint controls in Gutenberg, this was a requirement I couldn’t fulfill without going back to custom CSS (something I didn’t bother with in the video).

Again, these are only the issues I experienced trying to build one relatively easy section.

“But Kevin, just build custom blocks!”

This will be the argument that many use. To which I say: Then it’s not “for everyone,” is it!?

Sorry, but your average front-end developer isn’t custom coding blocks in React. And why should they be doing such things when page builders like Bricks and Cwicly allow them to build anything they want with nothing more than decent CSS fundamentals?

You’re telling me that any time someone needs to do something more advanced than padding and flex alignment, they have to custom-code a block? Is this the “for everyone” experience? Is this the true vision of the WordPress block editor?

Not only is that not plausible, it’s wildly inefficient and impractical. Imagine stopping your entire workflow to build a custom block simply because you needed a card that reveals an image on hover.

“Custom blocks” is a terrible argument.

Now, if you have a different argument for how we should be using the block editor to build maintainable websites, I’m all ears! Please, show us!

Is the block editor a page builder?

One issue I’ve had with all this is that I don’t think most people even know what the vision of Gutenberg is supposed to be, officially. Is it supposed to replace page builders, or am I using it wrong?

I polled my audience on Twitter (which is relatively small since I just started actively using it recently), and it seems they’re just as confused as me.

66.7% of people think it’s supposed to replace page builders and 1/3 of the ecosystem thinks it’s not supposed to.

If it is supposed to replace page builders, then it’s failing pretty badly, especially considering the 5+ year development timeline.

If it’s not supposed to replace page builders, then what’s it for?

Update: Block Editor Demonstration Entries

First, here’s my demo of doing it Bricks Builder for comparison:

The following people have submitted respectful and thoughtful demonstrations of their approach to this layout in the block editor. I would recommend watching these to see their perspective and understand what’s required different from Bricks. You also might learn something new!

NOTE: Only post thoughtful, respectful comments if you choose to engage with these users.

Brian Coords (@briancoords)

Read Brian’s block editor thoughts as well.

Danielle Zarcaro (@QueerDevPerson)

Final thoughts

My basic conclusion matches my premise: the Block Editor isn’t for everyone.

And here’s the worst news: It stands almost no chance of being for everyone at any point in the future.

To build a good product, you have to pick a primary audience. Being “for everyone” is the fastest and easiest way to fail. Front-end developers and your average Joe Business Man are radically different people with different needs. Creating one editor that they both find intuitive and capable is an impossible task.

So, all that’s left to ask is: Who is Gutenberg for, then?

At the moment, it’s for three types of people:

1. People who need to assemble a blog post. That’s what I’m using it for right now and what it’s best at.
2. Developers who are going to custom-build almost all their essential blocks.
3. Lay people or low-level freelancers/agencies who want to swap content in a pre-determined theme.

It’s NOT for:

• Beginner web developers who want to learn how to build websites.
• Intermediate web developers who want to build custom websites.
• Advanced web developers who want to build custom websites.
• Most agencies & freelancers (unless they’re committed to building custom blocks).

I want to like it, I really do. As it stands now, though, the only viable way to use the block editor to build a custom site is with third-party tools. Native ain’t cutting it.

What do you think? The comments are open. Sound off!