Het bouwen van een directory-website klinkt triviaal totdat je jezelf betrapt op het koppelen van databases, caching-lagen en reactieve front-end frameworks, alleen maar om in essentie een gecureerde inhoudsopgave weer te geven. Onlangs heb ik Social Tools List gebouwd, een site voor het vergelijken van social media-software. Mijn doel was om het snel online te krijgen, snel te houden en het onderhouden van infrastructuur te vermijden voor content die alleen verandert wanneer ik een tool toevoeg of bijwerk. Ik koos voor een static-first stack: Astro voor sitegeneratie, TypeScript voor gestructureerde data en Cloudflare Workers voor deployment. Het resultaat is een site die direct laadt, bijna niets kost aan hosting en geen databasebeheer vereist.

Waarom een static-first aanpak logisch is voor een directory

Veel web-apps kiezen standaard voor server-side rendering of single-page architecture omdat dit veilige, moderne keuzes lijken. Maar niet elke site ontvangt bij elk verzoek dynamische gebruikersinput. Social Tools List is een read-heavy resource. De vergelijkingsdata verandert wanneer ik een update push, niet wanneer een bezoeker de pagina ververst. Het vooraf renderen van HTML neemt de noodzaak weg voor databasequeries aan de edge, template-compilatie on the fly, of hydration-overhead in de browser. Ik genereer de site tijdens de build-tijd, deploy de statische bestanden en laat een lightweight worker de wrapper afhandelen. Dit houdt de responstijden laag en elimineert een hele klasse aan runtime-fouten.

Sla data op in TypeScript, niet in een database

Ik gebruik geen database. Elke tool in de directory is gedefinieerd als een TypeScript-object met een slug, naam, domein en een array van ondersteunde workflows. Een typische entry ziet er zo uit:

{
  slug: 'buffer',
  name: 'Buffer',
  domain: 'buffer.com',
  workflows: ['scheduling', 'analytics']
}

Het opslaan van data in dezelfde taal waarin de site wordt gebouwd, heeft twee directe voordelen. Ten eerste worden pull requests content-reviews. Wanneer ik een tool toevoeg, laat de diff de exacte velden en waarden zien, en kan een teamgenoot een typefout of een verkeerd domein opmerken zonder een CMS-interface te hoeven leren. Ten tweede dwingt de TypeScript-compiler de vorm van elk record af. Als ik vergeet een slug op te nemen of een workflow-key verkeerd spelde, mislukt de build voordat de foutieve data een pagina bereikt.

Een database zou migraties, connection strings, caching-strategieën en back-uproutines introduceren. Voor een directory met een paar honderd entries die ik handmatig onderhoud, is die overhead pure ballast. Statische data in TypeScript-modules is de goedkoopste juiste keuze voor dit model. Het "juiste" gedeelte is belangrijk. Het gaat niet alleen om het besparen van geld; het gaat om het verwijderen van abstractielagen die problemen oplossen die ik niet heb.

Laat Astro de routing en rendering beheren

Astro genereert één HTML-pagina per tool vanuit één enkele dynamische route. Ik definieer één layout-component, en Astro genereert automatisch de metadata, koppen en gestructureerde data voor elke entry. Omdat dezelfde dataset de hoofdpagina, de workflow-categoriehubs en de individuele detailpagina's aanstuurt, is er geen kans dat een kaart op de homepagina een andere beschrijving toont dan de detailpagina zelf. In traditionele CMS-opstellingen zie je vaak afwijkingen: de API geeft één versie terug, de cache een andere, en een client-side render een derde. Statische generatie vanuit een enkele source of truth voorkomt dat.

De island-architectuur van Astro maakt het ook gemakkelijk om kleine interactieve onderdelen toe te voegen zonder de hele pagina te vervuilen met JavaScript. De site wordt geleverd als statische HTML, en alleen het filterscript hydrateert zijn specifieke deel van de DOM. Er is geen framework runtime die het hele document omhult. Astro behandelt paginametadata ook als een topprioriteit. Elke tool-pagina krijgt zijn eigen title tag en meta description, direct afgeleid van het TypeScript-record, zodat ik geen aparte plugin of een head-management library nodig heb.

Filteren zonder een framework

Zoeken en filteren verleiden ontwikkelaars vaak om React, Vue of een zware state management library te installeren. Ik heb dat weerstaan. Astro rendert de volledige lijst als gewone HTML op de server. Een klein vanilla JavaScript-script, minder dan een kilobyte, draait in de browser en schakelt de display-eigenschap van lijstitems om op basis van een workflow-tag of een tekstmatch.

Het serveren van de volledige markup klinkt inefficiënt als je een API-gestuurde achtergrond hebt. Maar houd rekening met de overhead van een typische dynamische aanpak. De browser downloadt een JavaScript-bundle, hydrateert een componentboom, roept een endpoint aan, wacht op JSON en rendert vervolgens de rijen. Voor een directory die minder dan honderd tools bevat, is dat ritueel trager en minder betrouwbaar dan het verbergen van divs die al in het document aanwezig zijn. Mijn script koppelt event listeners aan filterknoppen, leest een data-workflow-attribuut op elke rij en zet niet-overeenkomende items op 'hidden'. De operatie duurt slechts enkele milliseconden.

Omdat de lijst aanwezig is in de initiële HTML, is de site bruikbaar zonder JavaScript. Search engine crawlers zien elke link en elke beschrijving. Gebruikers op trage netwerken of met scriptblockers krijgen nog steeds de volledige directory te zien. De filtering is een verbetering, geen barrière.

Sitemaps en robots als code

Sitemaps en robots.txt zijn geen achterafjes die met de hand zijn geschreven. Het zijn Astro-routes die dezelfde dataset en URL-helpers gebruiken als