This is a personal exercise. When I say personal exercise I do not mean you are going to get sweaty here. It is a mental exercise. My friends know I am not a fitness kind of guy – I know that's sad, but let's stay on topic here and save your fat jokes for the comments section. Think about how you like to code. When I am confronted with this question I always choose to write as little and as meaningful code as possible. Do you agree with this vision?
Some jibber jabber
Sometimes I have been known to take things to extremes – at least for a minute or two. This happens because I am on a quest to be the best Software Engineer I can be. I want to build truly beautiful and easy to use code. I want to build tools to make my life – And yours – easier. To do this, sometimes, I need to embrace constraints. I need to accept the reality – what is – and compromise a little in my vision – of what can be. This compromise doesn't come easy to me. I am stubborn and proud – This doesn't mean I am incapable of accepting new and interesting arguments. It takes time for me to say: "OK. I guess I was wrong". But you have to understand I am talking about my creation here. Some people have babies to make their life meaningful and bring them joy. I am one of those guys who need to make pragmatic contributions to society. That is what makes me happy.
My vision
At the time I am writing this article there are 3 components for my pet-project WPExpress:
- WPExpress/UI: A Render engine for WPExpress which allows you to implement mustache or twig in an easy way.
- WPExpress/Query: An abstraction layer for WP_Query. An object-oriented tool to build WordPress queries faster.
- WPExpress: One day while working on a WordPress project I found myself repeating a lot of the same code over and over. So I decided to create a tool which would cut corners and allow me to write meaningful code.
WPExpress UI, Mustache and Twig
I will not tell you how much it bothers me to see HTML code embedded in strings. It would be like spitting at myself – Or at the people who used to love classic ASP. Instead, let's talk about Separation of Concerns. If you are familiar with the concept and purposely choose to ignore it, skip to the next section. Ok. Those of you who stayed. I guess a couple of you came to WordPress from some sort of an MVP framework. Code Igniter, Yii and friends. You like routing, your controllers, and views. I like them too. They make sense. And make our lives easier too. For us who have experience with MVC frameworks Separation of Concerns is not an optional thing you do when you have the time. It is encoded in our DNA – Well it is actually a very strong preference, but just gimme this one. Separation of Concerns allows for DRY and building layered applications. It is something we learned once and kept doing because the logic is sound. That said. It doesn't mean the rest of the world is wrong just because they are different. Some people just like to write code like it is 1999. We need to respect that. Even if it is a hard thing to do. Because we are grown-ups – or at least we are supposed to be grown-ups. When I first started WPExpress I wanted to impose my vision on what good code is. Follow PHP-Fig recommendations. Respect Semantic Versioning. Implement Separation of Concerns, Inversion of Control, Composer powered autoloads. And I wanted to wrap it all up in a pretty Open Source package under the GPL License. I failed! I started getting some comments from fellow WP Developers telling me "that is not the WordPress way". They are not right. Unfortunately, the fact that they are wrong doesn't make me right either. I felt this was a futile endeavor on my part. Just like any other argument about who's right. It doesn't lead anywhere. When I created in my mind the idea for this framework it was bound to Mustache and Twig. Because – call me crazy in the comments section if you must – in my mind it makes perfect sense to move away from embedding HTML within PHP code. However, trying to convince people about quitting their nasty string embedded HTML vice is not a battle I am prepared for. Nor is it a battle I want to take on. So it is with a heavy heart that as of WPExpress 1.4.0, WPExpress UI will cease to exist.
Moving forward
When defeat comes, accept it as a signal that your plans are not sound, rebuild those plans, and set sail once more toward your coveted goal.
The above quote is from Napoleon Hill @ Brainy Quote.
I pride myself on being consistent. I know that when I have made a decision to go big or go home I have the backbone to support my choices. I've lost the battle to keep Mustache and Twig as part of WPExpress core. I ended up killing a component and assimilating it back into the main codebase. I have made several mistakes in trying to impose my view of what code can be. But I will not quit, and I will not cease to support my view of what code can be. I just will not force it on you or anyone else. Your mission, should you choose to accept it, is to be the best Software Developer you can be.
What this changes mean for WPExpress users
- A Minimal Footprint Framework: Since Mustache and Twig are gone for good from the code base, that means you will benefit from a smaller codebase. This will eliminate hundreds of files from the vendor directory. Which is great if you did not use these packages. Or if you just used Mustache.
- New Optional RenderEngines: The BaseRenderEngine class is an abstract class which delegates the render method to the child class. This is "The" right move to support multiple RenderEngines. As I said before, I will not waver in my resolve to support Twig and Mustache. I just will not force my vision on the rest of the world. WPExpress 1.4.0 will ship with a WordPress based RenderEngine class. This class will attempt to load the files from the Stylesheet Directory, then from the Template Directory and it will default to WPExpress's own vanilla PHP files if no custom template is defined. The logical next step is to add two new optional components:
- WPExpress/UI/RenderEngine/Twig
- WPExpress/UI/RenderEngine/Mustache
These packages contain the related dependencies and will support developers to keep toying with Mustache and Twig.
Learn to embrace constraints
As I told you at the beginning of this post, this is an exercise. One which allows me to demonstrate why Embracing Constraints is a good thing for building good software. I am working on a pet project to create low-cost interactive whiteboards. My original idea had a lot to do with EPD for low energy consumption – and because it is quite cool. However, after researching for a couple of weeks I came across Johnny Lee's video on How to create a low-cost Interactive Whiteboard using a Wiimote. My view of the world is to use EPD. What I can achieve at the time being is different. I have decided to embrace my constraints and repurpose my – not so original – idea. I leave you now with one of my favorite quotes from Theodore Roosevelt:
Do what you can, with what you have, where you are.
Thanks for reading. If you like this article, share it. I am always open to exchanging ideas on Twitter @iaaxpage.