There are plenty to choose from when it comes to PHP frameworks. Laravel and Symfony seem to be a default choice for many projects, with a lot of hype and media coverage around them. Both are excellent tools. However, we opt for something else, and for good reasons too.
We use CakePHP. As with anything, the less of a difference there is between the options, the more heated are the argument for either of the choices. This is commonly known as Parkinson’s Law of Triviality, or bikeshedding. Let’s try to avoid this.
We will ignore all the usual arguments of the “right tool for the job”, performance, security, community, documentation, etc. In this day and age, PHP frameworks are very similar in all of these regards, and the differences are insignificant.
One of the first reasons to choose a particular technology tool is familiarity with it. We do mostly agree with the “Choose Boring Technology” viewpoint and think that it makes a lot of sense. Our team has an extensive experience with the CakePHP framework. We have used it for years in previous jobs and personal projects. We’ve attended CakeFest events, where we met with core developers of the framework, authors of plugins, and other CakePHP users. And we have even contributed to the framework, several plugins, and the documentation.
OK, so we know CakePHP and like it. But why not change to something else? Why was the initial choice so good and why do we still to it, even after so many other PHP frameworks appeared and matured?
This is because the primary reason for the initial choice of the CakePHP is still true. It is a real, true framework. Let’s explain this.
Definitions of what a framework is vary from team to team and person to person. In our definition, the framework must provide the frame of work. That is, it should enforce or strongly encourage the consistency of work produced by different teams and developers.
We think that CakePHP fits that definition better than others. One of the cornerstones of the CakePHP architecture and philosophy is “convention over configuration”. Here’s a quote from the CakePHP Conventions page:
We are big fans of convention over configuration. While it takes a bit of time to learn CakePHP’s conventions, you save time in the long run. By following conventions, you get free functionality, and you liberate yourself from the maintenance nightmare of tracking config files. Conventions also make for a very uniform development experience, allowing other developers to jump in and help.
Most PHP frameworks allow the developer a lot of choice in how to build the application. If you look at Laravel or Symfony projects, you will notice that they vary greatly from one to another. This makes more the sort of libraries or toolboxes, than frameworks. CakePHP, on the other hand, strongly encourages the developer to follow a particular way, hence, providing a frame of work. CakePHP applications are more similar than they are different, irrelevant of who built them, when and how.
We find this consistency priceless, especially on the long-lasting projects and on the projects where multiple teams and developers are involved.
The last, but not the least, reason that we choose CakePHP is the long-term support. Technology moves fast. And this is mostly a good thing. But it is rarely so when you are involved in the slow-paced enterprise projects. Long-term support is crucial in the corporate world.
At the time of this writing, CakePHP developers are preparing for the release of the major version 4. The long-term support for the current version 3 will continue for 18 month after the release of 4, and security updates will continue for 36 month. Version 2, which was released back in October of 2011 (8 years ago!), will continue to receive bugfixes for 12 months and security fixes for 18 months after the release of version 4. That’s quite a commitment!
But there’s more. Traditionally, upgrades from one major release to another are very complex, error-prone, and expensive. This is true for most software, including every PHP framework. And it was so for the CakePHP too. At least, for the upgrades from version 1 to version 2, and from version 2 to version 3.
CakePHP developers realized this problem and took a different approach for version 4. Instead of introducing all the breaking changes in one giant leap, they have provided a much simpler, gradual migration path from version 3 to version 4. This was done via the deprecated warnings. Starting from CakePHP 3.6.0, all functionality that will change in version 4 is marked with deprecated warnings. This allows the developers to fix them over time, slowly preparing for the new major version. These warnings can be disabled in production, leaving such preparations completely invisible to the end users. Once all the deprecated warnings are fixed, the application is then ready to be upgraded to CakePHP 4 with a simple change of the version constraint in composer.
We are currently involved with several client projects spanning from CakePHP 1.2, through CakePHP 2.10, all the way to CakePHP 3.8. And we think that CakePHP framework in unbeatable for both its long-term support and the easy migration from version 3 to version 4. Just these alone provide us with plenty of confidence to pick CakePHP over other frameworks any day of the week.