People really do not care whether they are react components or not - but they do care if it is difficult to just type in a paragraph.
Gutenberg does have potential, but they empowered widgets while making the core act of typing up a document more difficult. If they fix that, it has potential.
Arguing that the most popular content management platform (ever) should just stick to plain text and shortcodes is not really sustainable.
You can just type paragraphs, without any clicking. And before, you couldn't just "wrap a paragraph" around a widget, really ever; shortcodes broke stuff like that routinely.
(They are still improving cross-block text selection -- at the moment if you select from one block to another, both blocks select completely. But there's a solution to this that is very imminent)
I also saw a lot of potential in Gutenberg’s blocks back then. It changed our blogging workflow in some very elegant ways.
Website builder products and theme developers will wish they had a way to unionize once it happens because there is a lot of potential for the Automattic team to just take over that business themselves. And I wouldn't be surprised if it has come up in discussions, too.
This is an oddly hostile take about one of the best corporate citizens the web has, IMO.
There is an open question about what happens to the theme market generally once truly block-configurable themes exist (how many themes are necessary, really?) but pivoting that into some evil empire fantasy about Automattic -- a business that rescued Tumblr, that bought Simplenote to run it for free forever without ads simply because Matt Mullenweg depends on it -- seems a little odd.
Which is why I said it will take a long time, but it is heading in that direction.
They already released Patterns[0], which is very tiny inside look on where they plan to go with Gutenberg. Yeah, they might look cheap and not so attractive, but ultimately the ability to customize "blocks" is already there - it's just a matter of time before the capabilities of that customizer get cranked up to the max.
But -- considering patterns can be used by every third party theme in an open source CMS -- how do you get to talking about developers unionizing (that is, under threat from some corporate entity) and Automattic taking over that business from there?
The reason I read it like a corporate big bad wolf fantasy is that you wrote it like one.
I think because WordPress.org is heading into a direction of being a website builder itself, it will naturally hurt developers/businesses who make their living off of it.
Yeah, cool and exciting designs might still have a market, but for blogs, magazine sites, portfolios - that ~$50 for a premium theme might be better spent elsewhere.
I don't know if you're familiar with Webflow[0], but it started out as yet another website builder. And, in recent years they have added so many features and layout templates that I once got confused seeing the "Made with Webflow" badge on a landing page. It had all modern features like smooth page transitions, svg animations, cool gallery effects, etc,. You know, the things people pay that $50 for.
If this happens, or rather when it happens, maybe Automattic will have to think hard about what it wants the future to look like.
[0]: https://webflow.com/
And I must say, even though I have developed themes in the past, I'd prefer to see Gutenberg succeed in making most themes irrelevant. Themes that can be customised without PHP entirely seem to me to be a good solution to a lot of people's complaints about the untidy boundary between plugins and themes.
I am only familiar with Webflow from people who say "I've been trying to do this in Webflow but I'd prefer if we could do it in Wordpress".
Which is exactly the problem. Many people don't want to have heavy React ecosystem stuff on their Wordpress instance. There are reasons why they have not jumped on that train before.
This is how I see it.
I'm not sure why people believe there aren't smart people working on Gutenberg, which is an obviously challenging transitional strategy from blobs-of-HTML-in-a-database to a modern layout tool.
It's forward-looking, decade-scale development. There are loads of challenges.
Gutenberg has doubled down on blobs of HTML in the database: everything within `<body>` is stored as one big blob if using "full site editing", including additional markup defined using HTML comments. There is far less separation between data and how it's presented than there ever was with the "classic" editor.
This is not correct, surely?
Yes, if you're using FSE you're getting a template from that which is more or less a page. FSE replaces the header/footer/sidebar/widget area thing with an editable scheme.
That is, on one level, a big chunk of HTML -- but it is stored as a block graph (see below). And as far as I am aware the work has been done to allow it to produce HTML5 semantic tags?
There is an insertion point in the FSE template for content from hooks or the loop, which may or may not be returning block graphs. Post content can also now contain loops as created by query blocks, etc.
And yeah, Gutenberg stores as HTML internally.
But the distinction I am drawing here still holds.
The classic model was a blob of post content that was minimally post-processed to expand shortcodes. It didn't attempt to understand the HTML except in a minimal way to figure out if a shortcode should end up in a wrapper tag.
The rest of it was sent straight out into the page (after autop). TinyMCE then tried to deal with it, and had to recognise shortcode patterns. That is what I mean by a "blob": most HTML was handled in an unthinking, unprocessed manner. As text.
In the Gutenberg era they still do store HTML in post_content (for good reason) but it is in a form that can be serialised and deserialised into blocks -- it is not simply markup; it's a complete serialisation format.
https://make.wordpress.org/core/2017/01/17/editor-technical-...
https://developer.wordpress.org/block-editor/explanations/ar...
And unlike in the Classic Editor era where the HTML is handed to TinyMCE for it to sort out, and then sent back and stored as whatever it submitted (minimally filtered), WP can now serialise and deserialise that information as a block graph in both PHP and JS, and there are hooks at both sides.
Yes -- the stored content can be rendered in its frozen form (and will be, by any theme that doesn't know about blocks).
But it can be processed as a block graph instead.
So in fact the data is being stored in a much more semantically accessible way; not only dumb HTML processed with what amounts to regexps.
The fact that it's _also_ effectively HTML in post_content rather than, say, JSON in a new column is a design decision to maximise compatibility.