Laravel vs Next.js: hvad skal du vælge til dit projekt?

Laravel vs Next.js er ikke et valg mellem to udgaver af det samme. Laravel er et backend-framework i PHP, bygget til data, brugere og forretningslogik, mens Next.js er et React-framework der er stærkest til hurtige, søgemaskinevenlige sider og interaktive brugerflader. Min tommelfingerregel er at vælge Laravel når det svære ligger i systemet bag skærmen, Next.js når det ligger i siderne og oplevelsen foran, og en kombination når begge dele er store.

Jeg arbejder selv i begge, og Laravel-udvikling er en af de ydelser jeg sælger. Læs med det forbehold. Jeg har forsøgt at være lige så tydelig om hvornår Laravel er det forkerte valg.

Den korte version: hvad er forskellen?

Tabellen er en grov sortering, ikke en dom. Valget af framework er kun én del af hvad en tech stack er, og det er sjældent det alene der afgør om et projekt lykkes. Vil du se hvor beslutningen hører hjemme i et samlet forløb, har jeg beskrevet hvordan et udviklingsprojekt foregår fra idé til drift.

Hvad Laravel er stærkest til

Laravel kommer med det meste indbygget. Databaselag, validering, login, rettigheder, e-mails, notifikationer, filupload, køer til baggrundsjob og planlagte opgaver er en del af frameworket og dokumenteret samme sted. Det betyder færre valg i starten og færre løse dele at holde opdateret bagefter.

Det passer til projekter hvor det svære ligger bag skærmen. Tænk på en kundeportal hvor hver kunde kun må se sine egne data, et bookingsystem med regler for kapacitet og afbud, en SaaS med abonnementer og fakturaer eller en integration der synkroniserer ordrer med et økonomisystem hver nat. Den slags handler om datamodeller, rettigheder og opgaver der skal køre pålideligt i baggrunden, og det er præcis det Laravel er bygget til.

Laravel udgiver én stor version om året. Laravel 13 kom 17. marts 2026 og får sikkerhedsrettelser frem til marts 2028 ifølge Laravels officielle udgivelsesnoter. Den faste rytme gør det lettere at planlægge opdateringer og sætte penge af til dem.

Et punkt mange overser: Laravel betyder ikke en gammeldags brugerflade. Laravels officielle startpakker giver dig en React-frontend med TypeScript og Tailwind via Inertia, et lille bindeled der lader Laravel styre ruter og data, mens React tegner siderne. Du får altså en moderne React-app i én kodebase med én udgivelse. Vil du helst blive i PHP, findes Livewire, hvor interaktive komponenter skrives uden ret meget JavaScript. Jeg har samlet resten af argumenterne i hvorfor Laravel er mit standardvalg til webapps.

Hvad Next.js er stærkest til

Next.js er et framework oven på React, udviklet af Vercel. Styrken er siderne. De kan renderes på serveren eller bygges på forhånd, så de loader hurtigt og er lette for Google at læse. Det gør Next.js oplagt til marketingsider, indholdstunge sites koblet på et headless CMS (et indholdssystem uden egen frontend), frontends til webshops og produkter hvor brugerfladen er selve produktet.

Next.js har også en serverdel. Route Handlers og Server Actions kan modtage formularer, hente data fra en database og tage imod webhooks fra andre systemer. Men dokumentationen er selv ærlig om grænsen: Next.js' backend-funktioner er ikke en fuld erstatning for en backend, men et API-lag. Login, databaseadgang, køer og planlagte opgaver vælger og samler du selv fra forskellige biblioteker og tjenester.

Hosting er det andet du skal kende. Den nemme vej er Vercel, firmaet bag Next.js. Du kan også køre Next.js på din egen Node.js-server eller i Docker, og ifølge Next.js' guide til udgivelse understøtter begge dele alle funktioner. Kører du på en platform der afvikler koden som serverless-funktioner (små stykker kode der startes ved hver forespørgsel), advarer dokumentationen til gengæld om at langvarige opgaver kan blive afbrudt af tidsgrænser, og at WebSockets ikke virker.

Next.js udvikler sig hurtigt. Version 16 er den aktuelle, og ifølge Next.js' supportpolitik får den forrige hovedversion kun kritiske rettelser i op til to år efter sin udgivelse. Det giver mange nye muligheder, men grundlæggende ting som routing og caching har også ændret sig flere gange de seneste år. Sæt tid af til opdateringer.

Hvornår Laravel eller Next.js ikke passer

Hvornår du ikke skal vælge Laravel

• Når projektet primært er en marketingside eller et indholdssite, hvor redaktører arbejder i et headless CMS, og design, animationer og indlæsningstid er det der sælger. Laravel kan sagtens klare det, men Next.js er bygget til netop det.
• Når dit eget team kun skriver JavaScript eller TypeScript og selv skal vedligeholde koden. Ét sprog i hele løsningen er en reel fordel, og den skal du ikke ofre for min præference.
• Når du bare har brug for en enkel hjemmeside med få sider. Så er et framework sjældent svaret, og et CMS eller en sidebygger er ofte billigere.

Hvornår du ikke skal vælge Next.js

• Når det meste af systemet er formularer, data, rettigheder, rapporter og integrationer. Så ender du med at bygge din egen backend af løse dele, og hver del er en afhængighed der skal opdateres og måske betales for.
• Når der skal køre tunge eller langvarige opgaver i baggrunden, fx import af store filer, generering af PDF'er eller synkronisering om natten. Det kræver en ekstra tjeneste ved siden af.
• Når løsningen skal vedligeholdes i roligt tempo af én udvikler i mange år. Next.js' hurtige udvikling koster opdateringstid, og det mærker et lille budget.

Ingen af de to er et dårligt valg i sig selv. Problemerne opstår når frameworket bruges til noget det ikke er bygget til. Et typisk eksempel er et projekt der starter som en flot Next.js-prototype, måske bygget med et AI-værktøj, og langsomt vokser til et forretningssystem med roller, betalinger og integrationer, uden at nogen har taget stilling til hvor backend-logikken skal bo.

Når det bedste svar er at kombinere dem

Laravel og Next.js udelukker ikke hinanden. Der er tre opsætninger jeg ser som realistiske, og de har meget forskellige omkostninger.

Laravel med React via Inertia

Én applikation, én kodebase, én udgivelse. Laravel klarer data, login og baggrundsjob, og React tegner brugerfladen. Det er mit standardvalg til kundeportaler, interne systemer og SaaS-produkter, fordi du får en moderne brugerflade uden at skulle vedligeholde et API mellem to systemer.

Next.js foran og Laravel som API bagved

Next.js står for de offentlige sider og appens brugerflade, mens Laravel leverer data via et API og klarer login (fx med Laravel Sanctum), køer og integrationer. Det er stærkt når både de offentlige sider og backend er store. Prisen er to kodebaser, to udgivelser og en API-aftale mellem dem der skal holdes ved lige, og login på tværs af to systemer kræver omhu.

Next.js-hjemmeside og Laravel-app hver for sig

Marketingsiden ligger på dit domæne i Next.js, og selve systemet kører på et underdomæne som app.ditfirma.dk i Laravel. De to deler kun design og links. Det er den enkleste kombination, fordi delene kan udvikles, opdateres og hostes uafhængigt af hinanden.

Kombinér kun når begge dele er store nok til at bære det. To systemer betyder mere koordinering ved hver ændring, så gevinsten skal være tydelig. Det er samme afvejning som ved monolit eller microservices: start samlet, og del først op når der er en konkret grund.

Drift, opdateringer og pris over tid

Framework-valget påvirker ikke kun udviklingen, men også hvad løsningen koster at drive i årene efter. Der er især tre ting du skal se på.

Den første er hosting. En Laravel-app kører typisk på en almindelig server, fx administreret med Laravel Forge, eller på Laravel Cloud. Next.js er nemmest på Vercel, hvor prisen typisk afhænger af trafik og forbrug, eller på din egen server, hvor du selv står for driften. Hosting er sjældent den store post, men forbrugsbaseret afregning kan overraske ved trafiktoppe.

Den anden er antallet af tjenester. Et Next.js-projekt med meget backend-funktionalitet ender ofte med separate tjenester til login, database, e-mail og baggrundsjob. Hver tjeneste har sin egen regning, sin egen konto og sine egne opdateringer. Laravel samler mere i én applikation, og det gør regnskabet og overblikket enklere.

Den tredje er opdateringer og hvem der kan overtage. Laravel har 18 måneders fejlrettelser og to års sikkerhedsrettelser pr. version. Hos Next.js får den forrige hovedversion kun kritiske rettelser, og der har været flere store omlægninger mellem versionerne. Begge skal holdes opdateret, og det bør stå i din vedligeholdelsesaftale i stedet for at vente til noget går i stykker. Det er typisk lettere at finde React-udviklere end Laravel-specialister, men en Laravel-udvikler kan som regel dække hele applikationen alene. Og nej, PHP er ikke på vej ud, se mit indlæg om hvorfor PHP stadig er et godt valg.

Bygger du en SaaS, går jeg mere i dybden med valget af hele stakken i tech stack til en SaaS.

Næste skridt: sådan træffer du valget

Peger dine svar mod Laravel, kan du se hvordan jeg griber den slags projekter an på siden om Laravel-udvikling. Peger de mod Next.js, siger jeg det, og jeg bygger gerne i Next.js når det er det rigtige valg.

Ofte stillede spørgsmål

Er en Laravel-side dårligere til SEO end Next.js?+

Nej, ikke i sig selv. Laravel sender færdig HTML fra serveren, og den kan Google læse uden problemer. Bruger du React via Inertia, kan du slå server-side rendering til, så siderne også her sendes som HTML. Next.js har flere værktøjer til forudbyggede, lynhurtige sider, men for de fleste forretningssystemer bag et login er SEO slet ikke relevant.

Kan man skifte fra Next.js til Laravel senere, eller omvendt?+

Ja, men det er sjældent et rent skift. Det mest almindelige er at beholde Next.js som frontend og flytte den tunge backend-logik over i Laravel bag et API, eller at flytte en Laravel-apps offentlige sider til Next.js. Begge dele kan ske gradvist. En komplet omskrivning er dyr og bør have en klar forretningsmæssig grund.

Hvad med Supabase eller Firebase som backend til Next.js?+

Det kan fungere fint til en MVP (en første, enkel version af produktet) eller et mindre produkt, især hvis det meste er enkel læsning og skrivning af data. Sikkerheden afhænger dog af at adgangsreglerne i databasen er sat korrekt op, og forretningslogik ender let spredt i databasefunktioner. Når systemet vokser med integrationer og baggrundsjob, er en egentlig backend ofte lettere at holde styr på.

Hvilket framework er hurtigst til at bygge en MVP?+

Det som du og din udvikler kender bedst. Forskellen mellem to modne frameworks er mindre end forskellen mellem en erfaren og en uerfaren udvikler. Har din MVP login, roller og betaling, kommer Laravel typisk hurtigere i mål, fordi meget følger med. Er det primært en side der skal sælge et produkt, er Next.js ofte hurtigst.