I’ve debated a long time—as in over 12 hours—on whether or not I wanted to share my opinions on this because is such a sensitive topic, and I don’t want to do any damage to the way the WordPress developer community is perceived.
I care about our reputation and I want to have positive discussion with other developers. As someone who builds things for, blogs about, and contributes directly to the core of WordPress, I should share something.
The way I see it, I care about WordPress and software development, so I have some obligation to share my thoughts (though they are probably better suited as a blog post).
TL;DR (WordPress is not Doomed)
Generally speaking, I think that we—as in all developers—need to stop projecting what we like about one framework and saying that that’s how another framework should operate.
On Frameworks and Libraries
For the most part, frameworks and libraries are written and evolve out of a felt need that a person or a small team has recognized. It normally grows fast from there especially in the open-source community. This is a Good Thing™.
Frameworks and libraries are meant to solve a certain problem in a certain way. The problems that they are aiming to solve may not always be the same problem that another application is aiming to solve, so trying to project one framework’s approach onto another may not be fair. It really does depend on the respective problem at hand.
That said, there are general concepts that work well in the context of building web applications that can transcend libraries. Are there things WordPress can do better? Absolutely. Are there things it does amazingly well? Absolutely.
But it’s growing, changing, and maturing. What else can you expect from software? Seriously.
My Thoughts on The Dire State of WordPress
Above all else, I love when people share their opinions about their favorite piece of software. I think that James genuinely wants to see WordPress improved—don’t we all?
And his final comment confirms that:
So consider this post to be the start of a discussion about how [migrating the functional aspects of WordPress to a PHP MVC framework] can happen. I ain’t quittin’ you yet, WordPress.
With that said, I firmly agree that WordPress works fundamentally different than many of the most popular frameworks especially those that are MVC. Now, many believe that MVC is the best way to develop web applications.
Honestly, I used to do Rails prior to WordPress because MVC simply fits my mental model of how web applications should work. In fact, it’s why my boilerplates are written with, say, the
views directory and the core plugin code includes the view code.
It separates view logic from core business or API logic.
But that doesn’t mean it’s the de facto pattern for building applications, nor does it mean that other frameworks are excempt from their own issues. At the time of this writing, Rails 3.2.13 has major regressions. Is this a Dire State of Rails? I kid, I kid.
But only sort of.
To address the points in the article:
- The article is predicated on the idea that WordPress should follow MVC ideals as it’s a best practice. Though MVC is popular and has it’s advantages, it’s not the de-facto pattern. The Template Method Pattern, the Pub/Sub model, etc. all offer their own advantages.
- Yes, you could argue that there’s a mish-mash of views and data mangled together in WordPress. This is a problem, but only in so far as you’re attempting to apply one pattern’s approach to an application that doesn’t follow said pattern. I fully admit that this creates spaghetti code and a maintenance nightmare, but the thing is, we can do a better job of separating our logic. I know many plugin developers and theme developers who already do it.
- There are rules and best practices for theme development and for coding standards, but whether or not developers adhere to them is their problem – not WordPress’. You can mish-mash view and data logic together in Rails and ASP.NET MVC just as much as you can in WordPress and throw conventions out the window. I view this as more of the developer’s responsibility.
- I think that a platform’s optimization for speed of development is at least partially contingent upon a developer’s familiarity on the environment in which s/he is working. I can write a certain type of WordPress application faster than a Rails application and vice versa. It depends on the problem domain and what tool suits the solution best. If we’re getting into that discussion, then it isn’t about WordPress’ shortcomings, it’s about developer’s familiarity with other frameworks and knowing what tools are best suited for their problem at hand.
- Finally, to the documentation, I think he’s right. Luckily, we’re making a huge concerted effort to fix this. It’s simply going to take time to ship the new documentation, but we do have a time committed to it, editors behind it, and a schedule that we’re aiming for.
Overall, I think that he makes some compelling points and I applaud his desire to continue improving WordPress. At the risk of sounding cliche, it’s what we all want, right?
But I think there are some points that are more closely aligned to “I can’t seem to do [X] in WordPress the way I was able to do [X] in the [Y] framework.” And I’m not sure we need to work on merging concepts of all of our popular frameworks into a single convention or not.
I’m apt to say the latter.
What’s great for rapidly building web applications, such as in Rails, may not what’s be best suited for rapid building publishing applications, like WordPress.
I don’t claim to have all the answers. I simply want to provide a different perspective on the subject.
But I know that WordPress isn’t in dire straights. It’s in a place that’s better than it was before headed in a direction that will be better than it is today, and plugin, theme, and application developers can build tools on top of it adhering much better practices but it’s up to us to do it.
So if you made it this far, cool. I’m surprised. I’d genuinely love to know your thoughts on all of this.