45 Comments

  1. Nick
    · Reply

    Nail on the head. I often think things are harder and overly complicated now, but I’m probably just an old curmudgeon. Just gotta evolve or get out of the way.

    Report

  2. Otto
    · Reply

    Not everybody makes the same things. And not everybody works the same ways.

    I’ve made a lot of code over the years. Java, C, C++, PHP, and so on. Many languages. Each of them has their conventions. Most of them are about the community, and are not directly rooted in the language itself.

    This is “normal”. I don’t expect the JavaScript systems to be the same as the PHP systems. But, after a while, you learn the new system. It’s not “harder”, it’s just “new”. Welcome to the world of being a programmer.

    When I first took my first computer programmer class in college, it was in Pascal. Really. I know dozens of programming languages, and in the end, they’re all the same. You adapt. You learn over time. It’s part of growing up in computer programming culture. Admittedly, it does help to have a formal background, so yes, I do recommend a computer science degree. But, to each their own, and we all learn that languages are transient. Try not to get attached to either a language or a style. Object oriented is not better than procedural, just different. Namespaces are not better, just different.

    Learn to embrace differences. And learn to fit in. Then you will do best in your programming progression. Because you will not only know one language or style throughout your life. You will know many.

    Report

  3. Archimidis
    · Reply

    Dear Justin your articles are a great source of information, as always and I am thanking you for that.
    However I have one very not so simple question becaule I really want to evolve.
    I am a WordPress themes/plugins developer for almost a decade with fluency in PHP and I also work a lot with vanilla JS . I am at your age also. So I would like to ask you what is the first thing I should read to start developing with the so called “modern” WordPress development style,except the documentation? Should I examine the code of various block plugins and how they work etc? Should I download a nice WordPress block theme and examine its parts etc?

    Report

  4. Nick
    · Reply

    When it comes to few things I’m completely puzzled: People complain about Gutenberg, how Tiny is better, blah, blah, blah… What don’t they just use the Classic Block (in fact you can multiple instance of it in a single post/page), and be happy?

    Also, if one does not want to install and learn a million things (me), why don’t they just use Lazy Blocks, or even better ACF Pro to create their blocks with php, html, CSS, and vanilla JavaScript? With ACF Pro I can do things that the React developers can’t even imagine !

    Report

    • Phil
      · Reply

      Just to note, the Classic Editor was more than just TinyMCE. It was a whole interface with panels for meta data (non visual data). It had action buttons above TinyMCE that helped insert things like media easily at any time. TinyMCE was only one small part of the Classic Editor UI, and the 5+ million people using Classic Editor over the Classic Block likely need it for more than TinyMCE alone.

      Report

  5. Steve Grant
    · Reply

    A small commercial developer is time pressed and we need good tools, reliable outcomes. Currently the tooling is fragmented and difficult to maintain an understand. As business owners it is objectively more difficult, slower, and more costly than previously and brings us few rewards. Obviously there will be rewards, but I wonder for whom.

    For example:
    When I saw this talk about templating as a key goal for end users I was very confused. No client has ever asked me for this, and for good reason – no corporate website editor (intern!) would have time or authority to edit and share layouts, that’s just madness. So who thinks (sharing patterns) is a valuable idea ? One worth a lot of dev time.

    To an academic coder interacting with problems and contributing to the community is a great pleasure and rewards come from peer-group plaudits. To an academic coder submitting patterns to a public library makes total sense. Plus it’s in JSON, sexy, sexy JSON!

    My clients care about other things: If I tell them my build process just gained 28 new steps they won’t be impressed. They don’t care that I’m not using jQuery any more, or even what PHP is.
    Clients care that their design looks good on a phone, is fast loading, easy to edit, won’t break, will integrate with their 3rd party systems. That’s what they value. They don’t care about editing themes. They hire a web developer to take care of that. They are busy with their own work, their actual real jobs.

    But unfortunately – commercial small devs don’t have time to try and push the path toward what we actually want, and academic devs have all the time in the world. To an academic dev it’s fine that the process gets ever more labyrinthine, because they love installing new tools, and trying new methods. I am not at all diminishing the skill of these devs, but I am saying that their love of code is not leading to a solution we in the commercial world actually need – because their goals are not the same as ours.

    Report

    • Dominique Pijnenburg
      · Reply

      You are so right..

      I am one of those small commercial developers. I don’t know what way to go currently. We develop the custom themes for our clients mostly with PHP and a bit of JavaScript if needed. When needing to add custom Gutenberg blocks we use the functionality of ACF (thank god for that). We believe the sites we currently deliver are great and easy to manage for our clients.

      I don’t know what possibilities Full Site Editing will open up for ourselves and end-clients. Maybe I made the mistake of not investing enough time in it, although I feel like I attended various online conferences and read a good portion of articles about it.

      I tried to build Gutenberg blocks the ‘real’ way, by following several video tutorials on Udemy. I’ve seen functionalities that I can’t mimic with ACF, but also the other way around. And performance of ‘vanilla’ blocks in the editor is way better. But I feel like it’s so much work to create blocks this way and the rewards aren’t that big. And indeed, setting up the environment isn’t great and caused a lot of trouble.

      And then there’s also the movement to headless websites, with WordPress as the source of data. I am far more enthusiastic about that, but I am totally unclear in what the role of Gutenberg will be there.

      Report

    • Carlos Guerra
      · Reply

      No client has ever asked me for this, and for good reason – no corporate website editor (intern!) would have time or authority to edit and share layouts, that’s just madness.

      100% same here.

      Report

    • justanotherdev
      · Reply

      Maybe it’s the other way around and deeper:

      Perhaps it is Your (all wordpress.org users) goals that are not the same as Theirs.

      Because think about it… Let’s imagine the goal was to build a Wix/Squarespace competitor, then with that perspective every decision that has been made has been “correct”. The end “client” in that perspective is very different to your client…

      Report

    • Justin Tadlock
      · Reply

      I was one of those commercial developers, launching my first business in 2008. Of course, my fulltime job is now at WP Tavern. However, over the years, I have had many clients and users (not all) who would have loved for the ability to directly edit templates and the like.

      It all really depends on who you are creating products or solutions for. Let’s not split this discussion between academics and real-world developers. The experience of the latter is not homogenous.

      What is important is discussing what tools/features/etc. that would help you and those doing the specific work you’re doing, opening tickets for those things, and trying to get them into core.

      Report

  6. Courtney A Robertson
    · Reply

    On the training side of things, as of yet, there isn’t a clear progression after being a user. When a person wants to advance into the code, there are just a lot more steps involved.

    https://make.wordpress.org/training/2021/05/03/high-level-roadmap-to-learning-wordpress-development/

    Harder or easier than the past WordPress, than the past non-WordPress web development is an individual opinion. Adding more complexity isn’t bad. I wouldn’t want to return the WordPress of 10 years ago.

    A clear progression through the sequence would benefit learners at all stages of their journey. Experienced developers can spot areas they may want to revisit and improve upon. Beginning developers and training organizations can follow a logical flow for what to cover in which order.

    I’ve surveyed the web developer training programs. I’ve only found those instructing on how to use WordPress and no-code configuration. I have not found others covering the development portion. A common misconception there is that it’ll be easy to learn in a short amount of time. Again, hard or easy is subjective.

    What is hard though, is wanting or trying to learn something when you don’t know what you don’t know. If you don’t know a rough order to learn various languages and build tools in, it can be very challenging to figure out where to start and what is next.

    I hope to see the WordPress community help ourselves continue learning, and also to onboard the developers of the next 18 years.

    Report

  7. Damon Cook
    · Reply

    Thank you for your reflection and insightful writing Justin. This is a superb contribution to the conversation.

    I remember when I started creating a blogging network for my state university back when WordPressMU was a thing. The documentation was fragmented, but the community was strong (as it still is).

    I’m excited by the large shift in theme development. It certainly seems rapid and frustrating at times to try and keep up. Again, community prevails and many have helped answer my questions. I’m very grateful for this community and looking forward to the future. 🚀

    Report

  8. BlogSafe
    · Reply

    If I’ve learned one thing in my 40+ years of writing code, languages change. You either adapt or you become old school. New school has it’s own problems. Coders can often become so focused with the bloated features that try to make it look nice that more important accuracy and efficiency issues get shoved aside. For example. There’s a known bug in WP core code whereby a database insert will fail without error if the fields aren’t large enough to hold the data. No warning, no truncated insert, just silent failure. For six years that I know of, this bug has been repeatedly kicked down the road. But Gutenberg is looking nice.

    Report

  9. Geoff
    · Reply

    As someone who got into WordPress development literally a year before Gutenberg was announced, I think I actually have a pretty good perspective on this, and yes, development is harder and more complicated now. That said, that’s partly because I learned the php side of WordPress when it was very mature and well-documented.

    The fact is though that creating new blocks requires a lot of the baseline skills that WordPress dev has always required (setting up a local build, probably knowledge of version control, some knowledge of PHP, CSS, JS, and HTML, an understanding of how WordPress manages data, etc.), while also requiring new skills, such as writing JSX, configuring JS build tools, and just plain understanding how the block editor works. You still need to learn most of what you used to need to learn to get into WP dev, but now you need to learn more, plus the documentation for the new stuff just isn’t as mature as the docs for the old stuff were when I was learning it a few years ago.

    That said, I’m completely a fan of the new direction. I mostly create sites for non tech-savvy clients, and the block editor is just so much easier for them to use. Seeing your content look the same on the backend as the frontend is huge for usability, and I’ve completely replaced my previous workflow of mostly using ACF, to one centered around the block editor.

    Also, while it was difficult to learn, it is ultimately super empowering. Being able to design the editor UI for new blocks is a huge usability win, and I now find myself putting almost equal effort into designing the backend experience of new blocks as the front end experience, and I think my clients end up as the winners ultimately. I’ve definitely noticed a lot less emails asking for help making content changes, and while the documentation for developing for Gutenberg is a little spotty perhaps, the docs for using Gutenberg are great, and my clients can figure a lot of it out for themselves.

    Report

  10. Josh
    · Reply

    This post makes great points but I think they support the opposite conclusion.

    If the 2007 version of you was transported to now, Justin, how easy or hard would it be for them to build that block? I don’t know the answer. How good was your JS in 2007.

    In 2007, you need to know PHP to work on WP. Now you need to know PHP and JS. Of course, it’s harder.

    Steve Grant’s comment hits on a key issue: the apparent chasm between people who build websites for a living and the academic developer.

    I’m not sure why you quoted Carolina Nyack’s tweet. To me, it highlights the problem.

    “When people get stuck saying, ‘But I can’t use my hooks in a block theme,’ it is because they are looking at what exists today, not ahead.”

    We’re looking at what exists today because we don’t have time machines. We’re building websites today. We need a solution that works today and won’t break tomorrow.

    Report

    • Justin Tadlock
      · Reply

      I removed the last paragraph of your reply. Please make sure that your comments follow the comment policy.

      If the 2007 version of you was transported to now, Justin, how easy or hard would it be for them to build that block? I don’t know the answer. How good was your JS in 2007.

      I don’t know if it would be much harder one way or another. I was not particularly good at PHP or JS at the time. I was much younger then and a bit more driven to pick up new skills.

      In 2007, you need to know PHP to work on WP. Now you need to know PHP and JS.

      You can also know just one or the other to work on WordPress now. There are parts where you can work on and not know a lick of the other language. It just depends. It’s better to be well-versed in both.

      Report

      • Josh
        · Reply

        Thanks for taking the time for all of the replies. It’s taking ages to read all the comments and I’m only replying to this one.

        tl;dr It isn’t just the technical difficulty. You also have to look at the willingness to invest the time to overcome the difficulty.

        I think the curse of knowledge has you, Justin. You’re looking at the situation through coder-colored glasses. If I knew more JS, I might have a different perspective.

        Gutenberg asks (some) people to learn a new language to do the same thing they’ve been doing since WP’s inception. If there’s a write-up explaining how the benefits outweigh that cost, I haven’t seen it.

        You’re right for your reality. It probably isn’t any harder to start with WP now if you know the languages. And with today’s documentation, it might be easier. But if you don’t JS, it’s so much harder.

        I apologize for violating the comment policy. I’m not sure which part broke which rule. But, as someone who has used WP for as long as you but hates JS, this is absolutely a nightmare.

        Gutenberg and its implementation might make sense to coders and/or WP insiders. But it doesn’t make sense to everyone. That lack of understanding leads to confusion and even some distrust. You can’t just compare difficulty levels between 2007 WP and 2021 WP. You have to compare people’s willingness to overcome that difficulty whether it’s due to concerns about Gutenberg or the lack of ROI.

        Report

  11. Álvaro
    · Reply

    The experience is totally different. Making this assessment from a programmer’s point of view is tendentious. Developers are more predisposed to new build processes. For non-programmers, the entry level has become much more complex. If we compare a beginner 10 years ago with a beginner today, today’s path is much steeper.

    Report

  12. Daniele Mte90 Scasciafratte
    · Reply

    I agree with various people here.
    Looking on my 90% customers as we agency they don’t need blocks, they just write articles or have product with a description. The layout is built as they wanted by the theme we did without any block.
    This user case is not handheld now by wordpress without the classic editor that will stop support the next year.

    Looking as plugin developer with thousands users in free/premium that do also support, the situation is highly similar. Sometimes they create ACF fields to achieve the same things and without the burnout to check that the website is not broken with an update.

    In all of this we are forgetting that the majority of WP websites are small websites that don’t need this stuff and everyone it is doing in a different way that is replicating the fragmentation of visual composer/page builder just without blocks.

    At the same time gutenberg is not optimized with google pagespeed/lighthouse and coreweb vitals because the css/js are injected in all the pages also if the blocks are not used at all or if it is used just one.

    So we need to think that there are casual users where gutenberg is useful but the people that work, like many people in the comments, as dev or support all of this is a trouble.
    Honestly I don’t think that is a matter of dev age or tech debt, is that we are changing how wordpress works but is not complete with various issues.
    Something that forcing gutenberg created when it wasn’t ready and is not still ready.

    Report

    • Nick
      · Reply

      “This user case is not handheld now by wordpress without the classic editor that will stop support the next year.”

      Someone please correct me if I’m wrong here… Removing Tiny (Classic Editor) from the core should not be a big issue, as from my understanding, the Classic Block is built separately and from the grounds up, therefore it will always be available no matter what. Also, I’m almost certain that when the core removes Tiny, it will be introduced by someone if not by several developers as a plugin.

      BTW, during Euro Camp 2021 Matt said that he does not think it will be a big problem if they add another year before removing the Classic Editor from the core, so it will happen, it’s just when… so those who heavily rely on it, start using the Classic Block instead, just to be future proof.

      Report

  13. Nigel
    · Reply

    I don’t doubt people’s ability to learn new skills. There has been little focus, however, on the economic hurdle. I came to WordPress because I had a PC that didn’t have enough power to compile a simple mobile app. Fast forward 5 years and here we are, back at square 1.

    Report

  14. Jon Ang
    · Reply

    If anyone has good ideas on how to make any of these challenges (which in my opinion are great for leveling up) easier via Documentation, I’m all ears and directly contactable on Make / WordPress Slack. (#docs that is!)

    Report

    • Steve Grant
      · Reply

      I’ll illustrate one convoluted item which needs documentation, or more likely refinment

      Use case: make a Pattern.
      User (with relevant rights) lays out some blocks in the editor, and wishes to make them into a pattern for re-use.

      How do they do this?
      Currently it’s not self explanatory. There’s a menu item called “Add to re-usable Blocks” which is a similar but different (abandoned?) feature. There is no “Add to / Export to patterns (json)” here.

      If a user finds the code view and copies the text they’ll need to unescape it. Most online tools will throw an error at the input (“invalid JSON”). So teh best option is to actually “Add to re-usable Blocks” then manage reusable blocks then export as JSON, then add into a file for later re-use.

      I think that process is less than sleek or self explanatory considering Patterns are such a big headline feature.

      Report

  15. Lee Blue
    · Reply

    There is a huge opportunity right now – especially for those who aren’t coding gurus – to take these amazing new plugins, themes, blocks, etc. and assemble them into something that drives results for their clients.

    The secret to success is to develop your solution FIRST then win clients who want the outcome of the system you’ve built rather than hunting for people looking for garden-variety WordPress skills.

    For example, build a system like Support Docs for SaaS Startups. Build your data organization opinions into the product. Then market your system to SaaS businesses saying this is how they can reduce churn and streamline their onboarding process. Those are the results they want.

    Thanks to all the awesome forward looking work being done in the WP community right now we need people to take those pieces and build beautiful systems without needing to write/invent anything new.

    Report

  16. David McCan
    · Reply

    Absolutely if you want to write a plugin that interacts with the editor then the learning curve is much higher than it was before Gutenberg. Previously I could look at the code of other plugins to figure out how to add an icon to the editor toolbar, for instance. Learning through reading the code is harder now because the code has gone through a build process.

    ACF, Meta Box and other plugins have shown that it is possible to support creating Gutenberg blocks using PHP. If we want to reduce the barrier to entry that would be a good place to start. Any reason why that isn’t supported in core?

    By the way, congrats on being able to create your first block in a few hours. I believe that is exceptional, not normal. I’ve seen several professional theme developers say they studied hard for about a week before making their first block, although perhaps you and they were approaching it differently.

    Report

    • Justin Tadlock
      · Reply

      Learning through reading the code is harder now because the code has gone through a build process.

      I had this in my notes but forgot to put it in the post. One of the major reasons it’s harder is because so many plugin authors do not provide their source code along with their build/production code. And, if it’s not publicly available on GitHub or similar, it’s impossible to study it.

      This is one area that I wish the plugin directory would follow the theme directory rules. All minified/compiled code should include the original source.

      ACF, Meta Box and other plugins have shown that it is possible to support creating Gutenberg blocks using PHP. If we want to reduce the barrier to entry that would be a good place to start. Any reason why that isn’t supported in core?

      I haven’t tried these out in the while, but the last time I used a project with ACF Pro, it was a pretty terrible user experience because it relied on server-side rendering, needing to refresh the block content instead of a JS-based live preview. I am not sure if that is still true today.

      But, core WP basically does do this. SSR blocks are the easiest to build, which I believe ACF builds upon. It’s just the edit part (assuming there are block options) needs to be coded in JS. This is a really good jumping-in point if you want to transition something like an old shortcode or widget to a block.

      By the way, congrats on being able to create your first block in a few hours. I believe that is exceptional, not normal. I’ve seen several professional theme developers say they studied hard for about a week before making their first block, although perhaps you and they were approaching it differently.

      Everyone learns at their own pace. I know others who pick up things much faster than I do. My approach is more just diving in headfirst. Then, study when I hit a problem.

      Report

      • Tobias Schmitz
        · Reply

        because so many plugin authors do not provide their source code along with their build/production code.

        Isn’t this against wordpress.org plugin repository rules?

        Code must be (mostly) human readable.

        We require developers to provide public, maintained access to their source code and any build tools in one of the following ways:

        – Include the source code in the deployed plugin
        – A link in the readme to the development location
        We strongly recommend you document how any development tools are to be used.

        Why are these plugins allowed?

        Report

  17. Fat Brad
    · Reply

    Justin you are 90% wrong in this article.

    As someone else said building a block requires javascript, php and I’d add you need to learn react as well.

    WordPress desperately need to make building a block as easy as building a shortcuts, it is about an order of magnitude harder atm

    Report

    • Justin Tadlock
      · Reply

      I can live with being right about 10% of the time. 😂

      Report

    • Steve Grant
      · Reply

      I’d settle for “as difficult as making an Elementor Extension”.

      I don’t know how many people have tried making an extension for Elementor, but it’s really really easy. The documentation is sparse, but clear. And that’s enough documentation because it’s so simple. To add to that – all the pro-top articles only require 1 short page, because the foundation is so simple that even the protips are readable in one chunk.

      If (native) Gutenberg block creation was as simple as making an Elementor widget that would be a massive improvement.

      To be clear I’m talking about process here, nothing beyond that.

      Report

  18. Michael Nelson
    · Reply

    Thanks for sharing some valid points.
    I’m one of the critics of WordPress modern development and wrote about it here: https://cmljnelson.blog/2019/02/05/are-wordpress-small-d-developers-getting-left-behind-by-modern-best-practices/

    I don’t think the problem is just that I, a backend developer, am being forced out of my comfort zone into the front end. It’s that modern WordPress development reminds me a lot of ancient Java development from 15 years ago. It’s riddled with build tools, incomprehensible dependency trees, and configuration files. A simple “hello world”-type application is dizzying.
    And like Java’s Spring Inversion of Control fiasco-of-a-framework was obliterated by Ruby on Rails’ “convention over configuration” because it removed a so much over-complicated nonsense, I hope WordPress’ super-complex configuration gets replaced by something more approachable to newbies and oldies.

    Report

  19. Nick
    · Reply

    Great article, I think this applies to all types of programmers. I am a dotnet developer and I related to the difficulties you have written about. Web technologies have accelerated in the last few years and it’s hard to keep up-to-date with it all. When I was at college I was told never too use JavaScript, disable it and create websites in macro media flash! My, how times have changed!

    Report

  20. Brandon Paul
    · Reply

    Its both.

    Modern web development is too complex – i challenge you to make a form with date picker that displays formatted dates on IE10 – but also this can lead to greater opportunities.

    Report

Leave a 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: