Is WordPress Development Really All That Hard To Get Into Today?

Oh, how easily we forget the WordPress of 10, 15 years ago.

We are spoiled. We are spoiled by the gluttony of documentation and tutorials, a wealth of knowledge created over more than a decade. We are spoiled by our own expertise, built-in our more vigorous youth, now sitting on our haunches as we have aged along with our beloved platform.

We have grown to become the proverbial grumpy old men. “Back in my day, we didn’t need all these fancy tools to help us write code. We pulled ourselves up by our bootstraps and built everything from scratch.”

I kid. Sort of. I count myself among the old-school developers who helped build the WordPress that so many are still nostalgic about — I think I have earned the right to joke about myself. They were “simpler” times but not really.

Having been in the community as long as I have, I can remember the backlash each time a new feature landed. I recall the days when there really was non-existent documentation for pretty much everything.

Lately, there has been a growing conversation around the difficulty of overcoming WordPress’s current barrier to entry for developers. This has been an ongoing discussion for a few years now, but the latest flare-up comes on the heels of a tweet by Chris Wiegman:

The deeper I get with modern WP dev the more I understand why newer devs don’t like to work on it. This is not the same project as it was in the past. The learning curve is now extremely high regardless of past experience.

I built my first block plugin in a few hours about a month ago. When writing on the experience, I said the barrier to entry was much higher than when I had built my first plugin in 2007. Having had the time to sit back and think about that, I am not sure it was a fair statement. We tend to view the past through rose-colored glasses while forgetting the real struggle.

What I had wanted was to build the plugin in 30 minutes. Had everything been in PHP, that would have been an easy feat for me. Objectively, I am an expert (or close enough) in the language. However, my JavaScript knowledge is 10 years behind.

It had been a while since I had been challenged in that way. That was a distressing experience for someone who had become comfortable in his own skills.

I griped about the docs. But, let’s be honest. WordPress has never had the sort of deep documentation that could teach a budding developer everything. I know this because I have written at least a couple hundred tutorials in my career. Nearly every time, I dug into the project’s source code to make sense of it, which allowed me to teach other developers how to work with various features. And many other developers in the space did the same.

In time, WordPress.org added more robust developer documentation, but this was not built overnight. It is a constantly evolving project.

I also built my first block type with vanilla JavaScript. No build tools. No React docs open. Just plain ol’ JS code in my editor. I needed to crawl before I could walk, and getting that first iteration of the code into a workable state was necessary before I jumped into anything more complex.

In the days after, I re-coded it all to use more modern JavaScript and compiled it with webpack. A week after that, I built a second block plugin with more advanced features.

Was it hard? Definitely. Was the barrier to entry higher than when I first developed plugins? Probably. Truthfully, I did not struggle as much, but I am also at a different point in my life. At 37, I no longer have quite as much drive and likely less capacity for picking up new skills as quickly as in my late teens and early 20s. However, I have a strong foundation and enough experience to overcome some of the hurdles I encountered.

Would a 20-year-old me struggle with this JavaScript landscape more than a strictly PHP-based WordPress? I doubt it. Both had huge learning curves for someone new.

Someone’s first introduction to Subversion or Composer can be just as scary as their initial dive into webpack and npm. For a fresh mind, an open canvas that has yet to be painted with over a decade of doing things the “WordPress way,” I am unsure if the barrier to entry is so much higher.

For us old-schoolers, our world has been flipped upside down. There is no denying that. The Gutenberg project, which is at the core of nearly every new WordPress feature, moves so fast that it is next to impossible to keep up with while also upping your skills. It is easy to get overwhelmed. When this happens to me, I usually take a step back and return when I have had a chance to rest my mind.

Contributing to the WordPress ecosystem has always had one barrier or another. Whether it be the privilege of time, knowledge of PHP, or some other skill, the project has left some people out. That is changing in some ways. Some parts are now available to users that were never accessible before. This is easiest to see from the theming side of things.

“I wish people would see that theme development is heading the opposite way,” tweeted Carolina Nymark. “The entry barrier for designers and new developers will be lower. 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.”

Having spent more time on the theming side of the block editor than plugin development, I agree wholeheartedly. Theme authors have been given a clean slate, or at least by the time block-based themes are supported in core WordPress, this will be true.

While I could write ad nauseum on the details of how theme development itself is leaps and bounds better, the revolutionary part is how the system welcomes those who had no entryway in the past.

Alongside version 5.8, WordPress.org opened the first iteration of its pattern directory. Soon, any user will be able to contribute custom block patterns without writing a single line of code. They can simply create layouts from the editor, copy them, and share them with others.

When the site editor lands, it will once again change the game. Non-coders will have the power to essentially create entire front-end designs without any preexisting programming knowledge.

If WordPress must become more complex for developers to provide end-users this much power, I can live with that.

The highest barrier to entry — as it has always been — is contributing directly to WordPress. Or at least contributing to the block side of things via Gutenberg.

The Getting Started With Code Contribution section of the Block Editor Handbook is a dizzying list of installation notes and procedures that can be off-putting to even the most seasoned developer. Because just about everything is a third-party tool, any trouble you run into just setting up your system is likely to land you in support forums or chatrooms outside of WordPress. Even moving past setup, contributing code to Gutenberg is unlike the days of yore.

What is lacking is the history. We had a decade and a half to perfect our systems for classic WordPress. It was often ugly and brutal building the platform and the ecosystem around it to a point where it was a comfortable space for developers. We have had only three years for modern WordPress to feel as natural as in years past.

I am ever the optimist, hoping that in another 15 years’ time, we are having these same discussions about the new technology stack that WordPress 10.0 has introduced. In the meantime, I look forward to seeing our documentation evolve, our developer community expanding its skillset, and new WordPressers coming along for the journey.

Continued Reading

In this discussion, there are no right or wrong answers. The conversation matters because it enriches our knowledge and informs how we build the next version of WordPress and the web.

The following are links related to this topic that helped inform my thoughts. Each is worth a read, listen, or viewing. If I missed any that others have published, feel free to link them in the comments.

45

45 responses to “Is WordPress Development Really All That Hard To Get Into Today?”

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

  2. 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?

  3. 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 !

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

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

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

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

    • 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…

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

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

  6. 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. 🚀

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

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

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

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

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

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

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

    • “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.

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

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

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

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

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

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

      • 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?

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

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

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

  18. 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!

Newsletter

Subscribe Via Email

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