Vite er som en elcykel til frontend – du kan stadig cykle selv

Vite er som en elcykel til frontend - du kan stadig cykle selv

At arbejde uden Vite i 2024 føles lidt som at køre på en gammel, tung herrecykel op ad Valby Bakke, mens alle andre suser forbi på elcykel. Ja, du kan godt komme op. Men du sveder lidt mere end nødvendigt.

Jeg var længe sådan en, der insisterede på “helt simpel” frontend: én index.html, én script.js, ingen tooling. Det virkede. Lige indtil jeg ville bygge noget bare lidt større end en to-do liste. Så begyndte det at knirke.

I den her tekst vil jeg vise dig, hvad Vite er, hvornår du faktisk har brug for det, og hvad der sker, når du skriver npm run dev og npm run build. Ingen magi, bare et overblik, så du ikke drukner i nye ord.

Hvornår giver Vite mening (og hvornår gør det ikke)?

Forestil dig to projekter:

  • Et simpelt visitkort-site med lidt tekst og et billede.
  • En lille webapp med flere sider, komponenter og måske React eller Vue.

Til det første ville jeg personligt bare bruge ren HTML, CSS og JavaScript uden Vite. Åbn filen i browseren, færdig. Du lærer meget af at starte så simpelt.

Til det andet begynder Vite at give mening, fordi du får:

  • Dev server som automatisk opdaterer browseren, når du gemmer.
  • Modul-system så du kan dele din kode op i filer med import/export.
  • Build-step, så du ender med en lille, hurtig pakke til brugere.

En helt grov tommelfingerregel:

  • Hvis du kun har 1-2 JavaScript-filer og ingen frameworks: du kan godt springe Vite over.
  • Hvis du vil bruge React, Vue, Svelte eller mange moduler: brug Vite.

Jeg tænker tit: “Vil jeg stadig rode med den her mappe om 3 måneder?” Hvis svaret er ja, vælger jeg Vite. Det gør projektet lettere at vokse med.

Grundideen i Vite: dev server, hot reload og build

Lad os starte med en mental model. Vite gør egentlig bare to ting:

  1. Giver dig en hurtig dev server, når du udvikler.
  2. Bygger din kode til en production-version, når du er klar til at udgive.

Dev serveren: hvad sker der ved npm run dev?

Når du skriver:

npm run dev

sker der noget i stil med:

  • Vite starter en lille server på en adresse som http://localhost:5173.
  • Den server læser dine filer direkte fra src/-mappen.
  • Når du gemmer en fil, opdager Vite ændringen og opdaterer kun det nødvendige i browseren.

Det kaldes HMR (Hot Module Replacement). I praksis betyder det bare: du gemmer, browseren blinker lynhurtigt, og din ændring er der. Ingen manuel refresh, ingen “gæt hvad der er nyt”.

Build til produktion: hvad sker der ved npm run build?

Når du senere skriver:

npm run build

sker der noget andet:

  • Vite gennemgår alle dine filer og finder ud af, hvad der afhænger af hvad.
  • Den bundler (samler) din kode i færre, optimerede filer.
  • Den lægger resultatet i en dist/-mappe.

dist/-mappen er den, du rent faktisk uploader til nettet. Dit src-projekt er din arbejdsplads. Dist er det færdige produkt.

Hvis du vil læse lidt mere om forskellen på udvikling og produktion, har vi også artikler om frontend-workflows, men det kan du sagtens gemme til senere.

Installation trin for trin: fra ingenting til første Vite-projekt

Nu tager vi den stille og roligt. Ingen må gå kold på Node-opsætning her.

1. Tjek at du har Node og npm

Åbn din terminal (Command Prompt, PowerShell eller Terminal) og skriv:

node -v
npm -v

Hvis du får versionsnumre tilbage, fx v20.0.0 og 10.0.0, er du klar. Hvis du får “command not found”, skal du installere Node først. Npm følger automatisk med.

2. Opret et nyt Vite-projekt

I en tom mappe (eller der, hvor du vil have projektet) skriver du:

npm create vite@latest my-app

Du bliver typisk spurgt om:

  • Projekt-navn (my-app er fint).
  • Hvilket framework: fx Vanilla, React, Vue.
  • Om du vil bruge TypeScript.

Hvis du er helt ny, så vælg:

  • Framework: Vanilla
  • Sprog: JavaScript

Så slipper du for ekstra kompleksitet, men får stadig fordelene ved Vite.

3. Installer afhængigheder og start dev serveren

Gå ind i din nye mappe og kør Vite:

cd my-app
npm install
npm run dev

Terminalen viser nu en adresse, typisk noget i den her stil:

  VITE v5.x.x  ready in 300 ms

  Local:   http://localhost:5173/

Åbn linket i din browser. Du burde se en lille Vite-startside. Hvis du har nået hertil, uden at maskinen er brudt i brand, er du faktisk allerede ret langt.

Projektstrukturen forklaret: hvad er hvad?

Åbn projektet i din editor (VS Code fx). Du vil typisk se noget i den her stil:

  • index.html
  • vite.config.js (eller .ts)
  • package.json
  • src/-mappen
  • public/-mappen (nogle skabeloner)

index.html

Det er din hoved-HTML-fil. Vite læser den her for at finde ud af, hvor den skal starte. Der vil typisk være en linje som:

<script type="module" src="/src/main.js"></script>

Det betyder: brug ES Modules (mere om det lige om lidt), og start i src/main.js.

src/-mappen

src/ er hjertet. Her bor din JavaScript, dine komponenter, CSS-filer, billeder du importerer osv.

I en simpel Vanilla-skabelon vil du typisk se:

  • main.js
  • style.css
  • måske en counter.js eller lignende demo-fil

Det er her, du hurtigt opdager, at du kan splitte din kode op i flere filer i stedet for én stor mur af JavaScript.

public/-mappen

Det her er en lidt speciel mappe. Alt i public/ bliver serveret “som det er”. Du bruger det typisk til:

  • Ikoner, som du refererer direkte i HTML.
  • Filer, som ikke skal gå gennem Vites import-system.

Hvis du lægger logo.png i public/, kan du bruge det som /logo.png i din HTML. Det vender vi tilbage til, når vi snakker om 404-fejl efter deploy.

Import/export og ES Modules i praksis

Hvis du kun har arbejdet med ét <script>-tag før, kan ES Modules føles lidt som at få sorteret sit klædeskab. Pludselig er ting i mapper, ikke bare i én bunke.

Den simple version

Forestil dig, at du har en fil med nogle hjælpefunktioner:

// src/utils.js

export function sum(a, b) {
  return a + b;
}

export function multiply(a, b) {
  return a * b;
}

Og så vil du bruge dem i main.js:

// src/main.js

import { sum, multiply } from './utils.js';

console.log(sum(2, 3));       // 5
console.log(multiply(2, 3));  // 6

Nøglen er export i den ene fil og import i den anden. Browseren (med hjælp fra Vite) forstår nu, at de to filer hører sammen.

Standard-exports

Du kan også have én “hoved-ting” i en fil:

// src/math.js

export default function square(x) {
  return x * x;
}

Og importere den sådan her:

import square from './math.js';

console.log(square(4)); // 16

Forskellen er default og de manglende krøllede parenteser ved import. Hvis du er ny, så brug named exports (uden default) i starten. Det føles ofte mindre magisk.

Hvis du vil forstå ES Modules dybere, er MDN ret god til det, fx deres side om JavaScript-moduler. Men du behøver ikke læse det hele før du går videre.

Fra udvikling til virkelighed: sådan deployer du et Vite-projekt

På et tidspunkt vil du gerne vise dit projekt frem til nogen andre end din kat. Det er her npm run build kommer ind.

1. Byg projektet

I projektmappen:

npm run build

Nu får du en dist/-mappe. Åbn den. Der ligger typisk:

  • En optimeret index.html.
  • Nogle JavaScript-filer med mærkelige navne.
  • CSS-filer og eventuelle assets.

Det er de filer, din hosting skal have.

2. Vælg en simpel hosting

Til begyndere er noget som Netlify, Vercel eller GitHub Pages ret fint. De kan alle sammen hoste statiske sider, altså helt almindelige HTML/CSS/JS-filer.

Den generelle idé er:

  • Lav et repository eller et projekt på din hosting-tjeneste.
  • Peg build-outputtet til dist/-mappen.
  • Deploy.

Hvis du arbejder videre med moderne frontend, kommer du ret hurtigt til at møde både Git og deployment-værktøjer. Vi har andre tekster om fx Git og GitHub, som du kan bruge sammen med Vite-projekter.

Typiske fejl og hvad de betyder

Nu til den del, hvor jeg selv har brugt mest tid: når ting bare ikke virker. Det er her, de små kryptiske fejl dukker op.

“command not found” eller Node-fejl

Fejltyper:

  • npm: command not found
  • node: command not found
  • Eller en meget gammel Node-version, der fejler ved installation.

Løsning:

  • Installer ny Node fra den officielle side.
  • Genstart terminalen efter installation.
  • Tjek med node -v og npm -v igen.

Hvis du bruger en meget gammel LTS-version, kan nogle dependencies drille. Jeg går typisk efter en nogenlunde ny LTS-version.

404 på billeder eller CSS efter deploy

Det her er en klassiker: alt virker lokalt, men når du deployer, får du 404 på billeder eller CSS-filer.

De typiske årsager er:

  • Du refererer billeder med forkerte paths.
  • Du bruger absolutte paths uden at sætte base korrekt i Vite-config.

En mere sikker måde i Vite er at importere assets i din JavaScript eller CSS, fx:

import logo from './assets/logo.png';

const img = document.querySelector('img');
img.src = logo;

Så sørger Vite for, at filen får det rigtige navn og path efter build.

Hvis du hellere vil have det i public/, så brug en rod-relative sti, fx /logo.png, og læg filen i public/logo.png. Bare vær konsekvent.

Relative vs absolute paths

En anden kilde til forvirring er forskellen på:

  • ./utils.js (relativ)
  • /src/utils.js (rod-relativ)

I moduler bruger du næsten altid relative imports, altså:

import { sum } from './utils.js';

Ikke:

import { sum } from '/src/utils.js';

/src/... kan se fristende ud, fordi det virker i dev, men du kan nemt løbe ind i problemer efter build, hvis du ikke har styr på base-url.

Så, lille vane: når du importerer mellem egne filer, så start med ./ eller ../.

Mini-tjekliste: sådan ved du, at dit setup faktisk spiller

Hvis du sidder og tænker: “Har jeg sat det rigtigt op, eller fungerer det kun ved et lykketræf?” så er her en lille tjekliste.

  • Dev serveren kører: npm run dev virker, og du ser din app på localhost:5173.
  • Ændringer slår igennem: Du retter en overskrift i src/main.js eller index.html, gemmer, og browseren opdaterer.
  • Imports virker: Du kan lave en ny fil i src/, eksportere en funktion og importere den i main.js uden fejl.
  • Build lykkes: npm run build kører uden røde fejl, og der opstår en dist/-mappe.
  • Dist virker lokalt: Hvis du bruger en simpel static server (fx VS Code plugin eller npx serve dist), kan du åbne dist-versionen og se det samme som i dev.

Når du kan sætte hak ved de fem, er du længere end mange, der har fulgt 10 tilfældige YouTube-videoer uden at forstå, hvad der sker.

Hvad kan du bygge herfra?

Når du først har ét Vite-projekt kørende, er næste skridt egentlig bare at bygge noget, du gider at bruge tid på. Et par idéer:

  • En lille dashboard-side, der henter data fra en API og viser det pænt.
  • En mini-spilside, hvor du opdeler logik i moduler (player.js, enemy.js, gameLoop.js).
  • En React-udgave af et simpelt projekt, du allerede har, så du kan mærke, hvordan Vite også hjælper der.

Hvis du først vil have styr på “ren” JavaScript, inden du hopper i framework-poolen, kan du fx bygge videre på en lille app med moduler og localStorage. Det spiller ret godt sammen med Vite.

Og hvis du vil have mere struktur på din læring, så kig efter vores intro-artikler til JavaScript for begyndere og de forskellige frontend-frameworks. De kan sagtens kombineres med Vite som udviklingsværktøj.

Hvis du kun gør én ting anderledes efter at have læst det her, så lav ét lille Vite-projekt med vanilla JavaScript, byg det, deploy det et sted, og brug det som din personlige skabelon til alle fremtidige små apps.

Ida Balslev er den type ven, der pludselig dukker op i din messenger med et link til en lille web-app, hun lige har bygget for sjov – og bagefter gerne viser dig, hvordan du selv kan lave den. Hendes passion for kodning startede med en hjemmebygget hjemmeside til en hestestald og er langsomt vokset gennem aftener med tutorials, fejlmeldinger og små, hjemmelavede projekter.

På Codingclass.dk deler Ida den viden, hun selv manglede i starten: konkrete eksempler, tydelige forklaringer og ærlige historier om, hvad der typisk går galt første, anden og tredje gang. Hun elsker at tage et abstrakt begreb som fx "API" eller "asynkron JavaScript" og koge det ned til noget, du kan se, klikke på og lege med i browseren. For hende handler kodning ikke om at være perfekt, men om at turde prøve, bryde ting og bygge dem op igen.

Ida skriver især om webudvikling med HTML, CSS og JavaScript, små Python-scripts og grundlæggende koncepter som debugging, versionsstyring og struktur i din kode. Hun tænker altid i næste skridt: når du først forstår idéen, viser hun dig, hvordan du kan udvide det med en ekstra funktion, lidt pænere styling eller en smartere måde at tænke din kode på.

Gennem sine artikler på Codingclass.dk vil Ida gerne give dig følelsen af, at du ikke sidder alene med koden – men at der faktisk er en, der har kæmpet med de samme fejlmeddelelser og nu gerne vil vise dig en vej igennem dem, i et tempo hvor alle kan være med.

1 kommentar

comments user
Lotte

ok elcykel-metaforen gav mening, især hvis man ikk vil svede op ad bakken.

Send kommentar

You May Have Missed