The switch, from CakePHP to LaravelCategories: Laravel, CakePHP, Framework, PHP
CakePHP is a good framework, and we have experienced that it works well with modern development practices, like test driven development, dependency management, cloud deployment, migrations, caching and rapid development. Cake has been our main framework for more than 3 years now and it has been awesome. We have learned a lot but it is time to move on.
Tl;dr: Laravel will be our main web development framework for the next year or so. We are going to switch to Laravel and we have a couple of reasons why.
- Laravel enables true “Rails-like” development for PHP and goes beyond just that.
- Laracasts.com is the most awesome learning resource out there, right now!
- We believe Laravel has a bright future.
After discussing our considerations I will discuss the consequences of the switch and how it will affect the development of our rapid-back-end creation library Auja.
Beyond true “Rails-like” development
CakePHP was of course heavily inspired by Rails. Back in the day, things like a command-line utility and migrations where fairly new to the PHP community. These did seem awesome. However, while we tried to use these features we often ran into problems.
- The structure of migrations was difficult to understand.
- I18N translations were a pain.
- Executing commands in the command-line on Windows wasn’t always easy.
- Difficult Travis CI configuration.
- We’ve tried using CakePHP with Composer but it wasn’t always trivial to load plug-ins or the framework itself.
Because of these problems we regrettably often didn’t use features like migrations and composer, mainly because a deadline was always right around the corner. It left us with a bad feeling that the code architecture could have been better if we just had the time to tackle these problems.
We have played around with Rails two years ago and noticed it didn’t have these kinds of problems. Dependency management was particularly nice with Bundler and Gems. However Rails had a whole other class of issues. Rails installation took literally more than an hour on computers that where not that old. And deployment was not trivial.
When we started experimenting with Laravel our mouths fell open. Laravel was basically all the goodness of Rails and PHP combined—no deployment pains, a great extendable command-line utility, very good dependency management integration, painless Travis CI configuration and great migrations.
Rails has CodeSchool and RailsCasts, CakePHP never had a learning resource with that level of polish. So we learned the framework by reading the documentation. I know some of you may disagree, but the truth is: “documentation is boring” and nobody is going to read all relevant pages before starting a project. Furthermore documentation does not explain why things are the way they are and do not often lead to a deeper understanding.
Laracasts was a real eye-opener, it showed everyone who was unfamiliar with Laravel all the relevant information to get a project going immediately. Our designers now know their way around Laravel, thanks to Jeffery Way. And this is not because we’ve forced them to learn this stuff—no they actually find it very interesting.
Our developers learned a lot of new things too. Sometimes it is very difficult to explain why a developer should test their application or use a certain pattern. Laracasts is great at showing why things are the way they are, and give developers new insights.
Laravel is booming, especially in the Netherlands. We have seen how easy it is and are confident other developers will pick it up. If you search on Google Trends for Laravel and CakePHP you can see that Laravel has surpassed CakePHP as a popular search term. The Laravel framework is focused on the future and backwards compatibility isn’t an issue—yet. Therefore it can get the most out of all the new PHP language features as well as support HHVM.
Auja and the future of our Cake libraries
Earlier this year we decided that Label305 will be a company that embraces open source. We even made it one of our core values. We wanted to open source our interface library Auja, with which you can create a back-end for a web application extremely fast. But our first core value has to do with ease-of-use, and using the library frankly wasn’t that easy for the developer. The library was written to our very specific way of working and therefore useless for most projects out there. Now that we are making the switch to Laravel we are confronted with that very same problem ourselves, the CakePHP library isn’t useful for a Laravel project.
We are open to new technologies and always want to use different kinds. So we gladly want to work on your PHP, Node.js, Python and Ruby projects. We will of course still support all CakePHP projects and continue to follow the framework. But for new web applications with a relatively standard architecture we will use Laravel.