Why we still choose Laravel in 2026

Choosing a framework in 2026 is mostly a maintenance decision disguised as a technical one. The code gets written once and read for years, usually by someone who was not there when the decisions were made. That is the lens worth applying.

The case is coherence, not features

Every mature ecosystem can do queues, scheduled jobs, authentication, mail, file storage, database migrations and a test suite. The difference is whether those arrive as one system that was designed together, or as a dozen packages that each made their own choices.

Laravel gives you the first. A queued job, a scheduled command and a mailable all look like the same codebase, use the same container, and are tested the same way. Swapping the queue driver from database to Redis is a configuration change, not a rewrite.

That coherence has a compounding effect that benchmarks do not capture: an engineer opening an unfamiliar Laravel application already knows where the routes are, how validation is expressed, and what a service provider does. On a project with one or two people on it and a five-year life, that is the dominant cost factor.

What has changed in the last few years

Two things worth naming, because objections to PHP tend to be a decade old.

PHP 8 is genuinely fast. Typed properties, enums, readonly classes, constructor promotion and a real JIT. A modern PHP codebase reads like a modern typed language, and the runtime is competitive for I/O-bound web work, which is nearly all web work.

Server-driven interactivity got good. Livewire, Hotwire and htmx all landed on the same insight: most “interactive” UI is a form, a filter, a modal or a list, and shipping a client-side framework to handle those is a poor trade. Keeping state on the server means one language for business logic and one place where validation and authorisation live.

We use Livewire selectively rather than everywhere. This site is a case in point: the marketing pages are plain server-rendered templates with a few kilobytes of Alpine for the navigation, and only the contact form loads a component runtime. A stateless page gains nothing from a component framework and pays for it in payload.

What Laravel is worse at

An honest argument needs this part.

Long-lived connections. The request-response model is not where a WebSocket-heavy product wants to live. Laravel has solid answers (Reverb, Octane), but if presence, cursors and live collaboration are the product, a runtime built around persistent connections starts ahead.

CPU-bound work. Image and video processing, numerical computation, anything you would reach for a native library to do. Push it to a queue and a dedicated worker, or write that part in something else. The framework is not the right tool and pretending otherwise ends badly.

The ecosystem’s own conventions. Facades and magic methods make for fast writing and worse static analysis than an explicitly wired equivalent. It is a real trade. We mitigate it with typed signatures and PHPStan rather than by pretending it does not exist.

Frontend expectations. If the design calls for a genuinely app-like client (offline support, optimistic updates everywhere, complex client-side state) a server-driven approach fights you. Use the right tool.

Where we would choose differently

• A real-time collaborative editor: something built around persistent connections.
• A machine learning pipeline: Python, where the libraries live.
• A high-throughput event ingestion service: Go, and keep it boring.
• A static content site with no application behind it: a static site generator, and no server at all.

None of those are Laravel weaknesses so much as Laravel not being a universal answer.

The actual criterion

For the applications we are usually asked to build (a business process with a database behind it, integrations with services the client already pays for, a few thousand users, and a ten-year expected life) the question is not which stack has the highest ceiling. It is which stack a competent maintainer can still work on in 2032 without an archaeology phase.

Laravel’s conventions, documentation and upgrade discipline make that likely. That is a boring reason to choose a framework, and it is the one that has held up.