Je klant wil volgende week zelf een bericht kunnen typen. Jouw Astro-blog staat te blinken, met markdown-bestanden netjes in de repo. En precies dat wordt nu het probleem: de klant gaat niet via git publiceren, en terecht.
Dit is het moment waarop mensen een CMS erbij pakken. Een logische keuze daarvoor is EmDash: een open source CMS dat op Astro is gebouwd, met een admin waar je contenttypes zelf inricht, inclusief concepten, revisies, planning en live preview. De content sla je op als gestructureerde JSON, niet als bende losse velden. Hoe zou je een blog opzetten met Astro en EmDash samen, zonder dat je later opnieuw moet beginnen?
Hoe ver kom je in één middag?
Verder dan je denkt. `npm create emdash` zet een project neer met admin, database en types. In het admin maak je een contenttype blogpost aan: titel, excerpt, hero-afbeelding, publicatiedatum en de content zelf. Vanuit Astro lees je die entries met een getypeerde query en render je ze als pagina's. Op emdashcms.com staat de volgorde precies uitgelegd, met een playground als je eerst wilt kijken zonder iets te installeren.
Deze site is er zelf een voorbeeld van: servergerenderd via Astro op Cloudflare Workers, met de content in de Cloudflare-database D1, sessies in KV en media in R2. Wat je hier leest, komt dus binnen via dezelfde route die ik hierboven schets: JSON-blokken in de database, een Astro-pagina eromheen.
Markdown in de repo is prima, tot iemand anders moet publiceren
Als je solo schrijft en git vlot vindt, heeft markdown in je repo nog steeds de voorkeur: geen server, geen database, een build en klaar. Daar is niks mis mee. Maar op het moment dat een tweede iemand publiceert, wordt diezelfde route een achillesheel: pull requests als publicatieroute, en daar haakt iedereen af die niet technisch is.
Precies daar kies je een CMS. Niet omdat markdown slecht is, maar omdat publiceren dan een taak wordt met rechten, revisies en een voorbeeldscherm, in plaats van een deploy. En wil je later ook formulieren opvangen zonder een tweede dienst in te huren? EmDash Forms draait in dezelfde stack en neemt intake, uploads en spamafweer mee.
SSR kost je de eenvoud van een statische build
Het nadeel moet je wel kennen: met een CMS en serverrendering ruil je de simpele wereld van een statische build in voor runtime op een server. Die server heeft kosten, logs en updates nodig. Voor een blog met één schrijver is dat vaak verspilling; voor een site met meerdere makers koop je er hanteerbare publicatie voor terug. Weeg dat per project af, en kies het niet omdat het nieuw is.
Het ecosysteem is ook nog klein: Astro-themes met een EmDash-variant verschijnen pas net, naast Sanity- en markdown-varianten. Wie vandaag start, bouwt zijn eigen layout in plaats van een theme te kiezen.
Vandaag het contenttype, morgen de rest
Pak er een avondje voor: scaffold `npm create emdash`, maak het contenttype blogpost met titel, excerpt, hero en datum, en typ één testpost. Publiceren mag morgen nog. Alles wat je dan hebt, draagt mee wanneer je later echte content importeert.
Bestaande WordPress-content die je mee wilt nemen, zet de EmDash Exporter klaar, en het volledige plan om WordPress naar EmDash migreren zonder SEO-schade staat apart uitgewerkt. Begin je vanaf nul, dan helpt de afweging achter welke EmDash plugin je eerst bouwt om niet op de verkeerde plek te beginnen. En zijn er EmDash plugins genoeg om verder te bouwen, dan zijn de EmDash-pluginpakketten de plek voor wat dat aan hulp en licenties kost.
Let de komende maanden op de theme-markt: bouwers publiceren al Astro-themes met een EmDash-variant naast een Sanity-variant. Zodra die soepel op Workers draaien, hangt de keuze voor een nieuwe blog niet meer aan techniek maar alleen aan prijs en smaak.