In reply to David Vongries.

Indeed. I see the flawed thinking on both sides with the block editor or page builders. Have to say though, and I am not shy of saying this, the indictment lies a little more on the Gutenberg teams’s side of things for many reasons. Some mistakes have been made on the way:

• Forcing the block editor as default too soon and, having to install the Classic Editor plugin, or some other method to disable Gutenberg was cumbersome. In fact a simple line of code kills the block editor if that is what you want.

• Setting up the new editor, then quickly moving onto FSE, before addressing some quirks and use cases where the block editor doesn’t cut it, a bit shady in my opinion. Data entry, as a purely custom field experience with templates on the front end comes to mind.

•  In relation to the above, where the Classic Editor is touted to be removed soon, where is the block editor UI version of WooCommerce Products in the backend? Strange when WooCommerce is an Automattic plugin? As it is clients with eCommerce sites are presented with a mixed UI environment because of this.

• Lastly, the block editor should have bee provisioned with a restricted set of blocks for typography and layout/structure, as in sections/containers, rows and columns. Third parties should not be allowed to produce any other versions of these and instead an API should have been created to allow third party plugins and page builders to override these blocks to add their own bells and whistles and fancy UI. Turn off the plugin/page builder or switch to another and at least the content and layout would be left in a reasonable state. Instead we have way too many variations on a theme with a smorgasbord of block offerings.

Taking all off the above, if tackled, I would say that all page builders would be crazy not to re-invent themselves with a block based foundation.

As it is, I reckon that many of the smart vendors of page builders will do this anyway. They haven’t gone away you know.