Why is the WordPress Block code so verbose and inefficient?

Hi @kittenchief117. These are good questions and there’s a big answer to them; here’s a not-so-brief summary.

The most important part to understanding this is probably that WordPress is trying to build an open and extensible system. Most of the decisions related to the way content is stored is directly working to one of those two goals.

more brief and concise code means: faster to write, less network bytes consumed, efficient browser parsing/rendering/reflow performance, easier to read/maintain, more productivity, and better Developer Experience (DX).

WordPress posts tend to perform quite well in rendered pages and there’s been a fair amount of care built into the editor in order to produce semantic and efficient HTML. One part to note is that the content stored in a post is not the same content delivered to the browser. In any case, the extra metadata stored with each block is rather minor, and a single image upload to a site might outweigh the total of all the additional data surrounding blocks.

Those HTML comments provide a very fast way to parse the blocks out of a post and to isolate them for processing on page render without requiring the use of more opaque data structures like a proprietary JSON format. They provide for sufficient functionality when rendered as an HTML file without any server while communicating the higher-level attributes which define what any given block is and means.

For a deeper dive into this question, you can read more in an article I wrote many years ago now.

Many styles are duplicated first in the WP block comment, and then in the actual tag itself. Why? Can’t we just write Tailwind-like styles…Why not use that instead of?"orientation":"vertical"?

Duplication should be kept at a minimum, but if you look carefully at the example you posted you will see that there are minor differences. A Block represents a kind of rich media and its attributes define the parameters which define that particular bit. An image block’s url attribute indicates where to find an image file, but the HTML that’s rendered for that block could be one of many different HTML constructions depending on things like whether there are different sizes available for display, whether there’s a caption, whether there are artistic choices being made based on the screen size. Styling is similar in that there are concepts being defined at a higher lever than raw CSS. There’s a close correspondence, but CSS becomes a way to express the higher-level style kind. Therefore most block’s have attributes indicating the intentional styles while the HTML inside a block contains the realization of that style with CSS.

It’s common when developing blocks to add CSS late during render and to do that based on the block attribute or based on some other information available to the server when rendering a page. If you examine the rendered page you will note, for instance, that most blocks contain a number of additional classes which aren’t stored with the block in the editor or in the database. WordPress provides the render_block filter to modify the HTML when sending a page to a browser.

Also, more complicated styles not supported by the WP editor…have to be added to Blocks with CSS class names I think, which are then harder for normal users to identify and remove one if they want to.

If you find that you are adding things routinely to many blocks then you might look into that render_block filter and see if it’s something that you can provide dynamically.

Many of the style systems are designed to work together with Global Styles and block supports that give people the ability to adjust the layout or visual styling of a block or page without resorting to code or CSS. This is also one of the reasons it’s hard to rely entirely on CSS, because the WordPress concepts often transcend an individual block in a post or an individual setting.

Everything being built is done in the open and in a spirit of cooperation and invitation. If you experience specific problems or want to share an idea for how to do things differently, you can interact on the Issues page for Gutenberg (the name of the editor).

Thanks for asking!

Hi @dmsnell,

Thank you for taking the time to write the detailed response! I appreciate it.

I understand and agree with you for the most part. I guess I’m used to having a modern JS dev environment with automatic type-checking, completions, linting, prettifying, highlighting, and many other dev-friendly features, that developing on WordPress still seems a bit cumbersome.

Regarding point #1: Yes, you’re right that other assets will be much larger than the block code, but those assets can also often be lazy-loaded separately and aren’t as critical for UX and Core Web Vitals (FCP, first-byte) as the initial HTML page, which loads the main content the user is interested in.

But even more importantly, it takes much longer to write the code! I love utility-style class names for how quickly and efficiently you can build layouts, and I wish WP had them too (side note: for my sanity I might even write a script that takes my Tailwind HTML code and auto-converts it to WP block code wherever possible!)

Of course, if a block has a property that isn’t directly correlated/mapped to a class name or CSS style, it can go in the block comment (or perhaps a better structure as the block comment JSON isn’t easily prettified, autocompleted, or syntax highlighted by code editors).

But I believe the majority of the styles are duplicated, which can add unnecessary confusion, extra learning curve, weird bugs, and more things to remember, especially because of the non-standard naming schemes.

I’ll also try looking into other editors like Elementor and Divi to see how things are.

But either way, thank you again for the answers. Have a great day Dennis…

Yes, you’re right that other assets will be much larger than the block code, but those assets can also often be lazy-loaded separately and aren’t as critical for UX and Core Web Vitals (FCP, first-byte) as the initial HTML page, which loads the main content the user is interested in.

In review I could have been clearer in stressing that this duplication isn’t present on the rendered page. The HTML comments and their JSON attributes are stripped away when rendering, styles are merged, and for some blocks the entire content is swapped out when building an actual page.

What I was trying to convey was that in terms of the delivered page, WordPress and its block content performs quite well. Here’s a 2021 article discussing how block posts score high in the browser for performance and for mobile accessibility.

But even more importantly, it takes much longer to write the code! I love utility-style class names for how quickly and efficiently you can build layouts, and I wish WP had them too (side note: for my sanity I might even write a script that takes my Tailwind HTML code and auto-converts it to WP block code wherever possible!)

It’s easy to sympathize with this, but the systems are different and you may find that there are also alternative ways to develop that eliminate that coding altogether.

For instance, if you haven’t explored them, check out Block Patterns. The combination of creating a block pattern and using the Group Block effectively can be a quick way to build reusable micro-layouts in your posts, and that doesn’t involve any code at all. The benefits of the ecosystem come with it too; for example, when building columns there’s an option to check that transforms columns into a vertical list of each column on mobile displays so that it avoids awkward horizontal scrolling.

thank you again for the answers. Have a great day

Glad to try and clarify! You have a great day as well.

Yeah, I have been looking into Block Patterns.

Though, at least personally, I find it much faster to edit the raw code in my code editor (with all the advanced editing capabilities) versus changing things in the UI, but I’ll look into it more.

Thank you for all the suggestions and help!