When we started Web Wisteria, Laravel 4 had just been released. We chose it tentatively, half-expecting to outgrow it. Twelve years and dozens of projects later, it's still the backbone of almost everything we build. That longevity deserves an explanation.
The conventions that actually hold up
Most frameworks age poorly because the conventions they enforce in version 1 become liabilities by version 5. Laravel has done something unusual: it's added enormous capability while keeping its API surface readable by someone who learned it three years ago. The upgrade path from Laravel 10 to Laravel 11 was the least painful major upgrade we've done in any stack.
Part of that is Taylor Otwell's design instinct. Part of it is the community's willingness to deprecate bad patterns rather than maintain them for compatibility's sake. Either way, the result is a framework where knowing it well actually compounds over time.
What Eloquent gets right
ORMs are a perennial argument in developer circles. The ActiveRecord pattern has genuine critics, and they're not entirely wrong - Eloquent can encourage lazy loading patterns that kill performance at scale, and the magic behind $model->relationship can obscure what's actually happening at the database level.
But for the size of project we typically work on - hundreds of thousands to low millions of records - Eloquent's ergonomics are worth the tradeoffs, as long as you're disciplined about eager loading and know when to drop down to the query builder.
We've shipped projects where Eloquent handled the business logic beautifully, and then optimised the three or four hot paths with raw SQL when it mattered. That escape hatch is always there and never feels dirty to use.
Where we've felt the limits
The places we've genuinely pushed against Laravel's edges:
- Real-time applications. Laravel Reverb has improved the story here considerably, but for anything with genuinely complex pub/sub requirements, we've sometimes reached for Node services alongside a Laravel API.
- Heavy queue workloads. Horizon is good. It's not Kafka. When throughput requirements started climbing into the hundreds of thousands of jobs per hour, we looked elsewhere for that layer.
- Microservices. Laravel is opinionated in ways that fight you when you're trying to build very small, stateless services. For those cases, we've had success with Lumen historically, or just bare PHP with a minimal router.
None of these are criticisms so much as honest observations about what the framework optimises for. Laravel is a full-stack web application framework, and it's exceptional at that. When you need something different, it doesn't pretend otherwise.
The ecosystem argument
The practical reason we keep choosing Laravel for new projects is the ecosystem. Cashier for billing. Sanctum for API auth. Scout for search. Socialite for OAuth. These are mature packages maintained by people who understand the framework's idioms. Starting a project with Laravel means not solving ten already-solved problems before you get to the interesting work.
In 2026, that's still a genuine advantage.