Waarom we in 2026 nog steeds voor Laravel kiezen

Een framework kiezen in 2026 is vooral een onderhoudsbeslissing vermomd als een technische. De code wordt één keer geschreven en jaren gelezen, meestal door iemand die er niet bij was toen de keuzes gemaakt werden. Dat is de lens die de moeite waard is.

Het argument is samenhang, niet features

Elk volwassen ecosysteem kan queues, geplande jobs, authenticatie, mail, bestandsopslag, databasemigraties en een testsuite. Het verschil is of die binnenkomen als één systeem dat samen is ontworpen, of als een dozijn packages die elk hun eigen keuzes maakten.

Laravel geeft je het eerste. Een queued job, een gepland commando en een mailable zien eruit als dezelfde codebase, gebruiken dezelfde container, en worden op dezelfde manier getest. De queuedriver wisselen van database naar Redis is een configuratiewijziging, geen herschrijving.

Die samenhang heeft een samengesteld effect dat benchmarks niet vangen: een engineer die een onbekende Laravel-applicatie opent, weet al waar de routes staan, hoe validatie wordt uitgedrukt, en wat een service provider doet. Op een project met één of twee mensen en een levensduur van vijf jaar is dat de dominante kostenfactor.

Wat er de afgelopen jaren veranderd is

Twee dingen die het noemen waard zijn, omdat bezwaren tegen PHP vaak tien jaar oud zijn.

PHP 8 is écht snel. Getypte properties, enums, readonly classes, constructor promotion en een echte JIT. Een moderne PHP-codebase leest als een moderne getypte taal, en de runtime is competitief voor I/O-gebonden webwerk, wat bijna al het webwerk is.

Server-gedreven interactiviteit werd goed. Livewire, Hotwire en htmx landden allemaal op hetzelfde inzicht: het meeste “interactieve” UI is een formulier, een filter, een modal of een lijst, en een client-side framework daarvoor shippen is een slechte ruil. Staat op de server houden betekent één taal voor businesslogica en één plek waar validatie en autorisatie wonen.

We gebruiken Livewire selectief, niet overal. Deze site is het voorbeeld: de marketingpagina’s zijn gewone server-gerenderde templates met een paar kilobytes Alpine voor de navigatie, en alleen het contactformulier laadt een component-runtime. Een staatloze pagina wint niets bij een componentframework en betaalt ervoor in payload.

Waar Laravel slechter in is

Een eerlijk argument heeft dit deel nodig.

Langlevende verbindingen. Het request-responsemodel is niet waar een WebSocket-zwaar product wil wonen. Laravel heeft stevige antwoorden (Reverb, Octane), maar als presence, cursors en live samenwerking het product zijn, begint een runtime die om persistente verbindingen heen is gebouwd voorop.

CPU-gebonden werk. Beeld- en videoverwerking, numerieke berekening, alles waarvoor je een native library zou pakken. Zet het op een queue en een dedicated worker, of schrijf dat deel in iets anders. Het framework is niet het juiste gereedschap, en doen alsof eindigt slecht.

De eigen conventies van het ecosysteem. Facades en magic methods maken snel schrijven mogelijk en slechtere statische analyse dan een expliciet bedraad equivalent. Dat is een echte ruil. We mitigeren het met getypte signatures en PHPStan, niet door te doen alsof het er niet is.

Frontendverwachtingen. Als het ontwerp écht een app-achtige client vraagt (offline support, overal optimistic updates, complexe client-side state) vecht een server-gedreven aanpak je tegen. Gebruik het juiste gereedschap.

Waar we anders zouden kiezen

• Een real-time collaboratieve editor: iets gebouwd rond persistente verbindingen.
• Een machinelearningpipeline: Python, waar de libraries wonen.
• Een high-throughput event-ingestieservice: Go, en houd het saai.
• Een statische contentsite zonder applicatie erachter: een static site generator, en helemaal geen server.

Geen van die zijn Laravel-zwaktes, zozeer als Laravel geen universeel antwoord is.

Het echte criterium

Voor de applicaties die we meestal gevraagd worden te bouwen (een bedrijfsproces met een database erachter, integraties met diensten waar de klant al voor betaalt, een paar duizend gebruikers, en een verwachte levensduur van tien jaar) is de vraag niet welke stack het hoogste plafond heeft. Het is welke stack een bekwame maintainer in 2032 nog kan bewerken zonder een archeologiefase.

De conventies, documentatie en upgrade-discipline van Laravel maken dat waarschijnlijk. Dat is een saaie reden om een framework te kiezen, en het is de reden die standhoudt.