Laravel vs NestJS (2026): welke kies je? Lessen uit echte projecten

Lange tijd kende men me bij We Do Dev Work als "het Laravel-meisje".

Het korte antwoord: kies Laravel voor een klassieke zakelijke applicatie (accounts, betalingen, beheerschermen, wachtrijen) die een PHP-team snel moet opleveren: het neemt de meeste beslissingen voor je. Kies NestJS als de backend duidelijk aparte domeinen heeft, het team al TypeScript schrijft, of front-end en back-end dezelfde taal moeten delen. Allebei zijn ze eigenzinnig: Laravel kiest je stack, NestJS kiest je structuur.

Het was het eerste backend-framework waar ik me echt comfortabel bij voelde, en nadat ik het had gebruikt voor projecten zoals PUT-IT-ON, waar ik werkte aan betalingen, planning, queues en andere backendfunctionaliteit, begreep ik waarom. Laravel maakt me productief. Veel van de beslissingen die je bij het bouwen van een webapplicatie moet nemen, zijn al genomen, de verschillende onderdelen van het framework werken goed samen, en als je de Laravel-manier van werken eenmaal kent, kun je opmerkelijk snel vooruit.

Meer recent werk ik met NestJS, onder meer aan EngineeringScore, waar we een backend bouwen die websites scant op beveiliging, performance, SEO, toegankelijkheid en betrouwbaarheid en die resultaten dan combineert tot een transparante score. Het is een heel ander soort project, en NestJS heeft me anders doen nadenken over hoe ik backendapplicaties structureer.

De simpele conclusie zou zijn dat ik van PHP naar TypeScript ben overgestapt en ontdekte dat ik het ene boven het andere verkies, maar dat is niet echt wat er gebeurde. Ik hou nog steeds van Laravel, en er zijn genoeg projecten waarvoor ik er morgen voor zou kiezen.

Wat ik interessanter vond, is dat Laravel en NestJS op een belangrijke manier tot dezelfde familie behoren: het zijn allebei eigenzinnige (opinionated) frameworks. Ze geven je niet gewoon een verzameling tools en laten je zelf uitzoeken hoe alles in elkaar moet passen. Beide hebben sterke ideeën over hoe een backendapplicatie gebouwd moet worden.

Ze hebben alleen meningen over verschillende dingen.

Laravel neemt veel van de applicatiebeslissingen voor mij, en dat is een groot deel van waarom ik er zo productief mee ben. NestJS laat meer van die technologiekeuzes open, maar is veel explicieter over modules, dependencies en architecturale grenzen, wat waarschijnlijk is waarom het me meer over architectuur laat nadenken.

Na met beide gewerkt te hebben, besefte ik dat dit verschil veel nuttiger is bij het kiezen tussen de twee dan simpelweg PHP met TypeScript vergelijken of nog een lijst met frameworkfuncties maken.

Hoe het er in oktober 2026 voor staat

Sinds ik hierover begon te schrijven, zijn beide frameworks verder ontwikkeld, dus hier zijn de actuele feiten, gecontroleerd op de officiële sites.

• Laravel 13 werd uitgebracht op 17 maart 2026. Het vereist PHP 8.3 of nieuwer, krijgt bugfixes tot Q3 2027 en beveiligingsfixes tot 17 maart 2028 (Laravel release notes). Laravel 12 krijgt nog beveiligingsfixes tot 24 februari 2027, maar het venster voor bugfixes liep af op 13 augustus 2026. Laravel 11 heeft al geen beveiligingsondersteuning meer.

• PHP: 8.5 (november 2025) heeft actieve ondersteuning tot 31 december 2027. PHP 8.2 bereikt het einde van de beveiligingsondersteuning op 31 december 2026 (php.net), dus elke Laravel-app die nog op 8.2 draait, heeft binnenkort sowieso een PHP-upgrade nodig.

• NestJS 12 werd voor het eerst uitgebracht op 27 augustus 2026, en de laatste release op het moment van schrijven is 12.1.3 (12 oktober 2026) (NestJS releases). Het vereist Node.js 20.19+ of 22.12+, en de kernpakketten worden nu als ESM geleverd (v12.0.0 notes).

• Node.js: v24 en v22 zijn de LTS-lijnen en v26 is de huidige release; de oudere oneven en even lijnen zijn end of life (Node.js releases). Blijf voor productie op een LTS-lijn.

Een praktisch verschil: het ondersteuningsbeleid van Laravel is eenvoudig en voorspelbaar (elk jaar rond Q1 een nieuwe major, 18 maanden bugfixes, 2 jaar beveiligingsfixes). NestJS heeft zo'n vast ondersteuningsvenster niet, dus bij NestJS reken je op de nieuwste major en op het LTS-schema van Node.js. Geen van beide is een probleem, maar plan hoe dan ook elk jaar of elke twee jaar een upgrade. Weeg je ook de taalkant mee, zie dan Python vs Node.js en, voor het andere grote enterprise-duo, .NET vs Java in 2026.

Eigenzinnig zijn is een functie, geen beperking

Ontwikkelaars gebruiken "opinionated" soms alsof het een verwijt is. Een framework vertelt je hoe je iets organiseert, terwijl een minder eigenzinnige technologie je de vrijheid geeft om zelf te beslissen.

Die vrijheid klinkt aantrekkelijk, maar elke beslissing heeft een prijs.

Als een framework je niet vertelt hoe je iets aanpakt, moet iemand in het team beslissen. Je moet een bibliotheek kiezen, een patroon afspreken, het documenteren, ervoor zorgen dat iedereen het volgt en hopelijk een beslissing nemen waar je over twee jaar geen spijt van hebt.

Een eigenzinnig framework neemt een deel van die beslissingen van je over.

Dat is vooral nuttig als je in een team werkt. Als ik een Laravel-project open dat door een andere Laravel-ontwikkelaar is gemaakt, heb ik al een redelijk idee van wat ik ga aantreffen. Routes, controllers, models, migraties, jobs en commando's hebben vertrouwde plekken. De uitvoering kan natuurlijk nog steeds goed of slecht zijn, maar we beginnen tenminste met een gedeeld begrip van hoe de applicatie is georganiseerd.

NestJS biedt iets vergelijkbaars. Als ik een onbekende NestJS-applicatie open, verwacht ik modules, controllers en providers te zien. Ik verwacht dat dependencies worden geïnjecteerd in plaats van willekeurig overal in de applicatie aangemaakt. Ook hier garandeert niets hiervan goede code, maar het framework geeft de ontwikkelaars die eraan werken een gemeenschappelijke taal.

Daarom vind ik Laravel en NestJS beter vergelijkbaar dan ze op het eerste gezicht lijken. Het ene is een PHP-framework en het andere zit stevig in het TypeScript- en Node.js-ecosysteem, maar allebei proberen ze ontwikkelteams conventies te geven in plaats van een leeg doek.

Het verschil wordt interessant als je kijkt naar welke beslissingen elk framework voor je wil nemen.

Laravel neemt veel beslissingen voor je

Laravel heeft een heel complete visie op wat een webapplicatie nodig heeft.

Routing, databasemigraties, validatie, authenticatie, queues, caching, events, geplande taken en command-line tooling hebben allemaal vaste Laravel-aanpakken. Eloquent geeft je een ORM dat aanvoelt als een natuurlijke uitbreiding van de rest van het framework, terwijl tools als Artisan veel repetitieve ontwikkeltaken eenvoudig maken.

Je kunt onderdelen van dat ecosysteem vervangen als je er een goede reden voor hebt, maar meestal hoeft dat niet.

Dat heeft een enorme impact op de productiviteit.

Als ik een functie implementeer, kan ik meer tijd besteden aan de functie zelf en minder aan beslissen welk pakket elk technisch probleem moet oplossen. Er is meestal een Laravel-manier om het te doen, er is meestal goede documentatie voor, en er is een zeer grote community die waarschijnlijk al eens een soortgelijk probleem is tegengekomen.

PUT-IT-ON was voor mij een goed voorbeeld. Het platform vroeg een combinatie van functionaliteit, waaronder betalingen, planning, queues en de gewone databasezware logica die je van een bedrijfsplatform verwacht. Bij het bouwen van zoiets komen veel architecturale beslissingen kijken, maar er zijn ook veel problemen die niet uniek zijn voor het product.

Ik wil niet elke keer dat een project een queue nodig heeft een nieuwe manier bedenken om achtergrondjobs te verwerken. Ik wil geen migratiesysteem ontwerpen omdat het databaseschema veranderd is. Dat zijn niet de problemen die PUT-IT-ON uniek maken, dus met een framework dat al sterke oplossingen biedt, kan meer ontwikkeltijd naar de problemen gaan die er voor het product echt toe doen.

Dat bedoel ik als ik zeg dat Laravel me productief maakt.

Het is niet simpelweg dat PHP sneller te schrijven is, of dat Laravel een handige syntax heeft. Het is dat het framework verrassend veel beslissingen uit mijn dag haalt.

Productiviteit betekent niet dat Laravel alleen voor eenvoudige applicaties is

Hier ligt een voor de hand liggende valkuil.

Als mensen Laravel beschrijven als makkelijk te gebruiken en snel voor ontwikkeling, is de volgende conclusie vaak dat het perfect is voor kleine applicaties maar dat je iets "architecturalers" nodig hebt zodra een systeem groot wordt.

Ik vind dat niet eerlijk.

Laravel belet je niet om goede grenzen te trekken, bedrijfslogica te scheiden of een grote applicatie goed te ontwerpen. Je kunt services, actions, domains, repositories of andere patronen invoeren waar ze zinvol zijn. Laravel geeft je ruim baan om een geavanceerde applicatie te ontwerpen.

Het risico is eigenlijk een gevolg van hoe productief Laravel kan zijn.

Omdat het zo makkelijk is om nog een controllermethode toe te voegen, een Eloquent-model uit te breiden of wat meer logica in een bestaande klasse te stoppen, kun je vrij lang snel doorwerken zonder gedwongen te worden de structuur te heroverwegen. Als het ontwikkelteam niet gedisciplineerd is, kan een zeer productief eerste jaar leiden tot een veel minder productief derde jaar.

Dat is niet de schuld van Laravel. Je kunt in elk framework een vreselijke architectuur maken, ook in NestJS.

Het betekent wel dat ontwikkelaars moeten herkennen wanneer het gemak dat hen in het begin snel liet vooruitgaan, aangevuld moet worden met sterkere architecturale beslissingen naarmate de applicatie groeit.

NestJS heeft een andere mening

NestJS voelde in sommige opzichten vertrouwd, omdat het ook eigenzinnig is, maar de nadruk ligt anders.

NestJS heeft sterke ideeën over structuur.

Modules bepalen de grenzen binnen de applicatie. Controllers handelen inkomende verzoeken af. Providers bevatten functionaliteit die geïnjecteerd kan worden waar dat nodig is. Dependency injection is onderdeel van het framework in plaats van iets wat je later invoert omdat de codebase moeilijk te testen of te onderhouden is geworden.

Dat betekent dat architectuur heel vroeg in het project zichtbaar wordt.

Zelfs bij het bouwen van een relatief eenvoudige functie word je aangemoedigd na te denken over welke module eigenaar is, welke provider de logica moet implementeren en welke dependencies die provider moet hebben.

Soms is dat uitstekend.

Soms is het ook meer werk.

Bouw ik een heel eenvoudige CRUD-applicatie, dan zijn er situaties waarin de extra structuur me niet meteen veel oplevert. Nog een module, provider en DTO aanmaken is niet automatisch goede architectuur, alleen omdat alles over meer bestanden is verdeeld.

Architectuur moet complexiteit oplossen, niet creëren.

NestJS begon voor mij veel meer zin te krijgen toen ik werkte aan een backend waar de complexiteit al echt was.

EngineeringScore is een heel andere backend

EngineeringScore scant websites en beoordeelt ze op verschillende gebieden, waaronder beveiliging, performance, SEO, toegankelijkheid en betrouwbaarheid. Die resultaten moeten uiteindelijk samenkomen tot een score via een transparante en deterministische methodologie.

Vanuit productperspectief is dat één functie: scan mijn website en vertel me hoe goed de engineering ervan is.

Vanuit backendperspectief is het een verzameling vrij uiteenlopende verantwoordelijkheden.

Een performance-scan hoeft niet te weten hoe toegankelijkheid gemeten wordt. Beveiligingschecks hebben andere eisen dan SEO-checks. Het onderdeel dat de eindscore berekent, hoeft niet elk implementatiedetail te begrijpen van de scanners die de onderliggende resultaten leveren.

Er zijn ook externe diensten, API's en achtergrondprocessen bij betrokken, waardoor de backend vanzelf meerdere grenzen heeft.

In die omgeving wordt de structuur die NestJS aanmoedigt heel nuttig.

In plaats van te vragen hoe we al deze functionaliteit in één applicatie krijgen, kunnen we nadenken over de verschillende domeinen binnen die applicatie en bepalen hoe ze communiceren. Dependency injection maakt die relaties expliciet, terwijl modules ons een natuurlijke plek geven om grenzen te trekken.

Dat bedoel ik als ik zeg dat NestJS me meer over architectuur laat nadenken.

Het is niet dat NestJS op magische wijze betere architectuur maakt. Een slecht ontworpen NestJS-applicatie kan nog steeds tientallen modules hebben met onduidelijke verantwoordelijkheden en dependencies die overal heen gaan.

Het verschil is dat het framework me voortdurend architecturale vragen voorlegt.

Bij Laravel heb ik vaak het gevoel dat het framework vraagt: "Wat wil je bouwen?"

Bij NestJS stel ik mezelf vaker de vraag: "Waar hoort dit thuis?"

Beide zijn nuttige vragen.

NestJS geeft je structuur, maar je moet nog steeds keuzes maken

Er is nog een belangrijk verschil.

De meningen van Laravel reiken vrij ver in de technologiestack. Eloquent is de voor de hand liggende databasekeuze. Laravel heeft zijn eigen queuesysteem, migratiesysteem, authenticatieoplossingen en een breed ecosysteem van first-party of nauw geïntegreerde tools.

NestJS geeft je een sterke applicatiestructuur maar laat meer van de omliggende keuzes open.

Je kunt Prisma of TypeORM gebruiken. Je moet beslissen hoe persistentie moet werken. Er zijn verschillende aanpakken voor queues en achtergrondverwerking. Zelfs het onderliggende HTTP-platform ligt niet helemaal vast.

Voor sommige teams is die flexibiliteit precies wat ze willen. Voor anderen is het gewoon een langere lijst beslissingen.

Geen van beide is automatisch beter.

Als de technische eisen van de applicatie ongebruikelijk zijn, kunnen die keuzes waardevol zijn omdat je niet vecht tegen aannames van het framework. Bouw je iets relatief conventioneels, dan kan het nemen van die beslissingen simpelweg betekenen dat je tijd besteedt aan problemen die Laravel al voor je heeft opgelost.

Dit is waarschijnlijk de belangrijkste reden dat ik de vergelijking niet langer zie als PHP versus TypeScript.

Het is echt een vraag van waar je wilt dat het framework beslist en waar je wilt dat je engineeringteam beslist.

TypeScript is nog steeds een belangrijke reden

De taal is natuurlijk niet irrelevant.

Bij We Do Dev Work gebruiken we TypeScript uitgebreid, vooral op de frontend, dus NestJS heeft een duidelijk organisatorisch voordeel. Ontwikkelaars die al met TypeScript vertrouwd zijn, hoeven niet van taal te wisselen als ze tussen frontend- en backendwerk schakelen, en we kunnen vergelijkbare tooling en ontwikkelpraktijken voor beide gebruiken.

Voor een full-stack TypeScript-team is dat echt nuttig.

Maar ik zou niet voor NestJS kiezen puur omdat "één taal overal" netter klinkt op een architectuurdiagram.

Een team van ervaren Laravel-ontwikkelaars wordt niet ineens productiever omdat het management besloot dat TypeScript moderner is. Bestaande expertise telt, en het ecosysteem rond een bestaande applicatie ook.

De technologiekeuze moet de mensen omvatten die ermee gaan werken.

Dat is vooral belangrijk voor een bureau, omdat we niet eenmalig ons favoriete framework kiezen en het dan voor altijd gebruiken. Verschillende klanten hebben verschillende bestaande systemen, verschillende interne teams, verschillende eisen en verschillende plannen over wie de software na de lancering onderhoudt.

Soms is Laravel de duidelijke keuze. Soms NestJS. Soms geen van beide.

Wanneer zou ik dus voor Laravel kiezen?

Na met beide frameworks gewerkt te hebben, zou ik naar Laravel neigen wanneer de applicatie meer baat heeft bij het geïntegreerde ecosysteem dan bij het blootleggen van elke architecturale keuze.

Typische voorbeelden zijn:

• Een bedrijfsapplicatie met veel CRUD- en databasefunctionaliteit.

• Een platform dat authenticatie, queues, geplande jobs, notificaties en vergelijkbare gangbare backendfunctionaliteit nodig heeft.

• Een project waarbij het bijzonder belangrijk is om snel een solide eerste productieversie online te krijgen.

• Een applicatie die gebouwd of onderhouden wordt door een team met sterke PHP- en Laravel-ervaring.

• Een project waarbij de bestaande conventies van Laravel de meeste technische problemen rond de eigenlijke bedrijfslogica al oplossen.

Daarom werkte Laravel zo natuurlijk voor iets als PUT-IT-ON. Er was veel maatwerk-bedrijfslogica te bouwen, maar er waren ook veel conventionele webapplicatieproblemen waarbij ik de vrijheid om een eigen oplossing te bedenken niet nodig had.

Ik had nodig dat ze werkten.

Laravel liet me daarop focussen.

En wanneer zou ik voor NestJS kiezen?

Ik zou naar NestJS neigen wanneer de structuur van de backend zelf een belangrijk deel van de engineeringuitdaging is.

Bijvoorbeeld:

• Een applicatie met meerdere duidelijk gescheiden domeinen.

• Een backend die meerdere externe API's of diensten coördineert.

• Systemen met meerdere workers of processen die verschillende verantwoordelijkheden uitvoeren.

• Een sterk op TypeScript gericht ontwikkelteam waarin frontend- en backendkennis vaak overlappen.

• Applicaties waarin expliciete dependency-grenzen steeds belangrijker worden naarmate het product groeit.

• Projecten waarin we bewust meer controle willen over persistentie, infrastructuur of andere delen van de backendstack.

EngineeringScore past veel natuurlijker in die categorie. De scandomeinen, de scorelogica en de ondersteunende diensten geven ons echte grenzen om te modelleren, dus de architecturale structuur is er niet omdat NestJS ons zei die te maken. Ze is er omdat het product die complexiteit echt heeft.

Dat is een belangrijk onderscheid.

Laravel vs NestJS in één oogopslag

Welke moet je kiezen?

Mijn vuistregels, in de volgorde waarin ik ze toepas:

1. Begin bij het team. Als de mensen die het gaan onderhouden sterk zijn in PHP, kies dan Laravel. Als ze elke dag in TypeScript leven, kies dan NestJS. Een framework dat je team kent, wint van een framework dat er op papier beter uitziet.

2. Is de backend vooral conventioneel? Logins, betalingen, e-mails, queues, adminschermen en rapporten: kies Laravel en besteed je tijd aan de bedrijfslogica.

3. Heeft het product echt gescheiden domeinen? Meerdere scanners, workers of externe API's die niets van elkaar mogen weten: kies NestJS.

4. Moet je snel lanceren? Laravel brengt je meestal eerder bij een solide eerste release.

5. Deel je code met een TypeScript-frontend? NestJS maakt gedeelde types en tooling makkelijk.

6. Nog steeds onbeslist? Kies degene die het team kent, en schrijf hoe dan ook de module- of domeingrenzen op. Goede grenzen doen er meer toe dan het framework.

Wil je een tweede mening over een echt project, bekijk dan onze projecten of praat met ons over een dedicated team. En als je al een Laravel- of NestJS-app hebt en niet zeker weet hoe gezond die is, kun je die laten halen door EngineeringScore, de gratis website-audit die we met NestJS bouwden.

Wat ik nu vraag voor ik kies

Een paar jaar geleden zou ik waarschijnlijk Laravel gekozen hebben, simpelweg omdat ik het het best kende. Dat is trouwens niet per se een slechte reden. Productief zijn met een technologie die je begrijpt is vaak waardevoller dan het in theorie perfecte framework kiezen dat je nooit in productie hebt gebruikt.

Vandaag zou ik de beslissing bewuster nemen.

Voor ik tussen Laravel en NestJS kies, zijn dit de vragen die ik wil beantwoorden:

• Wat voor soort applicatie bouwen we eigenlijk?

• Hoeveel van de backend is conventionele webapplicatiefunctionaliteit?

• Waar zit de echte complexiteit in het product?

• Valt die complexiteit vanzelf uiteen in afzonderlijke domeinen?

• Hoeveel externe systemen en API's gaat de backend coördineren?

• Hoe snel moeten we een bruikbare productieversie bereiken?

• Welke technologie kent het bestaande team het best?

• Gaan ontwikkelaars regelmatig over zowel frontend als backend werken?

• Hebben we baat bij het kiezen van onze eigen infrastructuurcomponenten, of creëren we gewoon beslissingen die we niet nodig hebben?

• Wie gaat deze applicatie onderhouden na twee of drie jaar ontwikkeling?

Die laatste vraag waardeer ik steeds meer naarmate ik aan grotere projecten werk.

Een frameworkkeuze gaat niet alleen over hoe prettig de eerste sprint aanvoelt. Je kiest de conventies die toekomstige ontwikkelaars aantreffen wanneer ze het project openen nadat honderden functies, integraties, fixes en wijzigingen zich hebben opgestapeld.

Het beste framework is dus niet noodzakelijk degene waarmee je het snelst het eerste endpoint schrijft, en ook niet automatisch degene die je de meeste architecturale tools geeft.

Het is degene waarvan de meningen passen bij de applicatie die je echt bouwt.

Ben ik nog steeds het Laravel-meisje?

Waarschijnlijk wel.

Ik werk nog steeds graag met Laravel, en er zijn veel projecten waarvoor de productiviteit en het geïntegreerde ecosysteem het mijn eerste keuze zouden maken. Werken met NestJS heeft me er niet van overtuigd dat Laravel het verkeerde framework was; het heeft me simpelweg een andere manier gegeven om over backendontwikkeling na te denken.

Mijn oorspronkelijke gevoel over de twee frameworks is ook niet echt veranderd: Laravel maakt me productief, terwijl NestJS me meer over architectuur laat nadenken.

Wat wel veranderd is, is dat ik beter begrijp waarom.

Laravel is eigenzinnig over een groot deel van de applicatiestack en haalt veel beslissingen weg die ik gewoon niet bij elk project hoef te nemen. NestJS is eigenzinnig over structuur en maakt modules, verantwoordelijkheden en dependencies veel explicieter, terwijl het meer van de omliggende technologie in onze handen laat.

Daarom vind ik dat ze in hetzelfde gesprek thuishoren, ook al komen ze uit totaal verschillende ecosystemen. Beide frameworks proberen ontwikkelaars te helpen omgaan met de complexiteit van het bouwen en onderhouden van backendapplicaties; ze kiezen er alleen voor verschillende soorten complexiteit weg te nemen.

En na met beide gewerkt te hebben, is dat de vraag die ik nu zou stellen voor ik tussen de twee kies: welke beslissingen wil ik door het framework laten nemen, en welke zijn belangrijk genoeg dat ik ze zelf wil nemen?

Bronnen

• https://laravel.com/docs/13.x/releases
• https://www.php.net/supported-versions.php
• https://nodejs.org/en/about/previous-releases
• https://github.com/nestjs/nest/releases
• https://github.com/nestjs/nest/releases/tag/v12.0.0