Last but not least: why are they different?
As you will understand from this article, every framework can be compared against another, but I will split them into my own groups based on their uses:
- WordPress Project Management: Themosis, Orbit
- Plugin Management: Herbert, Picklist, Boilerplate, BOILERPLATE
- Backend View Management: Vafpress Framework, Redux
You should understand that some of these frameworks are evolving fast; hence I will update this article time after time to track their respective progress. Who can do more, can do less: a framework focused on a project is also able to build a plugin for example, but you have to be aware that you will have to work around the configuration.
There is one last thing to understand, using a certain framework does not prevent you from using another one. If I find it silly using Themosis and Herbert at the same time, then perhaps using some elements from a framework (i.e. how to manage the backend view with another project like an ORM) can be also a good choice if you know how to lay the bricks together.
All is not rosy
Well, during your next conversation with another developer, you can say that you are using a framework, and you are following “good practices”, “clean code”… Welcome to the master class! Pay attention there is also a hidden side of the moon.
If the project is stopped: Well, nobody plans on dying, but everybody will; the same works for IT projects. So, I will have a small preference for open source projects; when people stop working on a large project, most of the time there’s a small group of people that are frustrated and starts a fork in order to make some minimal maintenance of the project.
If it’s not possible to do what you want: I already saw people starting work on a technology without knowing exactly if it will meet their needs. So, read, learn and make a small proof of concept.
What if it doesn’t run in your productive environment? Did you already check if you can run your new framework on your productive environment prior to any serious coding? For sure, it will run smoothly on your development device and as developers always said: “But… it worked on my device!”, it’s so easy to manage localhost, feels like home right? It’s even more so with an environment like Mamp, Xamp, LAMP, EasyPHP… but it’s dirtier when it comes to production.
Mostly, as you will have the following option:
- WP official repository: That’s tricky guys! First, you will have to pass a complete review of your plugin by the WP team. They will require several parameters such as being able to run all supported versions of PHP!
First, be sure you meet the WP plugin guidelines, Take a look at how to write a plugin on codex, optional get a look at the coding standards.
Then, remember you will be downloaded by users all around the world in any kind of hosting, so the next rules “Shared hosting” also apply to you.
- Shared hosting: People using a shared PHP hosting have the chance to get a very complete service almost for free; the cons are that the less money they paid, the less parameters and configuration they can manage. Being able to change the PHP version is sometimes possible (often via cPanel or a .htaccess file), but loading a new Apache module feels like mission impossible. Why will people buy a dedicated server if everything is possible via shared hosting?
- Your own server: That’s the easiest part; it’s your server, so you can install what you want. Just do it the clean way, and be sure it will not impact existing applications already running on that server.
So be sure to make a small proof of concept, and check if it meets your needs and runs in your productive environment.