Den rækkefølge, tingene faktisk skete i
Dette websted gik live som en enkelt index.html-fil uden build-trin, uden
framework og uden database — en midlertidig pladsholder-side med et mailto-link.
Få dage senere havde det en scroll-drevet hero-animation, en casestudie med et videoslideshow og nok besøgende til, at den næste anmodning var: "Jeg vil gerne redigere dette selv, og jeg vil have, at det vises i søgeresultaterne." Det er netop den anmodning, der faktisk retfærdiggør et framework og et backend — ikke at gøre det fra starten, fordi det er den moderne standard.
Hvad »static first« har givet i mellemtiden
- Implementeringer uden konfiguration. Intet build-trin betyder, at der ikke er noget build, der kan gå i stykker. Hver push fungerer enten, eller også er diff’en åbenlyst forkert.
- Ingen tredjepartsanmodninger under kørsel. GSAP og begge webfonts er integreret i repoen — downloadet én gang, commitet, serveret fra samme oprindelse som alt andet. Intet CDN-nedbrud kan tage en font ned; ingen Content-Security-Policy behøver at stole på en ekstern host.
- En side, der fungerer uden at noget er aktiveret. Hver eneste animation på dette websted er additiv: fjern JavaScriptet, og indholdet er der stadig, stadig læsbart, stadig med links til de rigtige steder. Det er ikke en fodnote om tilgængelighed — det er det, der naturligt følger, når standardtilstanden skal vises korrekt, før man skriver forbedringerne.
Hvor det statiske faktisk ikke længere er nok
En statisk fil har ingen login-side. Den kan ikke have en – der er intet at autentificere sig over for, ingen session at opretholde, ingen databasepost at kontrollere tilladelser imod. I det øjeblik kravet bliver »lad mig redigere dette uden at skulle anmode om en commit«, er svaret ikke en større statisk fil, men et rigtigt backend: en database til indholdet, autentificering for den ene person, der har lov til at ændre det, og et build-trin, der kan gengenerere sider ud fra disse data. Det er en anden arkitektur, der bevidst er valgt af en konkret årsag — ikke fordi et statisk websted svigter, men fordi et statisk websted har udført sin opgave, indtil opgaven ændrede sig.
Selve overgangen behøver ikke at være risikabel
Den mest risikable del ved at skifte fra håndskrevet HTML til et framework er ikke frameworket — det er den stille tab af den specifikke, hårdt tilkæmpede korrekthed, der er opbygget i den gamle version, mens ingen kiggede. En ydelsesforbedring til mobil, en fallback, hvis JavaScript er deaktiveret, en animation, der vender pænt tilbage, når man ruller baglæns — intet af det vises på et skærmbillede. At porte det betyder bevidst at overføre den samme logik og køre de samme tests igen på den nye version, ikke at omskrive ud fra hukommelsen og håbe, at intet er blevet glemt.
Skrevet af Lars Sohl