Vite eller Next.js i 2026 (og hvorfor dit svar starter med 6 spørgsmål)
De fleste starter med at spørge: “Hvad er hurtigst, Vite eller Next.js?”. Det er det forkerte spørgsmål.
Det rigtige spørgsmål er: “Hvad skal min app kunne, og hvad vil jeg selv slås med de næste 6 til 12 måneder?”.
Jeg har selv valgt forkert flere gange. Første gang byggede jeg en alt-for-tung Next-app til noget, der bare var en lille SPA. Senere lavede jeg en Vite SPA, der viste sig at skulle rangere i Google. Det gik mildt sagt skævt.
I stedet for endnu en teoretisk gennemgang af SPA vs SSR vs SSG, får du her den model, jeg selv bruger nu: 6 spørgsmål, som næsten altid peger dig ret klart mod enten Vite eller Next.js.
1. De 6 spørgsmål der afgør dit valg
Forestil dig, at du sidder klar til at køre npm create vite@latest eller npx create-next-app@latest. Inden du trykker enter, så svar stille og roligt på de her spørgsmål.
Spørgsmål 1: Skal siden kunne findes i Google (rigtigt)?
Ikke “måske en dag”. Helt ærligt: skal den her app fungere som en rigtig, offentlig webside hvor SEO betyder noget?
Hvis dit svar er ja, og indholdet ikke kun er bag login, så er ren SPA med Vite den svære vej. Det kan godt lade sig gøre, men du kommer hurtigt til at mangle:
- server-side render (SSR) eller static site generation (SSG)
- ordentlig håndtering af
<head>og metadata per side - fornuftig 404/redirect logik ved serverrouting
Next.js har de ting bygget ind. Jeg har skrevet en hel artikel om SPA routing og 404 problemer, og meget af smerten forsvinder faktisk med Next.
Tommelfingerregel:
- Public site med SEO-krav: Next.js har et klart forspring.
- Ren app inde i et intranet eller bag login: Vite er stadig helt fint.
Spørgsmål 2: Hvor meget backend har du i virkeligheden?
Next.js er ikke bare et frontend framework. Du får server components, API routes og hele pakken. Det er dejligt, men også mere kompleksitet.
Spørg dig selv:
- Har du allerede et backend API (Node, Python, .NET, hvad som helst)?
- Eller vil du helst bare have “lidt backend” til formularer, auth, webhooks osv.?
Hvis du allerede har en backend, eller skal lære det som del af full stack workflows, kan Vite være et rent frontend-lag ovenpå den backend. Simpelt og adskilt.
Hvis du derimod ikke har lyst til at sætte en separat backend op, og du gerne vil have API routes tæt på komponenterne, så taler det for Next.js.
Spørgsmål 3: Hvem er projektet til?
Jeg plejer at skelne mellem tre typer projekter:
- Portfolio- / studieprojekt til CV og jobsøgning
- Lille hobbyapp til dig selv og et par venner
- “Rigtig” produktidé som måske skal leve længe
Hvis du primært går efter at vise, at du kan moderne frontend frameworks og forstå server-side render, så er Next.js guld til portfolio. Mange stillinger forventer, at du i det mindste har rørt det.
Hvis projektet bare er “jeg vil lære React og have det sjovt”, så vinder Vite 9 ud af 10 gange alene på simpel opsætning og hurtig dev server.
Spørgsmål 4: Hvor bange er du for drift og miljøvariabler?
Next.js kan føles lidt som at købe en campingvogn med avanceret el-installation, når du bare ville sove i et telt. Det er rart, når man har brug for det, men det går også i stykker på andre måder.
Med Next.js skal du typisk forholde dig til:
- build-time vs runtime miljøvariabler
- caching på CDN-niveau (især på Vercel)
- dynamic vs static routes med forskellig render-strategi
Det er ikke svært, men det kræver, at du allerede har nogenlunde styr på miljøvariabler og deployment flow.
Vite + en simpel static host (Netlify, Vercel static, GitHub Pages) er til gengæld meget ligetil at deploye. Næsten alt sker i build-step, og du har færre overraskelser ved runtime.
Spørgsmål 5: Skal der være login og “rigtig” auth?
Login, sessions, tokens og cookies er et helt emne for sig. Jeg har skrevet om det før i forhold til JWT og sessions, og Next.js ændrer faktisk spillet lidt.
Hvis du vil bygge en “seriøs” app, hvor:
- brugere logger ind
- data er personlige per bruger
- du måske har roller eller rettigheder
så er det meget oplagt at køre et BFF-mønster (Backend For Frontend) med server-side sessioner. Next.js gør det ret naturligt, fordi du kan håndtere cookies, sessions og API endpoints i samme projekt.
Med en Vite SPA ender du oftere i et token-setup med JWT i localStorage eller cookies og en separat backend, der styrer sessions. Det kan man sagtens, men du skal tage flere valg selv.
Spørgsmål 6: Hvor stort bliver det her reelt?
Den ærlige version, ikke drømmeversionen.
En lille app med 5 til 10 sider og begrænset data kan blive besværlig i Next.js, hvis du i praksis aldrig får brugt server features. Her er Vite skønt: du undgår kompleksitet, du ikke bruger.
Men så snart du kigger på noget med:
- mange forskellige sider og URL-strukturer
- indhold der skal kunne opdateres og caches rigtigt
- både public sider og private områder
så får du mere hjælp af Next.js.
2. Vælger du Vite? Sådan undgår du de klassiske SPA-fælder
Jeg elsker Vite. Det er hurtigt, simpelt og føles ikke så “tungt” i hverdagen. Men min første Vite SPA havde præcis alle de problemer, jeg advarer imod i dag.
Routing: fra App.jsx kaos til fornuftig struktur
Mit første forsøg så sådan her ud:
function App() {
const [page, setPage] = useState('home');
if (page === 'home') return <Home onNav={setPage} />;
if (page === 'about') return <About onNav={setPage} />;
return <NotFound />;
}
Det virkede. Men ingen rigtige URLs, ingen back-knap, ingen deep links.
Det her er langt bedre:
import { BrowserRouter, Routes, Route } from 'react-router-dom';
function App() {
return (
<BrowserRouter>
<Routes>
<Route path="/" element={<Home />} />
<Route path="/about" element={<About />} />
<Route path="*" element={<NotFound />} />
</Routes>
</BrowserRouter>
);
}
Brug et rigtigt routingbibliotek. Det koster næsten ingenting, men redder dig fra en masse hjemmerullet logik.
404 og serverrouting: hosten skal kende dit index.html
Den klassiske: Alt virker lokalt. Du deployer. Direkte besøg på /about giver 404.
Grunden er, at din host ikke ved, at alle ruter skal pege på det samme index.html, hvorefter din SPA selv tager over. Du skal typisk sætte noget i stil med:
- Netlify:
_redirects-fil med/* /index.html 200 - Vercel:
vercel.jsonrewrites-regel - Static nginx: fallback til
index.htmlpå ukendte ruter
Hvis du ikke gider tænke over det, er det et argument for Next.js, hvor serverrouting følger med fra start.
SEO “light” i en SPA
Hvis du alligevel ender med Vite til et semi-public site, så gør i det mindste det her:
- Brug et bibliotek til at styre
<title>og meta tags per route - Sørg for en ordentlig
<meta name="description" ...> - Lav en pæn fallback 404-side i din SPA
Det løser ikke hele SEO-historien (rendering og crawlbarhed kan stadig drille), men det er bedre end ingenting.
3. Vælger du Next.js? Hvad bliver lettere og hvad bliver sværere
De første par aftener, jeg sad med Next.js, var faktisk ret hyggelige. Routing føltes logisk, og pages/index.tsx gav mening. Problemerne kom senere, da tingene blev “rigtige”.
Det der faktisk bliver lettere
- Routing: Mappestruktur = URLs.
- SEO: Du kan få genereret HTML på serveren og styre metadata per side.
- Data fetching: Du kan hente data på serveren og sende det som props.
- API routes: Små endpoints i samme repo, godt til formularer og simple backends.
Til et jobrettet projekt er det en kæmpe fordel, at du kan vise, du forstår forskellen på client og server, og at du kan forklare SSR vs SSG vs client-side render. Det er lige ned i skuffen “moderne JavaScript til web”.
Det der typisk bliver sværere
Jeg ramte især problemer på tre områder.
1) Caching og data-opdateringer
Når du først bruger static generation (SSG) og ISR (incremental static regeneration), rykker data-opdateringer fra “når jeg kalder API’et” til “når buildet kører” eller “når CDN’et revalidates”.
Pludselig har du spørgsmål som:
- Hvor lang tid må en side være cached?
- Hvordan får jeg vist opdaterede data uden fuld redeploy?
Det er ikke svært, men det kræver, at du forstår, at data ikke altid hentes ved hver request.
2) Miljøvariabler og build vs runtime
I min første Next-app stod jeg i den her situation:
- Env var ændret i production
- Appen opførte sig stadig som før
Årsag: Variablen blev kun læst ved build-time, ikke runtime. Jeg skulle redeploy, ikke bare ændre env.
I en ren SPA (Vite) er der typisk én bygning af assets og ikke så meget magi omkring runtime environments. I Next er forskellen skarpere. Lær det tidligt, så slipper du for at stirre på skærmen og tvivle på dig selv.
3) Drift: logs, errors, edge vs serverless
Når din Next-app kører som serverless functions eller edge functions, ændrer måde du fejlfinder bugs på. Det minder mere om backend end om “bare frontend”.
Det er fedt, hvis du vil dybt ned i fejlfinding og debugging. Men det er ikke det nemmeste sted at starte, hvis du i forvejen kæmper med React basics.
4. Forms og validation: client-only vs server-first
Her er en konkret forskel mellem Vite SPA og Next.js, som jeg selv undervurderede i starten.
Vite SPA: alt sker i browseren (med et API ved siden af)
Typisk mønster i en Vite/React SPA:
- Bruger udfylder form
- Client-side validation (f.eks. med Yup/Zod)
- API call til backend
- Viser fejl eller succes på clienten
Du er nærmest tvunget til at tænke i “client first”, og backenden bliver en slags datatjener. Det er fint, hvis:
- du har få formularer
- du ikke har super stramme krav til sikkerhed og compliance
Next.js: server-first bliver nemmere at vælge
Med Next.js kan du håndtere forms som klassiske POSTs til dine egne routes eller API routes.
Eksempel:
async function handleSubmit(formData: FormData) {
'use server';
const email = formData.get('email');
// Validate på serveren
// Gem i database
}
Du kan stadig have client-side validation for UX, men den endelige sandhed ligger på serveren. Det er meget sundt, hvis du arbejder med “rigtige” data.
Hvis du ved, at din app får mange formularer, vil jeg personligt hælde mod Next.js i dag.
5. Auth: BFF og cookies vs tokens overalt
Jeg har haft én SPA, hvor jeg kørte full-on JWT i localStorage, refresh tokens, custom hooks og alt muligt smart. Det var spændende. Jeg ville ikke gøre det igen til et lille hobbyprojekt.
Vite SPA: typisk token-setup
Det naturlige mønster med en ren SPA er:
- Brugeren logger ind via API
- Du får et token tilbage (JWT eller lignende)
- Token gemmes (ofte i memory eller secure cookie)
- Alle efterfølgende API-kald sender token med
Det fungerer, men du får også mere ansvar:
- Opbevaring og rotation af tokens
- Håndtering af udløb (401, refresh, redirect til login)
- Sikkerhedsdetaljer, som du faktisk skal forstå
Next.js: BFF, cookies og server-side sessioner
Med Next.js kan du langt nemmere:
- lade serveren håndtere sessions (session-id i cookie)
- slippe for at clienten kender til tokens direkte
- bruge server components, der allerede “ved” hvem brugeren er
Det er ret meget i tråd med det klassiske web-sikkerhedssetup og passer godt sammen med moderne auth-løsninger og frameworks.
Hvis auth er en vigtig del af din app, og du ikke har lyst til at opfinde dit eget token-cirkus, er det endnu et argument for Next.
6. Performance: bundle size, data fetching og caching
Både Vite og Next.js kan levere hurtige sider. Forskellen er mest i, hvordan du tænker om ydelse.
Vite: tænk mest i bundle size og lazy loading
I en ren SPA er performance næsten lig med:
- hvor stort dit initiale bundle er
- om du splitter koden fornuftigt (code splitting)
- om du undgår alt for tunge komponenter på forsiden
Du styrer det typisk med lazy loading:
const SettingsPage = React.lazy(() => import('./SettingsPage'));Det er til at have med at gøre, og Vite er god til at vise dig, hvad der fylder.
Next.js: tænk også i render-strategier og caching-lag
Med Next har du flere knapper:
- SSR (server-side render ved hver request)
- SSG (byg siderne ved build)
- ISR (revalidate efter X sekunder/minutter)
- edge rendering
Du kan få virkelig hurtige sider, men du kan også forvirre dig selv, hvis du blander strategier uden at forstå dem.
Mit råd: Start med én strategi for det meste af appen, f.eks. SSG + lidt SSR hvor det giver mening. Juster senere, når du støder på konkrete performance-problemer.
7. Deployment: de typiske ting der går galt
Her er det område, hvor jeg i praksis har spildt flest aftener.
Vite SPA deployment: det der plejer at drille
- 404 på direkte URL: Ingen fallback til
index.html. - Forkert base path: Særligt på GitHub Pages skal du sætte
basei Vite config. - Env-variabler: Husk
VITE_-prefix for at eksponere dem til clienten.
Men når først det spiller, er det stabilt. Der er ikke så mange moving parts.
Next.js deployment: det der fanger mange første gang
- Build vs runtime env: Du ændrer env i UI’et, men glemmer at trigge et redeploy.
- ISR revalidate: Du forventer instant opdatering, men cachen lever længere.
- Serverless timeouts: Din API route laver for meget arbejde på én gang.
Til gengæld kan du med f.eks. Vercel hosting få et ret stærkt setup uden selv at rode med servere. Så der er lidt mere at lære, men også flere goder bagefter.
8. Tre anbefalede setups du faktisk kan leve med
For at samle det, får du tre “standardvalg”, som jeg selv kunne finde på at bruge i dag. Det vigtigste er næsten, hvad du siger nej til.
Setup 1: Begynderprojektet (lære React og bygge lidt UI)
Vælg: Vite + React + React Router.
Du får:
- simpel opsætning, hurtigt dev-flow
- rigtig routing, så du lærer URL-tænkning
- fokus på komponenter og state, ikke drift
Du fravælger:
- server-side render og SEO
- indbyggede API routes
- de mere avancerede performance-mønstre
Det er perfekt, hvis du kommer fra f.eks. begynderprojekter og bare vil en tand videre uden at drukne i opsætning.
Setup 2: Job-fokus projektet (vise at du kan “moderne web”)
Vælg: Next.js (app router) + server components + et par server actions til forms.
Du får:
- et projekt der ligner det, mange virksomheder bruger i dag
- mulighed for at snakke om SSR, SSG, routing, API routes
- et godt samtaleemne til jobsamtaler
Du fravælger:
- den allernemmeste start (det er tungere end Vite)
- helt skarp adskillelse mellem frontend og backend
Her vil jeg personligt holde backenden inde i Next, med mindre du direkte vil vise full stack med separat backend.
Setup 3: Produkt-fokus (lille SaaS eller sideprojekt der skal leve)
Vælg: Next.js som BFF + “rigtig” backend/service der kan leve for sig selv.
Det lyder tungt, men tænk i lag:
- Next.js for alt der handler om UI, routing, auth-flow, simple API endpoints
- en separat service (f.eks. Node/Express, FastAPI, Rails) til tungere domænelogik
Du får:
- god mulighed for at skalere og flytte dele senere
- klarere ansvar: UI her, domæne-logik der
Du fravælger:
- den helt enkle, monolitiske løsning
- “bare lige at starte” uden at tænke nogle måneder frem
Afslutning: Den aften hvor begge valg var forkerte
Jeg sluttede en tirsdag aften for et par år siden med at stirre på to forskellige repos: en Vite SPA, der var vokset ud af sine rammer, og en halvfærdig Next-app, jeg havde opgivet halvvejs fordi jeg var træt af build-errors.
Det gik op for mig, at problemet ikke var værktøjet, men mig, der ikke havde besluttet, hvad projektet skulle kunne, før jeg valgte stack.
I dag prøver jeg at tage de seks spørgsmål først. Nogle aftener ender jeg stadig i Vite-land, hvor jeg bare hygger mig med komponenter og små features. Andre gange bider jeg til bolden og starter et nyt Next-projekt, fordi jeg ved, at jeg får brug for SEO, auth og en lidt mere “rigtig” server-side.
Hvis du sidder nu og overvejer Vite vs Next.js: vælg den løsning, der gør de næste tre måneder realistiske, ikke den der ser bedst ud på LinkedIn. Frameworks kan du altid skifte senere. Tiden får du ikke igen.
Send kommentar
Du skal være logget ind for at skrive en kommentar.