20 Comments

  1. DannyW
    · Reply

    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).

    Report

    • Justin Tadlock
      · Reply

      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.

      Report

    • uptimizt
      · Reply

      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.

      Report

    • Matías
      · Reply

      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.

      Report

  2. Daniel
    · Reply

    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”.

    Report

    • Claudio
      · Reply

      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”.

      Report

  3. Steve Grant
    · Reply

    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.

    Report

    • Martin
      · Reply

      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).

      Report

    • Matías
      · Reply

      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.

      Report

      • Steve Grant
        · Reply

        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.

        Report

        • Matías
          · Reply

          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.

          Report

  4. Rules Of Logic
    · Reply

    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.

    Report

    • Justin Tadlock
      · Reply

      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?

      Report

  5. Bastian
    · Reply

    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.

    Report

    • Matías
      · Reply

      Agreed more examples are needed to help learning by imitating, which I concur is super important. Would expect to find those in the main documentation handbook or elsewhere?

      While blocks are one of the most important APIs, there’s still a lot of work put into other ways to extend the editor interface. If you haven’t, check out the reference guides in this section which cover a lot pluggable areas: https://developer.wordpress.org/block-editor/reference-guides/slotfills/

      This is still a beta, but the Block Book is meant to be a good way to inspect different blocks and get a reference for how to style them.

      Report

  6. Marcel Oudejans
    · Reply

    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.

    Report

  7. Christian Nelson
    · Reply

    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.

    Report

  8. Daniel
    · Reply

    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.

    Report

  9. Michael Nelson
    · Reply

    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.

    Report

Leave a Reply to DannyW Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: