I’ve known about Laravel since I first started investigating PHP frameworks years ago. At the time, I didn’t feel that it was the best choice for the site I was managing. But it has continued to grow and, today, it’s far and away the leading PHP framework.
Still, I resisted digging into it. I have long been a CakePHP fan, and it was something I knew.
In my current day job, they needed an app. All of the important corporate data is stored in spreadsheets… not even Google Sheets most of the time, but old-fashioned pass-the-file-around spreadsheets. They wanted an application to fill this gap, and I set about trying to decide what to write it in.
My first two considerations were CakePHP and WordPress. (The former because I knew it; the latter because they were rather entrenched in WordPress already.) While you can create an entire application with WordPress as the basis, I don’t see a reason to do that unless there are needs that encompass a lot of the existing WordPress functionality. (Otherwise you have a ton of overhead without a good reason.) So I spent most of my time with CakePHP (version 4 is out) and, sadly… I got frustrated… a lot.
I decided to look at Laravel. The rest, as they say, is history. But let me give you an overview of why I love it so much.
Laravel uses Blade (built for Laravel) as its templating tool. I’ve used Twig, Plates, and of course CakePHP’s templates, and Blade smokes them all. Twig comes close in some ways, but Twig won’t let you run PHP from a template. Blade has all the features you might want, some you didn’t know you needed, and it’s simple to understand and use.
CakePHP’s ORM (Object Relational Mapping) for database access has always frustrated me. In CakePHP, you can run straight MySQL queries, but to do so you nix a lot of the existing database benefits of using a framework. In Laravel, it’s just another command, no special connection and the other database benefits are still there. That said, the ORM as it stands is very understandable and very functional; the only thing I’ve had trouble with so far is a UNION ALL with four tables… for that, I had to revert to a “raw” query.
While you can use Laravel without these things, if you want to include one, a single command integrates it. And it’s consciously integrated, meaning there’s a plan in place for how these tools will work together.
I’ve never met better documentation in my life. Period. It’s so well arranged that learning the framework has been a breeze. Plus, since it’s the leading framework, there’s a ton to be found with Google searches.
Authentication and authorization
Laravel will scaffold it for you, but obviously one needs to make tweaks. CakePHP, in my opinion, made their auth even crazier with version 4, so I really wanted to find something where auth was solid and easy to use. (Even email verification is built in!)
Who even knows what this is?! Well, I do, now. Using it in Laravel is as simple as putting a new function in the proper folder and they explicitly tell you how and when it will be executed. It’s about as easy as hooking into WordPress.
I don’t know that migrations in Laravel are any better than any others, but they’re likewise very clear and understandable. I’m now doing 100% of the database from migrations, which is awesome because when I deploy I just need to run them and the database work is done.
PHPStorm knows Laravel. When you write a command for which you don’t have the right “use” in place, PHPStorm will prompt you to include it. No more digging around in API lists trying to find (and in my case sometimes giving up in frustration with CakePHP) the right thing to include to make your code work.
Best tech decision I’ve ever made. No kidding.
Expect to see a whole lot of Laravel posts (if I can tear myself away from coding in it) in the coming weeks.