Denne blog er bygget anderledes end de fleste moderne websites. Den bruger ingen frameworks. Ingen build pipeline. Ingen pakke-manager. Ingen database. Det er et bevidst valg — ikke en begrænsning, men en befrielse. Vi kalder det det flade HTML-dogme.

Inspireret af filmens Dogme 95 — der satte kunstige begrænsninger for at tvinge ægthed frem — har vi defineret et sæt regler for, hvordan denne blog er bygget. Ikke fordi vi ikke kender de moderne værktøjer, men fordi vi bevidst vælger dem fra.

Reglerne

Her er dogmet i sin helhed. Ti regler. Ingen undtagelser.

  1. Ingen frameworks. Ingen React, ingen Vue, ingen Svelte, ingen Angular. Browseren ved allerede, hvordan den renderer HTML. Vi lader den gøre sit arbejde.
  2. Ingen build step. Ingen Webpack, ingen Vite, ingen Parcel, ingen transpilering. Kildekoden er produktionskoden. Det du redigerer, er det, der bliver deployet.
  3. Intet CMS. Ingen WordPress, ingen headless API, ingen database. Indholdet lever i HTML-filerne selv — versionsstyret, diff-bart og permanent.
  4. Ingen afhængigheder. Nul node_modules. Nul package.json. Nul supply chain-angrebsflade. Sitet afhænger af præcis én ting: browseren.
  5. Ingen client-side routing. Hver side er en rigtig URL bakket af en rigtig fil. Browserens navigation fungerer nativt. Tilbage-knapper, bogmærker og dybe links virker — som de altid har gjort.
  6. Minimal JavaScript. JS bruges kun til progressiv forbedring — hamburger-menu, aktiv tab-markering, estimeret læsetid. Sitet er fuldt funktionelt med JavaScript slået fra.
  7. Ét stylesheet. En enkelt CSS-fil håndterer al styling. Ingen CSS-in-JS, ingen utility-klasse-sprawl, ingen preprocessor. Læsbart, scanbart, vedligeholdelsesvenligt.
  8. Semantisk HTML. Korrekt heading-hierarki, landmark-elementer, ARIA-labels og struktureret data. Tilgængelighed og SEO er bygget ind i markup'en, ikke boltet på som en eftertanke.
  9. Hurtigt som standard. Ingen JavaScript-bundler at parse. Ingen layout shifts fra lazy-hydration. Ingen loading-spinnere. Den første meningsfulde paint er den eneste paint.
  10. Udødeligt by design. Denne side ville have virket i 2005, og den vil virke i 2035. Teknologierne den bruger — HTML, CSS, en smule vanilla JS — er den mest stabile platform i computerhistorien.

Men hvorfor?

Det korte svar: fordi webben ikke behøver at være kompliceret.

Det lange svar kræver, at vi kigger på, hvad der er sket med webudvikling over de sidste ti år. Vi har normaliseret en ekstraordinær mængde accidental complexity — kompleksitet der ikke stammer fra problemet, men fra løsningen.

En blog med ti indlæg har ikke brug for en CI/CD-pipeline, et headless CMS, en CDN-edge-rendered React-app med incremental static regeneration. Den har brug for HTML-filer på en server.

Vi installerer megabytes af JavaScript for at rendere tekst. Vi bruger build-værktøjer, der tager længere tid at konfigurere, end sitet tager at skrive. Vi har afhængigheder, der bryder fra dag til dag, fordi nogen masseopdaterede en pakke, som halvdelen af internettet afhænger af.

Det flade HTML-dogme er en påmindelse om, at webbens originale arkitektur — dokumenter linket sammen — aldrig var i stykker. Den behøvede ikke at blive fikset. For sites som dette er den stadig det bedste værktøj.

Hvad vi vinder

Ved at følge dogmet får vi en række ting gratis:

  • Hastighed. Ingen JavaScript-bundler at downloade og parse. Siden loader på millisekunder. Lighthouse-scores i den høje ende uden at løfte en finger.
  • Pålidelighed. Ingen build der kan fejle. Ingen afhængigheder der kan bryde. Ingen server-side rendering der kan gå ned. Filen er der, eller den er der ikke.
  • Portabilitet. Hele sitet kan køre fra en USB-nøgle, en Raspberry Pi, eller et gratis statisk hosting-lag. Kopier mappen, og du har en kopi af sitet.
  • Sikkerhed. Nul afhængigheder betyder nul supply chain-angrebsflade. Der er ingen node_modules at kompromittere, ingen tredjepartskode at stole på.
  • Levetid. HTML-filer fra 1996 virker stadig i dag. Kan du sige det samme om din Gatsby-blog fra 2019?
  • Forståelighed. Enhver kan højreklikke, vælge "Vis kildekode" og forstå, hvad der sker. Ingen minificering, ingen kompilering, ingen obfuskering.

Hvad vi mister

Lad os være ærlige. Der er trade-offs:

  • Gentagelse. Header og footer gentages i hver fil. Der er ingen komponent-model. Det er bevidst — hver side er selvstændig og komplet.
  • Dynamisk indhold. Der er ingen database, ingen API, ingen server-side logik. Hvis indholdet skal ændres, ændrer du en HTML-fil. Det er manuelt og langsommere end et CMS.
  • Skalerbarhed. Med tusindvis af sider ville denne tilgang være upraktisk. Men denne blog har ikke tusindvis af sider. Den har en håndfuld. Og det er nok.

Det vigtige er, at disse trade-offs er bevidste. Vi har valgt dem med åbne øjne, fordi fordelene langt overstiger ulemperne for et site af denne størrelse og karakter.

Deploy-processen

Hele deploy-processen kan beskrives på én linje: 

$ rsync -avz --delete ./boingboing-dk/ server:/var/www/boingboing.dk/
# Færdig. Det er hele pipelinen.

Ingen GitHub Actions. Ingen Docker-containere. Ingen Kubernetes-klynger. Én kommando. Filerne kopieres til serveren. Serveren serverer filerne. Brugeren modtager filerne. Sådan har webben altid fungeret.

En opfordring

Næste gang du skal bygge en simpel hjemmeside — en blog, en portfolio, en landing page — så overvej at droppe værktøjerne. Åbn en teksteditor. Skriv noget HTML. Læg det på en server. Se, hvor langt du kan komme med webbens egne primitiver.

Du bliver måske overrasket over, hvor befriende det føles.