Even all these years later, I cannot wrap my head around WP's direction with Gutenberg. I think having a first party solution for WYSIWYG editing experience is important for WP going forward to keep folks (read: clients, bloggers, etc) interested in it, and I would much prefer to rely on core functionality than battling Elementor, Divi, Beaver Builder, and etc.
However, I have a list of a few items that just haven't sat right with me during the post-Gutenberg WordPress world.
1. The way that it saves the HTML output from React blocks directly to the DB is a cumbersome and unfriendly approach for all. Having a client ask for what would have been a simple tweak pre-Gutenberg and having to resave every page on the site so the deprecation pathway can "update" the block is not friendly to developers or editors. I know you can use PHP (aka "dynamic") blocks, but then you're duplicating the same exact UI between React and PHP and have to take on the technical debt to make sure to keep that in sync. We've moved to relying on ACF Blocks instead of React blocks for most things due to it having a better developer experience and a lot of our clients being used to how ACF works, but obviously this comes at the expense of the fancy inline editing that was the whole "wow!" factor of Gutenberg.
2. The documentation was lacking at launch, and it still feels that way sometimes. It was really aggravating to try to figure out what exactly you could change and remove in core blocks. I remember a coworker and I trying to reverse engineer their columns block since there were a lot of missing features we wanted and realizing that a very, very core block to the Gutenberg experience was utilizing functions marked as experimental without much documentation about what they were or why they were experimental (that we could find). I remember doing our usual upgrade on a new version year after we finally built our own version based off theirs, and the editor completely broke in one of the upgrades (can't remember if it was a major or minor release). Turns out those imports weren't experimental anymore (and no hard feelings on us having to update our imports. We knew we'd need to, it was just the length of time that passed that was "scary", because it doesn't feel great that the core backbone of your site is experimental, haha!).
3. Full site editing being rolled out has felt like Gutenberg's launch all over again. I think #2 is partially responsible for this, but I've watched coworkers have to fight with this a ton for very little benefit, and in some cases those folks end up just saying "hey, you know what instead of trying to rely on their new/weird templates, we'll just add header/footer.php back." This may be less of a problem of Gutenberg itself, but more just a continuation of the lack of decision making and planning that lead to Gutenberg's flaky launch to begin with. Like Gutenberg itself, it's a good idea, but launching it half-baked to just get it out the door makes me hesitate to want to incorporate it until years have passed. My experience has been somewhat limited with their FSE implementation since I've been doing a lot of NextJS work lately, but what little I've dabbled in it wasn't going to have me giving them glowing reviews.
4. It feels like they reinvented the wheel to "do" React SSR in PHP since they save React output directly to the DB. Sometimes I wonder if they wanted to actually have Gutenberg be a standalone project, move to Node, and do real server side rendered React, but were afraid of the very real pushback a move like that would cause and the loss of decades of plugins and backwards compatibility. I know we're toying around with the idea of headless WP + Next since it would hopefully get around the poor pathway for updating React components, but at that point we wonder is WP really what we want to go with or would another CMS be better for our needs.
All that said (didn't mean to rant so much!), I agree with what lenova said a few comments over that Matt has always appeared like a decent person from afar, and I've always respected that he's a web titan (in my eyes, at least), but doesn't come across with the same high and mighty attitude and harshness that a lot of other folks in a position of status like his do.
Fantastic summary of Gutenberg’s mistakes. They also completely missed the Headless CMS movement when they designed Gutenberg this way.
Having said all of that, we use Headless WordPress for many many client projects and have got it working really well for us. For us it’s much better than Sanity, Craft and Prismic. The WP-GQL plugin and ACF are really amazing.
Nice, that's good to hear! I've been using Contentful which has felt super familiar to editors and devs alike, but does have some pain points, such as the lack of ACF-like repeaters (IMO the relationship fields don't stack up as well for what we normally do for clients), the never-ending modal rabbit holes you go down to edit nested content (page -> section -> component -> image wrapper -> image, all because you can't force alt text on their default media uploads, and that was their suggested method of getting around it!).
However, I have a list of a few items that just haven't sat right with me during the post-Gutenberg WordPress world.
1. The way that it saves the HTML output from React blocks directly to the DB is a cumbersome and unfriendly approach for all. Having a client ask for what would have been a simple tweak pre-Gutenberg and having to resave every page on the site so the deprecation pathway can "update" the block is not friendly to developers or editors. I know you can use PHP (aka "dynamic") blocks, but then you're duplicating the same exact UI between React and PHP and have to take on the technical debt to make sure to keep that in sync. We've moved to relying on ACF Blocks instead of React blocks for most things due to it having a better developer experience and a lot of our clients being used to how ACF works, but obviously this comes at the expense of the fancy inline editing that was the whole "wow!" factor of Gutenberg.
2. The documentation was lacking at launch, and it still feels that way sometimes. It was really aggravating to try to figure out what exactly you could change and remove in core blocks. I remember a coworker and I trying to reverse engineer their columns block since there were a lot of missing features we wanted and realizing that a very, very core block to the Gutenberg experience was utilizing functions marked as experimental without much documentation about what they were or why they were experimental (that we could find). I remember doing our usual upgrade on a new version year after we finally built our own version based off theirs, and the editor completely broke in one of the upgrades (can't remember if it was a major or minor release). Turns out those imports weren't experimental anymore (and no hard feelings on us having to update our imports. We knew we'd need to, it was just the length of time that passed that was "scary", because it doesn't feel great that the core backbone of your site is experimental, haha!).
3. Full site editing being rolled out has felt like Gutenberg's launch all over again. I think #2 is partially responsible for this, but I've watched coworkers have to fight with this a ton for very little benefit, and in some cases those folks end up just saying "hey, you know what instead of trying to rely on their new/weird templates, we'll just add header/footer.php back." This may be less of a problem of Gutenberg itself, but more just a continuation of the lack of decision making and planning that lead to Gutenberg's flaky launch to begin with. Like Gutenberg itself, it's a good idea, but launching it half-baked to just get it out the door makes me hesitate to want to incorporate it until years have passed. My experience has been somewhat limited with their FSE implementation since I've been doing a lot of NextJS work lately, but what little I've dabbled in it wasn't going to have me giving them glowing reviews.
4. It feels like they reinvented the wheel to "do" React SSR in PHP since they save React output directly to the DB. Sometimes I wonder if they wanted to actually have Gutenberg be a standalone project, move to Node, and do real server side rendered React, but were afraid of the very real pushback a move like that would cause and the loss of decades of plugins and backwards compatibility. I know we're toying around with the idea of headless WP + Next since it would hopefully get around the poor pathway for updating React components, but at that point we wonder is WP really what we want to go with or would another CMS be better for our needs.
All that said (didn't mean to rant so much!), I agree with what lenova said a few comments over that Matt has always appeared like a decent person from afar, and I've always respected that he's a web titan (in my eyes, at least), but doesn't come across with the same high and mighty attitude and harshness that a lot of other folks in a position of status like his do.