A Discussion With Gutenberg Project Lead Matías Ventura on the Barrier to Entry

Last week, I published an opinion piece on the barrier to entry in the modern WordPress era. The article followed a tweet and post by Chris Wiegman that stated the current learning curve was extremely high, regardless of past experience. Members of the community responded with a flurry of articles, podcasts, and videos.

Because modern WordPress is primarily centered on Gutenberg, I reached out to the project’s lead, Matías Ventura. The goal was to bring some balance to the discussion. Unfortunately, he could not get back to me until a few days after the story was published. However, given his unique insight and perspective on the project, his views should be shared.

In our discussion, we covered the topic of the barrier to entry from multiple viewpoints. Depending on where a specific developer, designer, or user steps onto the ramp, each will have a different experience.

Why Are We Having the Same Discussions?

The block editor shipped with WordPress 5.0 in December 2018. We are closing in on three years, but it often feels like we are having the same discussions. One has to wonder why we have not yet moved beyond that point.

“I think this is a case of the size of the WordPress community, its diversity of perspectives, and the fact that we do still have a lot of work to do to continue to make things accessible,” said Ventura. “I’ve seen people that start with no prior WP knowledge get flying super quickly.”

He recounted one story of a popular block library that launched last year. The creators were designers but did not recognize themselves as developers. However, the APIs allowed them to build an entire plugin that would not have been possible with their previous skillset.

“To me, this was a triumph of the block APIs that are available for builders,” said Ventura. “But this is just one person’s perspective. It doesn’t invalidate PHP developers expressing frustration at the complexities of modern front-end tools.”

Theme Creation and New Onramps

On the theme creation front, we were in agreement. There are new ways (and more on the way) for non-developers to ease into visually building various parts of a website without needing the entire weight of theme development knowledge.

Ventura began his WordPress journey with theme development after first being exposed to Flash in the early 2000s. He recalled downloading a bunch of PHP files and thought he could execute by opening them. It is safe to say that he has learned a lot since then.

“Being able to edit pieces of a theme is a crucial aspect of democratizing access to code,” he said. “I think we are going to be seeing a lot of people get started by diving into how templates work. Or by playing with the Query block, which used to be a hidden piece unless you knew a bit of PHP already.”

He mentioned that, in some ways, this aspect of the block editor allowed solo creators or small teams to build unique projects, pointing to Aino as an example.

“I’m seeing a ton of designers for whom contributing to WordPress was difficult or a gated experience,” he said. “There’s a lot of developer entitlement when we say things used to be easy. They were not easy for a large chunk of the population that might have been excellent contributors if there were more avenues to contribute.”

Patterns may be the first official stepping stone, one avenue among many that WordPress could facilitate in the future. Ventura envisions a possible .ORG-hosted visual theme builder that would allow users to create and publish without ever touching code. We are likely years from seeing such a project come to fruition, but lofty goals can lead to innovative ideas that we have yet to think of.

Building Block Plugins

Block plugins are a different beast than themes. The barrier is undoubtedly higher, but how big is this hurdle for traditional WordPress developers?

“Going from contributing a pattern to building a block is a big leap right now,” said Ventura. “While there are folks that can learn it quickly, it’s still a big barrier for people. I think there are several layers to this: documentation could be an order of magnitude better in both organization and presentation. I hope we can do a lot more there.”

He is also curious about tools for building blocks, such as a blend of BlockBook and CodePen. He mulled over the possibility of blocks used for creating other blocks, a scenario in which developers might only need to write HTML with the tool interpreting features like Rich Text fields. At the very least, he believes we are barely scratching the surface of what the block-building experience could be.

“The biggest challenge is that there’s a tendency in PHP trained folks to neglect a bit the implications on the UX if it means the developer experience is simpler,” he said. “I think this is most visible in the shortcode/forms approach to UX as opposed to direct manipulation, which is hard to codify from a PHP set of APIs.”

WordPress/Gutenberg Contribution and the Bus Factor

Outside of building themes or plugins, the third and arguably the highest level of participating in the WordPress development ecosystem is direct contributions to the block system. Is contributing to core harder today than it was just a few years ago?

“I think this is a good point, but I think it partially misses that contributing to WP internals like WP_Query was also very difficult,” he said. “We just got used to it. We have received more contributions to Gutenberg from people than what I have seen in Trac in my years there.”

Ventura did admit that GitHub could be a factor in the amount of contribution, which many developers tend to favor over Trac.

While building an editor is a difficult task and requires certain levels of expertise, other parts of the system, such as the component library or smaller packages, might offer alternative paths for some people to get involved.

“Apart from this, I do agree that there’s also a higher level of expectations for what software should be capable of doing these days that make contributing meaningfully a harder task than before,” he said.

Historically, other parts of WordPress that relied on the JavaScript model, such as the media library, have not had high levels of contribution.

“I don’t think this is a topic we’ll exhaust any time soon, and it’s important to not become complacent and just say ‘oh things are just hard’ because an important part of the WP project being open source is that users can modify said software, and for that, they need to understand it,” he said. “I think we can introduce a new generation of people to coding if we do things right and work together more.

The secondary aspect of this is whether there is a bus factor for WordPress. If so, what is the number? This is a common question around the most technically challenging pieces of software. If X number of contributors with the requisite knowledge of the most complex pieces of a project were hit by a bus (sorry for the grim imagery), would the development grind to a halt?

It is not something often discussed in WordPress circles because it has never seemed to be an issue. However, if contributing to core carries too high of a barrier to entry, is there a number where the project cannot continue?

“I think, in some ways, it’s more sustainable now,” said Ventura. “We have been a lot more open with contribution permissions on the Gutenberg repo, and it has resulted in a larger amount of folks contributing. I think we might see a split between contributors that are comfortable with the back-end side of WP and those that are more comfortable with the interactive pieces.”

One thing the team did not entirely anticipate was Gutenberg’s use in projects outside of WordPress. This can add to its sustainability factor. He pointed to the WordPress mobile app being an example where others can meaningfully contribute. And other mobile apps are wanting to use it for their tools. At Automattic, where Ventura is employed, they are also working on adopting editor technologies for Tumblr.

“I think a broader topic of discussion, in general, is that contributing meaningfully to WP has become the privilege of those sponsored to work on it full time,” he said. “I think that’s in some ways natural but also a bit of a tragedy.”

20

20 responses to “A Discussion With Gutenberg Project Lead Matías Ventura on the Barrier to Entry”

  1. This totally ignores the fact that a lot of developers in the WordPress space don’t have the luxury of being employed by a large company that not just encourages, but specifically employs you to work on Gutenberg. A lot of developers work are freelance or small agencies who are having to entirely re-tool and learn complex, ever changing set of APIs (when we’re lucky) which themselves are poorly documented, if at all.

    Gutenberg creates a barrier to entry because it has been pushed forward by Automattic and a handful of people at larger agencies who have the privilege of time and money behind them to do so (of course there are individual contributors too).

    • I have deleted the last part of your comment because it broke two of the guidelines in our commenting policy. Please be mindful of the language you use and present proof of claims that you are stating as factual.

      On the topic of ignoring those not employed to work full time, Matías specifically mentioned that as being a problem and something that needs to be discussed. It’s quoted in the post.

    • I like Gutenberg.

      Yes, of course it is complex in the base. If you write blocks in the base. But I use Lazy Blocks and everything is very cool.

      I write code only in php and css, and I can make a site with blocks.

      But my sites are developed without code, and therefore people who do not know the code can do what they need.

    • Contributing to the block editor itself is naturally more difficult than building blocks, but the block APIs are designed to allow smaller developers and agencies to create rich and highly interactive pieces of software without having to be JavaScript experts. It’d be helpful to hear what parts of it are the hardest to work with for you as it can always be improved.

  2. I’ve wondered about the “difficulty” idea a lot since reading Justin’s opinion piece, it’s so hard to weigh up the before/after development experience vs. where someone was/now is in terms of ability and time. I do feel I’ve experienced more frustration than difficulty with the development cycle post-Gutenberg, and it’s been an anxious few years building on top of a project that’s slowly revealing its new shape.

    Prior to 2019 I chatted regularly with 4 local designers/developers working with WordPress, but the last of them stopped working with it at the start of this year. A couple went off to work on pure React projects (after becoming interested via Gutenberg!), one went to more PHP-oriented work, and one embraced Squarespace/Shopify for client work. I’m adamant about sticking with WordPress in the long term and am now engaged with the open-source aspect in a way I never was previously, but my daily WordPress life has changed, for sure. Between 2012–2020 my income was 100% from WordPress-related work, primarily custom themes and small plugins. This year it’s been basically zero, due to deciding to opt out until full site editing is properly in core. My brain simply started feeling too stretched between the “old” and “new”.

    • but the last of them stopped working with it

      Similar here, previous regular WordPress meetup attendants stopped coming (also online when online meetings started due to pandemic) and told their clients would need a more stable platform which “does not require dev work all the time”.

  3. I don’t want a return to the old WP, but it’s very painful to develop for the new WP because

    1: The build steps for blocks are onerous, tedious, convoluted, ever changing.
    2: The available Gutenberg features are liable to change in the middle of a site’s development->delivery , so it’s impossible to cost and more costly to support.

    I’d never advocate going backwards, because the old system was lumpy and did need refactoring somehow.
    My main problem is that when specifying a project now there’s no certainty. What is the platform, and what are its capabilities? How do we even template now, do we do it with JSON, if so what are the final features? Most of the project still seems like its fluid as if in an Alpha / Beta state.

    For example: Would you build using the new JSON based templating system for a Corporate site going live in September 2021? I suspect not.

    I started a project recently using the new template system.
    To add conditional to the home page required me to make a block with conditionals in (to call the relevant member content), and while there’s a number of native make-a-block strategies there I’m sure we can all agree they are ALL more complex than something like ” .

    I headed down several blind alleys in an attempt to develop that site using only blocks, and JSON templates and patterns , but nothing usable was accomplished (the site requires things the framework doesn’t yet support) and so all that work was set aside as unsuitable and unbillable. That’s a bad feeling.
    The templating system will be great, but it is in development, and while promising it still lacks key features, the tectonic plates are still shifting. It would be madness to build on that unstable footing.

    I don’t have a problem with WP becoming better, but the current WP version is in flux. It’s very difficult to create and deliver sites in a shifting landscape.

    • What is the problem with pinning Block Editor version via the “Gutenberg” plugin?

      I feel your pain about the quick changes in Gutenberg, that is why we always use the “Gutenberg” plugin in projects – and except for security related bugs, I don’t care about updating it for every version.

      Yes, this means they will not have the nicest and shiniest features. But at least everything is stable and works for them. Additionally, you can schedule and quote them on updating in proper intervals (0.5y or 1y intervals).

    • Thanks for sharing this. I’d be curious to hear more about the blind alleys you went through, because it can be illuminating of areas that need more work. Probably the trickiest part we are going through now is that things are moving in some ways too fast and in others not fast enough. I can definitely sympathize with that. One thing that we have been trying to establish more formally are the areas where things are mostly solid and the ones that are a bit more experimental and need faster feedback loops. Hopefully this can be helpful for planning what to embrace for a new project and what needs to wait.

      • Hi Matías ,
        From memory – as this was a while back (Gutenberg Version 10.9.1 ) so I’m sure everything about templating has changed many times in the intervening …. 8 weeks!!

        I think the largest roadblock was that anything programmatic in the theme required me to make a block. For example the site I was making: the home page needed to display different content to different levels of member, and also personalised content such as : “hello USERNAME, here are the stories since you last visited” + a call from an external LMS to show members subscribed course news.

        To achieve that in an old theme involved me writing a php function to render the relevant content against the user ID / user capabilities. Then I place the render_user_content(); into the home template.(not to imply old themes are “good”) That process would take me a couple of hours.
        Now, to accomplish that with the new system I need to open a command prompt, update my Node install, debug why that’s acting so weird as I’ve not used it since February, decide which is the most up to date NPX for creating a block, try to remember which I’ve tried and disliked, look up my notes where I scored them all, decide was it “create-block ” or “create-wordpress-block” / “wp-scaffold-block” or … etc. etc. Discover that the one I rated highest in october 2020 is now out of favour and all the tutorials are out of date.
        Eventually get a boilerplate block running, Troubleshoot my toolchain, fail to get the plugin to update, realise I’m using the wrong Node command window. Find a paths problem in my env vars. resolve that. Shout at the sky. Pull up a tutorial to remind myself of all that command line stuff for Node which I disliked so much because I hate command lines, and am now forced to use. Update some dependencies. 4000mb of libraries download into the wrong folder again. Shout at the sky. Eventually get a Hello World boilerplate block running and feeling like this should be less arduous and fragile.

        Day 2, as soon as I had a boilerplate block I started working on the JSON / partials to load the block, and I soon found that the nesting for a complex home page meant the JSON was frequently invalid due to fumbled closures. I did not have a decent JSON tree viewer in my chosen IDE (Atom) so I spent a good while chasing closures. The file was so large that the nesting was illegible. I used an online validator service instead to lint it.

        Day 3. I got that block up and running I noticed there was no sign of the menu editor any more. That was the week the old menu editor got removed and replaced with the new block editor , but in the theme I’d made there was simply not a sign of the new menu editor.
        Appearance now only had items for “Themes, Templates, Template Parts, Theme Editor” .. and no way to edit the menu. Assuming I had somehow disabled it in the JSON I spent time chasing that and failed. I re-activated TT1 Blocks theme and Appearance -> menu was absent there too! So I googled “what is the new location of menu WP 5.8” etc. to no avail. I, a WP dev for about 15 years, have no idea where the menu is in the admin!!

        I blundered around the “Site Editor (Beta)” section expecting to discover it, but only to get lost in the UI which I found massively confusing. There was no “menu” block at all, only blocks for Page Link, Home Link, Custom Link, etc. No “menu”. No place I could find a back door to trigger a path to /nav-menus.php or any equivalent.
        Visitng that URL directly told me “Your theme does not support navigation menus or widgets.” The theme was TT1 blocks. The error did not take me to the new secret nav menu location. It had no clues.

        Now, I never solved that – but I remembered that I needed to programmatically append to my menu (so that “Sign In” become “Sign out USERNAME”) . Usually this is a simple task which I’ve done 1000 times, and would take me about 10 minutes. Now it seemed that there was no menu any more, I simply could not find it – so I would need to create my own menu blocks with conditionals, and also find a way to edit them – now that the interface is in a special secret place.

        So , after a week I looked at what I had accomplished and discovered it was zero.

        The next monday I archived that work and started from scratch using the old system and by monday afternoon I had a theme, a menu with contextual links, a homepage calling user content. Sure the old system is old, but it works, it’s reliable, its simple. It does the job.

        My toolchain? Local by Flywheel and Atom. That was it. No spinning up of anything, no compiling or transpiling, no online linters, no path errors, no dependencies to update.

        That was my experience with the new template system in June, and it was not reassuring. I did not feel there was the stability or support to build a mission critical website on top of.

        I think the tooling and the UI need simplification and clarification.

        • Thank you for taking the time to share this.

          For the first case, I think it’s totally valid to consider a server-rendered block for the “hello USERNAME”, depending on whether you want to allow customizations or not. You could register a dynamic block, written in PHP, for which you shouldn’t need to setup a complex JS environment. I agree and sympathize simple units like this should not require overwhelming setups. I think ACF is doing some cool stuff there. One thing I’m curious about seeing explored is a way to allow you to write a block like the above directly in an HTML block, using tokens for displaying the username, etc, which can be extended server-side as needed.

          The menu editor disappearing sounds like an unfortunate hiccup (though frustrating) as things were being put in place. The navigation menu block is meant to be accessed through a site editor but also directly as a standalone thing like before.

          The end goal is for things to be simpler yet more expressive. (And for the overall developer experience to be clear and joyful!) There’s a lot of the previous toolset that doesn’t need to be discarded, and can be mixed with a more interactive template editing experience. The way to build themes evolved through many years, so it’s for sure in a more established ground. I appreciate the sincere feedback since the same sense of reassurance needs to be reached. I hope progress happens faster there in the coming weeks.

  4. Sorry, but the Block Editor is user-hostile and not intuitive. Who thought that creating blocks was easier than just hitting the key?

    I think this project is tyranny of the minority. The 5% or 10% most technologically savvy are trying to force the rest of us to adopt this.

    I will stop blogging when I can no longer use the Classic Editor. When composing posts is a chore, the activity ceases to be useful.

    • Can you describe some of the specific issues that you have run into so that the WordPress contributors who read this may be able to address them?

      I’m also not sure what you mean by creating blocks being easier than just hitting the key. Are you just talking about using the keyboard instead of adding blocks via the inserter? You don’t need to use the inserter if that’s what you are referring to. Personally, I work almost exclusively from the keyboard — I have noticed a few bugs myself, which are all reported and being worked on. What issues are you having with this?

  5. Here are some pain points I’ve had to deal with when using/developing for Gutenberg:

    Many people in the core team assume everyone knows and loves JS, React, tooling, and so on. Don’t assume this, please. I personally am still trying to grasp what many people find so great about JS, but sadly I know I’m in the minority.
    The documentation is nearly useless. Many people learn by example, and the examples found there are worthless. And some of them are still using React higher-order components instead of the simpler React hooks. The documentation is basically a glorified API reference.
    Everything is so geared towards block developing, that other areas of the editor are completely neglected. How am I supposed to migrate a plugin that makes a heavy use of meta fields (such as WooCommerce) to this new paradigm? No info anywhere. So many plugins (event managers, e-commerce, SEO, etc.) are still using the classic editor UI to this day because of this.
    In the plugin repo, there should be a rule that bans plugins that just ship the transpiled JS code. As I said before, many people learn by example, and the lack of source code makes this very difficult.
    The Gutenberg Starter Theme (https://github.com/WordPress/gutenberg-starter-theme) and the Gutenberg Examples (https://github.com/WordPress/gutenberg-examples) on GitHub are extremely simple and of very little use.
    There should be a CSS reference somewhere that lists all the classes that should be styled in a theme (frontend and backend) for every core block. I find it puzzling that after more than two years there is no something like this anywhere.
    I find it really annoying that Gutenberg still stores users’ editor preferences in the browser’s local storage instead of the database on a per-user basis. (https://github.com/WordPress/gutenberg/issues/15105)

    These are just some things that come to my mind right now, but there are many more challening issues that i stumble upon on a daily basis.

  6. I might be called a heretic for this but I simply ignore Gutenberg & use Elementor.

    Yes, I’m aware Elementor is slower (it’s improving!) but my skills as a website creator & maintainer have increased dramatically by using Elementor & its addons.

    Immediately prior to starting with Elementor, I designed a small site using only Gutenberg blocks. It worked out okay but I would have saved myself considerable time had I made it in Elementor.

    In my opinion, WordPress Core is great as long as you don’t let it get involved with your theme & design.

  7. When Matias and Justin respond to comments and ask the commenters to supply more details about the problems they mentioned, I doubt many will do that, since many of us already know that the WordPress developers don’t listen to us. They maybe pretend to listen, but the evidence shows that they do not. As one other commenter mentioned, we are suffering the tyranny of the minority.

    Matt has proclaimed that we are going to have Gutenberg and that we are going to love it…no matter what. Unfortunately, of ten or more website designers I personally know, only one says he likes Gutenberg…the rest are just struggling along with it, and considering other options.

  8. What evidence are you referring to, are there recent specific examples you can point to? I thought there were a few missteps early on (for example, the initial framing of custom meta fields as ‘legacy’ was alarming to many at a time when the shape of developing with Gutenberg was still unclear) but overall there’s a lot of very healthy engagement on the GitHub repo for Gutenberg. The FSE Outreach Program is also an excellent place to engage and be heard.

  9. Thanks for this. This seems like a fair assessment (and I’m one of those pining for WP’s “simpler” days.)
    This makes me realize the biggest things I, and probably others, need to get up-to-speed on developing with and contributing to WP and Gutenberg is documentation (even documentation that steps back a bit and gives some help getting started on supporting technologies, like webpack, Babel, and TypeScript which just got added to the list) and code stability.
    I recognize everything is in flux and so documentation and stability are really hard until things slow down.
    Moving development over to GitHub has certainly been a win, though.

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.