> If the first thing thousands of users do after installing WordPress is to pay for a page builder plugin to be able to work with their content in the way they want, that's a problem

Or, it's an opportunity. Look at Shopify - is it a problem that the first thing a new Shopify user does is to head to the Shopify app store to buy and install a handful of plugins?

Completely agree that access to plugins is a huge plus. Except if a very large number of Shopify users start to install the same plugin or plugin type, and you start to see articles titled "60 of the best [page builder|digital download] plugins for [WordPress|Shopify]", and you field daily support requests asking, "which page builder plugin should I use?", and users actively avoid an existing feature in your service to use a third-party add-on that does the same thing your feature was doing only better. At that point it's a great candidate for a core product feature or enhancement, as has been the case with Gutenberg.

Also worth noting there is no official WordPress.org paid plugin store and paid plugins are typically not hosted services as with Shopify.

The average experience WordPress users get when shopping for, maintaining, and getting support for plugins is much less smooth than a hosted platform like Shopify. (There are great WP plugin developers and terrible Shopify ones too, but fewer of the former than the latter.)

I think you've missed the point a bit. I'm trying to make a distinction between what is driving Gutenberg and what it's trying to solve and why. Improving the editing experience is a valid justification - of course - but it's not happening because users are demanding it or because their problems are not being met already. It's primarily vehicle for accomplishing other goals, i.e. improving .com's competitive offering and managing the transition to a JS centric code base. Those things are more important.

Understanding the priorities in play explains in part why Gutenberg is causing friction better than saying it exists because it is trying to solve technical problems for users. That would lead you to think that the technical problems were thought about really hard and that is some primary goal. It's not. It's just WordPress trying to modernise an interface.

> You can style the editor with CSS, and re-use much of your front-end theme styles in the editor stylesheet via Sass.

The reason I bring up the editor and WYSIWYG is that it shows the disconnect between some lauded goal of providing a more seamless experience and the thought that went into the technical solution. My feeling is that we ended up where we are not because we were trying to solve a problem in the best way, but because we were just trying to cram in a new JS way of doing things. It explains better how we arrive at the following mess. Let me show you it through the lens of styling a post:

https://imgur.com/a/AThzNns

> The “mess” in editing mode is needed to help people style their content more intuitively; you can't have a WYSYIWYG web UI without adapting the page content with scaffolding to enable styling controls.

Look at the gallery I posted and tell me honestly, are you really saying this is the only way to provide 'intuitive editing'? Of course that is not true, it's simply how Gutenberg decided to implement it. Of course, you can compose your CSS workflow to fit around how Gutenberg's editor functions and you'll get fairly good results if you do. But this is a workaround, it's made the UI a first class citizen at the expense of the rest. So theme developers have to think in terms of the UI, not just what the markup looks like on the front-end. And content creators are forced to think in terms of blocks. It's an UI that is altering how people interact with it, for its own sake.

Thanks for taking the time to make those screenshots.

To me they reveal a couple of misconceptions:

1. That a WYSIWYG should provide a pixel perfect like-for-like view of the front end on the back end.

As you mention, the theme you chose doesn't have full Gutenberg styling, so front and back end differences are more pronounced. But even themes that have good integration will display differences, because the back-end cannot perfectly model the front if users are going to do more than manipulate data inside it (i.e. change styling).

I do agree that there are other ways to provide more intuitive editing (like in-place editing), but they are not without downsides too. In-browser editing is a compromise and balancing act.

2. That the structural blocks around visual elements on the back end designed to enable UI elements and controls interfere with styling by theme developers in some way.

That was definitely my experience at first (I've just spent three months updating several themes for use with Gutenberg), but it isn't now that Gutenberg has evolved and I better understand how editor styling works. In short:

- You enqueue your editor styles after calling add_theme_support( 'editor-styles' ); with add_editor_style( 'style-editor.css' );

- You can then copy the bulk of your styles from the front end to that stylesheet (with a few exceptions, such as the post title, which do need editor-specific wraps at present).

- Gutenberg/WP 5.0 prepends those styles with a block-specific selector when you view the Gutenberg editor so that you don't need to worry about the “soup of UI markup”, as you put it.

- You can automate much of the CSS re-use using Sass, like the Twenty Nineteen theme is doing.

Theme developers need not think about the extra wraps unless they are developing custom blocks, and even then it's largely abstracted away for them by the JS API.

I would much rather have editor styling handled automatically by Gutenberg, and I think it will get there, but for the moment this is a small stepping stone on that path.

The UI does interfere, you, as a theme developer, have to adjust to it, as do content creators. This is getting to the point I'm trying to make, that the project wasn't invoked to solve technical problems. It's not answering to technical problems but to the motivations of the project leader.

You bring up how Gutenberg solves some of the issues it creates, i.e. how theme developers supply editor styles to match what is seen in the front-end. Until recently Gutenberg didn't even prepend block specific selectors, it was even more broken than now. Why did it even start out that way? How is that even possible to have Gutenberg develop that far without properly thinking about how to style for it? Why is it this solution patched on? (same can be said for meta fields, accessibility and so forth). Because the project didn't start with a clear idea of the technical problems it wasn't going to have to solve, it wasn't a priority.

So, for theme developers Gutenberg is more labour intensive (though it can be rewarding). It wouldn't need to be more labour intensive had it started with the full breadth of priorities in mind at the very start. You say 'you don't need to worry about the soup of UI markup, but you do. You have to work around the quirks of the editor or constrain yourself. Say you want to target every 2nd heading, or the paragraph after a blockquote, you can't do that elegantly, because the markup is different in the editor as it is in the front-end and it's not solved by prepending block selectors. Gutenbergs editor styles solution isn't elegant either. It is not a complete disaster, but it's indicative of the fact that the project is imposing its own paradigm over the problems its trying to solve. It's literally creating new problems to solve.

> they are not without downsides too. In-browser editing is a compromise and balancing act.

I'm not convinced at all that a different approach to how the UI manifests itself in the DOM would have entailed any meaningful trade offs at all. I've been working with this prosemirror implementation recently and the basic example pretty much matches my demo posted earlier: https://tiptap.scrumpy.io/

+1 I can concede that there are likely better technical implementations than where Gutenberg is at now. (Ghost's Koenig editor with the open block/card model is great, if much simpler and cutting corners by lacking Edge browser support and the ability to add custom cards.)

WordPress has always been a project where user happiness outweighs developer happiness, though, as much as I'd love for it to at least bring developer happiness inline. It will be interesting to see what the overall reaction is when 5.0 lands and the editor starts to become more widely used and accepted.

Yes and I'll concede that Gutenberg has a lot of room to grow and will even make plenty of people happy straight away. But I wouldn't call this about user happiness outweighing developer happiness, I'd say it's the other way around. It's based on asserting that we know what the future user wants, not the actual users. Right now user happiness is skewing negative.

And Gutenberg's development is precisely characterised by developers/designers prioritising their own happiness. It's a small group of people working mostly at agencies and companies doing enterprise level work who took Matt's idea around blocks and feverishly adopted the tools they personally wanted to use while developing and making decisions at a pace more rapid than other contributors could cope with. That is in part why we lost the accessibility lead.

Just wanted to clarify one thing, that “we lost the accessibility lead.” There were no accessibility leads until one was designated for the 5.0 release. There were three self-appointed accessibility team reps, one of which decided to step back from the group and blog about it. “Team rep” is largely an administrative role, and as I said before it’s self-appointed. Some teams have 5+ reps, and historically they have not been approved by anyone in WordPress leadership, nor do they connote authority or skill.

> Improving the editing experience is a valid justification - of course - but it's not happening because users are demanding it or because their problems are not being met already.

What's the difference between "compete on more level terms with the state of hosted solutions like WIX, Weebly, Squarespace who offer increasingly simple visual building experiences" and "solve problems for users". If there is something that is making people choose WIX/Weebly/Squarespace, isn't that something precisely: a problem that those things solve and default wordpress (currently) doesn't?

Because it's a case of a for-profit company competing for paying customers of other hosted platforms. Most WordPress sites don't have that competition, they run the self-hosted version and they are already well served by 3rd party solutions for their more complex needs. So now the community project is trying to prioritise the goals of the for-profit company at the expense of carefully developing solutions to meet its own users in a proportionate way. That's how we've ended up thinking of accessibility/custom fields/theme development/backward compatibility as things that are secondary priorities, if that.

The vast majority of revenue in the WordPress ecosystem is made by hosts other than WP.com. Everyone in the WP ecosystem benefits from increased usage, as it drives more plugins, more themes, more demand for agencies and developers, more books and tutorials about WordPress, et al. It’s all part of the virtuous cycle that has led to WP’s success so far. I’d be far more worried about the WP ecosystem if it started getting smaller and the various constituents were fighting over a shrinking pie.

For clarity, I'm not trying to make the suggestion this is about the pursuit of revenue, because I don't think that at all. My impression is that this is about survival and growth.

I've long emphasised the symbiotic relationship .org has with Automattic in positive terms. Up until fairly recently I would say this relationship was almost wholly to the benefit of the overall project. My impression is that WP.com under your leadership is now behaving more like other conventional tech companies - it's preoccupied with growth. That preoccupation with growth by implication operates in the context of wp.com competing with other commercial companies who compete for the same customers.

When I look at the success of WordPress through the years, I'm seeing growth arriving as a side effect, not as a specific end unto itself. Decisions were made because wrong or right, they seemed like a better, more powerful way to do things. When it becomes about growth, other things become a little less important. Through the lens of the need for growth, options are judged to the degree to which they are vehicles for further growth. Unfortunately this also leads to relaxing other principles that should be central to WordPress.

Before React changed its license, it had already heavily adopted for Gutenberg and Calypso and you had been poised to bless it had there not been so much turbulence. It was adopted because it had been the fastest way to move forward. The same militant zeal that was applied to 3rd party developers using non-GPL licenses was not applied to the adoption of React, because React was a useful tool in the pursuit of growth. Of course, you can say, but it's now a success story because I've no doubt that FB's change of license was influenced by WP. Community consensus was however a second order issue, as was the original licensing, what matters was what would make the people working for you happiest and most productive in the short term. (Credit to you, you were willing to abandon React at one point, that must be noted)

WordPress will soon be adopting AMP in core, given your support. Again, immediate growth will be the primary reason this happens, because AMP is the fastest way to cut down on bloat that is holding back performance for mobile users and users on slow connections. It's a shortcut, it's a shiny looking vehicle to continued growth, delivered on a plate by some of the worlds best engineers. This decision won't be made based on community consensus or a discerning look at whether it's good for the open web, or what other options there are. It will be stressed that AMP is developing web standards and is an open source initiative with many other players that have bought in, saving the web and helping poor users.

Because growth is the imperative, things that hinder growth are treated with the same baseline hostility as red tape is to businesses. Accessibility and privacy are inconvenient obstacles that ultimately need to take a backseat to building forward momentum, rather then the very means with which to democratise publishing and development.

Because growth is front and center, artificial time pressure needs to be created with which to force the issues. And like a conventional tech company that has grown into a monopoly, it starts to take advantage of its privileged position. It becomes aware of its own latitude, like now the ability to introduce a degree of breakage and concentrate all core development on the delivery of a flagship feature.

I'm seeing this and I'm thinking, many of the decisions that are being made are at best following the letter of stated principles, but not the spirit. Each decision can be somewhat rationalised and the pretense can be offered that it's in the interest of increasing the pie for everyone, or to reaching more users, general survival and for spreading OSS practices even further.

What I'm seeing is a web of monopolies that are interacting in such a way that their influence continues to grow. To have the web shaped by a few select players is not good at all, and I certainly haven't worked with WordPress all these years because I care about market share. I was motivated by the degree to which WordPress empowers people, how it brings people together and champions freedoms as well as its role in keeping the web open and independent. Now it's a slave to growth, nakedly pursuing monopoly status, boosting the role of problematic monopolies elsewhere while selectively applying its stated principles.

I have enormous, genuine respect for people working on WordPress, including you and the many people that work at Automattic and elsewhere. I believe strongly that every single person involved is working with the best intentions in mind. But the prioritisation of growth has corrupted the character of the project, and I can't express in words just how sad that makes me.

I completely agree that growth is a result, not a goal in and of itself. Fundamentally it represents what people, given the open market of all possible solutions to their problems, choose. We want to create the best software experience because that will help people choose Open Source vs proprietary solutions, which even if they don't appreciate it at the time will be better for them and the web overall in the long term.

Thank you for recognizing we were willing to walk away from React because of the license. It was chosen because of technical merit originally, but was a day or two away from delaying the entire project 6+ months to refactor.

AMP is interesting but no decision has been made there yet.

Thank you for sharing your thoughts and a generally excellent comment.

> Because it's a case of a for-profit company competing for paying customers of other hosted platforms. Most WordPress sites don't have that competition

So free users don't want the features that paying users want? Whyever not? Surely the fact that some people are willing to pay for a particular feature indicates just how important that feature is to a lot of users.

If that were true, why are so many existing users apprehensive about Gutenberg? Self-hosted users of WordPress have different priorities even if most would like a nicer editor, it matters how it comes about and it matters what other sacrifices are made in pursuit of the project.

Many users have legitimate concerns about Gutenberg (compatibility with existing plugins, suitability for ongoing plugin development, migration of existing instances). That's a very different statement from saying that it doesn't solve a real problem that many users have.