**TLDR:** Gutenberg is broken by design and there’s no good way to fix it. It’s a good option for simple projects, but once they get bigger it makes sense to use something different.
===================
I was thinking this way back in 2018 with the WordPress 5.0 release and haven’t changed my opinion since then. It’s a complicated way to solve simple problems. And let me explain why.
Gutenberg has a few fundamental problems. The first and most crucial issue is mixing blocks and simple elements in one context. It ruins the whole concept of the block editor and makes it useless for something more complicated than a simple article or post grid.
Why is this so important? Let’s start with the basics. Every page may consist of independent blocks. Each block is a wrapper for content (images, text, posts, etc.), with settings like margins, paddings, background, etc., defining how the content is displayed.
I use this approach in all my projects. Other page builders like Elementor or WPBakery are leveraging similar ideas. But what’s wrong with Gutenberg? It also has something called blocks with settings, content, etc.
The answer is not apparent. There is one main requirement to make block editors work: a page should contain only blocks. Gutenberg allows inserting simple elements like paragraphs or images without a block wrapper.
As a result, each simple element may break the layout. Fixing those issues on particular pages is possible, but it makes a block dependent on a page and creates many other potential problems. Moreover, it destroys the whole idea of using blocks.
Unfortunately, this fundamental issue can’t be solved because of the second problem: how the data is stored. For some reason, Gutenberg stores all the elements in page content with special comments handling settings and data.
It’s not new; many page builders use the same approach, but with a crucial difference: they use shortcodes or store the information about blocks in meta fields. It splits the data from its presentation and allows changing how it’s rendered.
This approach dramatically simplifies development. For example, if a block is independent, renders the content in one place, and uses styles with a unique namespace, you can change it in one place and be confident that other parts of the site won’t break.
In the case of Gutenberg, you have to change the content. I.e., you need to load all the posts, pages, etc., using blocks, parse the blocks using parse\_blocks(), then find the block you want to change, make changes, render all the blocks, and save it.
At every stage, you may have some exceptions and issues because the data in the editor might not be consistent. Also, there’s no guarantee that a page does not contain specific workarounds to handle some edge cases (larger margin for a paragraph, for example).
Ultimately, you need to check every page on the site and spend more time fixing issues. It’s terrible in terms of project support and development. That’s why we see messages about issues after WordPress updates. Unfortunately, there are other issues with Gutenberg.
Gutenberg has a very steep learning curve. You need to learn JS, React, spend time setting up the environment and ultimately can end up rendering the same template using JSX and PHP. Adding a custom setting to a block is exceedingly complex: [https://awhitepixel.com/blog/add-custom-settings-to-existing-wordpress-gutenberg-blocks/](https://awhitepixel.com/blog/add-custom-settings-to-existing-wordpress-gutenberg-blocks/)
Yes, some tools like ACF Blocks are simplifying this process, but why? You can spend less time creating custom widgets in Elementor using only PHP and a decent API ([https://developers.elementor.com/docs/widgets/add-new-widget/](https://developers.elementor.com/docs/widgets/add-new-widget/)). My only question is, why should we solve issues those issues?
I don’t mention other weird Gutenberg restrictions like the lacking term page support and missing margin and padding settings for some blocks. That’s not acceptable. As a result, Gutenberg is not widespread. Classic Editor is one of the most popular extensions.
I think, Gutenberg is a viable option for simple blogs, but from my perspective Automattic and the WordPress team made a mistake by including it to the core.
It would be better to keep it as a plugin.
I kind of agree with you and at the same time I kinda disagree. I’m torn because it isn’t anywhere as easy to make a block as acf and php but that because you have to make a rendered version for the backend so it’s shows up rather than being a bunch of boring fields, ala acf, which makes it super simple for the user.
I love that, learning how to render the block is interesting to me, and saving the whole block as attributes in Json as a single field saves so much time on database calls and saving that Gutenberg is way way faster than anything else.
I personally had to make my own block which had two options, full width and container, that then only used the columns block inside it, which then had every other block inside those. This works great but I agree its a nightmare with css. Using a package manager to incorporate tailwind into my plugin worked but I can attest that the documentation on css on blocks is a nightmare.