It's hard to believe but we started working with the Laravel framework back in 2015. The framework was at version 5.1 when we first installed it and php hadn't released PHP 7 yet, seems like a long time ago now.
During these years we've built and worked on a lot of Laravel applications, from our home-rolled CMS right through to auditing software for blue chip companies. Given this level of exposure to the framework we've seen many examples of where it excels and empowers teams and a couple where it's hamstrung development because of poor choices by the development team.
Here are 5 hot takes on Laravel after 9 years of using it:
1. It will scale for 99% of use cases
A standard criticism of Laravel has always been "but it (and PHP) won't scale". This just isn't true, I'm not sure when it ever was if you're just comparing to the other frameworks available. Given the speed of PHP 8, the JIT, Laravel Octane/Swoole/FrankenPHP and the availability of cheap compute power available in the cloud, Laravel and php won't be what holds you back. If you're at Facebook scale you'll have decisions to make that will probably need custom solutions, but for the rest of us and our 10s of thousands of users it's just not going to be the bottleneck you hit first.
As some personal experience, we've been running a website with millions of page reads on a relatively modest digital ocean droplet, some of the pages hit the MySQL database pretty hard but the response times are always fast, certainly faster than most social media sites/apps. The site has had bursts of traffic and is constantly being hammered by bots, the performance is solid and has plenty of room for more traffic before we even think about scaling the hardware. We've also been running a complicated multiplayer game where Laravel handles all of the inputs and user interactions with realtime game play. It just doesn't go wrong, lag or give us any issues at all.
2. It can be used in large complex domains
This is another one that we often hear, Laravel isn't 'Enterprise'. I've personally worked on several projects for blue chip organisations where Laravel is powering a major part of their technology, from global auditing services to powering the backend for apps in use by thousands of employees out in the field. I've seen it working at scale powering businesses who are making a lot of money, if you think it's just for blogs then I'd encourage you to get some experience on large projects using it, lots of them are always looking for good contractors so there's plenty of opportunity to work with it.
3. It has encouraged adoption of unit testing
Given that Laravel ships with the basic steps of setting up testing already covered I'm confident that this has led to more applications having at least some level of testing included. Even if the tests are simple 'check this page loads and contains this' it's something that you just don't see that much in legacy php applications, maybe this is because of the complexity of making the application testable or maybe just that testing wasn't a consideration beyond hitting F5 in the browser until it does what you expect.
4. It can lead to inefficient code that becomes a problem when databases grow
This is something I see quite often on projects and it's generally always down to a lack of thought of what the Eloquent ORM is actually doing behind the scenes when you use some of its features. The usual issues are where models always automatically append relationships or where relationships are eager loaded and then queried in large numbers. This can quite often lead to huge memory usage to build collections of nested objects when the objective was actually to count something, a query that could have been trivial.
This is more a problem of the active record pattern than Laravel itself, infact Laravel offers ways to deal with some of these challenges. But it's definitely a trap that's easy to fall into given how developer friendly Eloquent is when it comes to building complicated related models.
5. The abundance of packages isn't always a good thing
This is probably more of a personal thing but I see a tendency amoungst Laravel developers to reach for packages without really considering if they really need these dependencies in their applications. For big things like OAuth implementations, SSO, graphics libraries etc then packages are great. Where they're not so great is when they're just a thin wrapper to integrate another package into Laravel, I've seen some of these wrappers abandoned and left projects with tricky upgrade paths as they've made decisions about how to integrate with a library that has since changed. These wrapper packages will add dependencies to the app that could have been avoided with a small amount of work to build your own wrapper or integration for the underlying library, it's then up to you how you upgrade it. There's another tendency to use packages for things that are quite simple, or using a package just to access a single method that could have been implemented in a few lines.
This again isn't really a criticism of Laravel, it's more of a personal preference to avoid as many dependencies as possible, and this seems to be at odds with the general approach of the community (that I've seen anyway). That said, this is nothing compared to the dependency anxiety I get when working with Javascript applications!
So there you go, 5 things I've noticed over the 9 years of working with Laravel. In summary it's a great experience to work with it, and with thoughtful coding you can have a full featured application that's painless to update to the latest versions, just don't fall into the dependency traps or start extending parts of the framework, when you're extending classes deep in the framework stop and back up a bit and think of your future self.
