EmDash CMS: De WordPress-opvolger gebouwd op Astro
Wat Is EmDash CMS?
Je WordPress-installatie voert 47 databasequery's uit voordat een bezoeker je homepage ziet. EmDash voert nul uit. Het is een open-source CMS die op 1 april 2026 als v0.1.0 beta is uitgebracht — gebouwd met TypeScript op Astro, draait serverless op Cloudflare Workers, wordt uitgebracht onder de MIT-licentie. De onderhoudders noemden het niet een WordPress-alternatief of WordPress-concurrent. Ze noemden het de WordPress opvolger — de daadwerkelijke volgende generatie open-source CMS-architectuur. Dat is een gedurfde uitspraak voor een v0.1-release. Dus we hebben het geïnstalleerd, een echte site gemigreerd, een paar dingen kapot gemaakt, en gedocumenteerd wat werkt, wat vaporware is, en of je volgende clientproject erop moet draaien.
Dat is een enorme uitspraak. Dus laten we dieper ingaan op wat er werkelijk is, wat veelbelovend is, en wat nog steeds slechts een roadmap-slide is.
De Architectuur: Waarom Dit Interessant Is
EmDash maakt fundamenteel andere architectuurkeuzes dan WordPress. De meeste zijn goede.
Gebouwd op Astro
Astro is al ons favoriete framework voor content-zware sites bij Social Animal. Nul JavaScript standaard, islands architecture voor wanneer je werkelijk interactiviteit nodig hebt (React, Svelte, Vue — kies je gif), en snelle statische pagina's met selectieve hydratatie. Het bouwen van een CMS op Astro betekent dat EmDash al dit alles gratis erft. Je vecht niet tegen het framework om prestatiedoelen te behalen — je begint daar al.
Je content-site laadt geen PHP-runtime bij elke request. Het serveert vooraf gerenderde HTML vanaf de edge. Dat maakt meer uit dan de meeste mensen beseffen.
Serverless op Cloudflare Workers
Het admin-paneel en de API-laag draaien op Cloudflare Workers — geen servers om mee om te gaan, automatische globale distributie, betaling per verzoek. Als je jaren WordPress-hostinginfrastructuur hebt beheerd — servers patchen om 2 uur 's nachts, in paniek raken bij verkeerspieken, worstelen met PHP-geheugengrenzen omdat een plugin besloot alles in het RAM te laden — ja. Een ander universum.
Cold starts gemeten in milliseconden, niet seconden. De DX is hier werkelijk goed.
TypeScript De Hele Weg Naar Beneden
Geen PHP. Geen gemengde talen. De gehele stack is TypeScript — plugin-ontwikkeling, thema-sjablonen, core CMS-logica, allemaal. Voor moderne webteams elimineert dit het context-switching-belasting. Je front-end devs kunnen bijdragen aan de CMS zelf zonder eerst een aparte taal te leren. Als je ooit hebt geprobeerd een React-developer enthousiast te krijgen om in functions.php te duiken, weet je hoe groot een deal dit is.
De Plugin-Veiligheidsdoorbraak
Dit is waar EmDash iets werkelijk innovatiefs doet. Besteed aandacht.
De grootste veiligheidsvunerabiliteit van WordPress zijn altijd plugins geweest. We weten dit allemaal — het is de olifant in elke kamer op elke WordCamp. Elke plugin kan willekeurige PHP uitvoeren, de database rechtstreeks aanroepen, verzoeken doen, het bestandssysteem lezen — in principe alles wat de servergebruiker kan doen. Eén gecompromitteerde plugin betekent een gecompromitteerde site. Dit is niet theoretisch; het is de aanvalsvector achter de meerderheid van WordPress-inbreuken. We hebben deze rommel schoongemaakt. Je hebt het waarschijnlijk ook gedaan.
EmDash introduceert sandbox-plugins met capability manifests. Elke plugin moet precies verklaren wat ze nodig heeft — specifieke databasetabellen, netwerkeindpunten, bestandspaden, API-bereiken. De runtime forceert deze verklaringen. Een contactformulier-plugin die schrijftoegang tot een submissions-tabel verklaart kan letterlijk niet je userstabel lezen, zelfs niet als de code kwaadwillig of gecompromitteerd is.
Denk mobiele app-machtigingen, maar voor CMS-plugins. Het is een fundamenteel beter veiligheidsmodel dan WordPress's "plugins kunnen alles doen en we hopen gewoon op het beste" benadering. De meeste agentschappen begrijpen dit verkeerd bij het evalueren van nieuwe platforms — ze kijken eerst naar functies. Kijk eerst naar veiligheidsarchitectuur. Altijd.
Hoe Capability Manifests Werken
Elke plugin wordt geleverd met een manifest.yaml (of JSON) bestand dat verklaart:
- Opslagingang: Welke D1-databasetabellen of R2-buckets het kan lezen/schrijven
- Netwerktoegang: Welke externe domeinen het kan aanroepen
- Routetoegang: Welke URL-patronen het kan verwerken
- Hook-toegang: Welke CMS-levenscyclusgebeurtenissen het kan volgen
- UI-toegang: Waar het admin-panelcomponenten kan injecteren
De EmDash-runtime valideert deze verklaringen en sandboxed execution dienovereenkomstig. Site-admins kunnen machtigingen beoordelen voordat ze worden geïnstalleerd, specifieke mogelijkheden intrekken, en plugin-gedrag controleren tegen wat werd verklaard.
Als de uitvoering overeenkomt met de visie, lost het een probleem op dat twintig jaar lang is ontstoken. Dat is geen overdrijving.
Wat EmDash Goed Doet
- Performance standaard: Astro's statische-first rendering plus edge-implementatie betekent dat sites snel zijn zonder extra optimalisatiewerk
- Moderne developer experience: TypeScript, HMR, component-gebaseerde thema's, Git-gebaseerde workflows — het spul dat we al in 2026 verwachten
- Veiligheidsarchitectuur: Het capability manifest-systeem is een echte stap vooruit, zonder voorbehoud
- Implementatie-eenvoud:
wrangler deployen je bent live wereldwijd. Geen nginx-configs. Geen serverprovisioning. Geen oproep naar je hostingprovider om middernacht. - MIT-licentie: Werkelijk open source, geen commerciële licentiergatches, geen open-core lokmiddel
- Edge-native data: Gebruikt Cloudflare D1 (SQLite aan de edge) en R2 voor assets, gegevens dicht bij gebruikers wereldwijd houden
Wat Er Ontbreekt (En Het Is Veel)
EmDash v0.1.0 is een beta. Het versienummer is eerlijk — ik geef hun dat. Dit is niet klaar:
Geen Plugin-Ecosysteem
WordPress heeft 60.000+ plugins. EmDash heeft een handvol voorbeelden van de eerste partij. Het capability manifest-systeem is goed ontworpen, maar een lege plugin-marktplaats betekent dat je alles op maat bouwt. E-commerce nodig? Bouw het. SEO-tools? Bouw ze. Formulierverwerking buiten de basis? Je weet het idee.
Dit is het cold start-probleem waar elke nieuwe CMS mee wordt geconfronteerd. Het duurt jaren om op te lossen. Er is geen snelkoppeling, en iedereen die je iets anders vertelt, verkoopt iets.
Beperkte Content Modeling
Het content type-systeem bestaat, maar het is niet op grote hoogte van WordPress's custom post types-ecosysteem — of zelfs headless-platforms zoals Sanity of Contentful. Complexe content-relaties, revisiehistorie, workflowstatussen — deze zijn ofwel basaal ofwel op de roadmap. En "op de roadmap" levert geen functies op. We hebben dit allemaal de harde manier geleerd.
Geen Migratiepad van WordPress
Er is geen WordPress-importeur. Bestaande content verplaatsen betekent handwerk of aangepast scripten. Voor agentschappen die tientallen WordPress-sites beheren, is dit nu een non-starter. Niet "inconveniënt." Een non-starter.
Admin UI Is Vroeg
Het admin-paneel werkt, maar het voelt als precies wat het is — een v0.1-interface. Content-bewerking mist de Pools van WordPress's block editor (die, goed, Gutenberg heeft zijn eigen problemen — begin me niet) of enig volwassen CMS. Media-management is basaal. Gebruikerrolbeheer is minimaal. Het doet het werk, maar nauwelijks.
Documentatiegaten
Docs dekken de basis maar slaan randgevallen volledig over. Een vreemd probleem tegenkomen? Je leest broncode. Dat is prima voor ervaren developers die ervan houden om TypeScript-gangen in te duiken — het is een dealbreaker voor agentschappen die junior devs snel moeten onboarden. We zijn hier eerder door andere "developer-first" tools gebrand, en het duurt altijd langer om op te lossen dan iemand verwacht.
Geen Multisite, Geen Meertalig, Geen Ingebouwde SEO
Functies waar WordPress-agentschappen vanzelfsprekend van zijn, bestaan eenvoudigweg nog niet. Dit is niet-onderhandelbare dingen voor het meeste productiewerk.
Wie Zou EmDash Vandaag Moeten Gebruiken
Developers die willen bijdragen aan het project. Als je in de visie gelooft en dit ding vorm wilt geven, is nu het moment. Vroege contribuanten aan open-source projecten hebben onevenredige invloed op architectuurbesluiten — dit is wanneer je werkelijk een verschil kunt maken in wat EmDash wordt. Dat venster sluit snel.
Teams die greenfield persoonlijke projecten of interne tools bouwen. Omgevingen met lage inzetten waar je breaking changes tussen versies kunt tolereren en je geen volwassen plugin-ecosysteem nodig hebt. Nevenprojecten. Experimenten. Scratch-your-own-itch-dingen.
Agentschappen die het platform evalueren voor toekomstige adoptie. Bouw een proof of concept. Word handig met de architectuur. Realiseer je waar de gaten zijn die je in de toekomst met aangepaste plugins kunt vullen.
Wie Zou EmDash NIET Vandaag Moeten Gebruiken
Iedereen met productie-clientsites. Het project zelf zegt dat het niet productie-klaar is. Geloof hen.
Agentschappen die een WordPress drop-in vervanging verwachten. Het is er geen. Het content-model, themesysteem en plugin-architectuur zijn fundamenteel anders. Dit is een migratie, geen upgrade. Plan dienovereenkomstig — en budget dienovereenkomstig, want je schatting zit waarschijnlijk fout.
Teams zonder sterke TypeScript-developers. Als je team PHP-first is, is de leercurve reëel. Ondermaak het niet — en neem niet aan dat "JavaScript is JavaScript" je erdoorheen zal krijgen. Dat zal niet.
Sites die e-commerce, lidmaatschap, LMS of andere complexe functionaliteit vereisen. Het ecosysteem is er gewoon nog niet. WooCommerce alleen al heeft meer functies dan EmDash's gehele plugin-catalogus. Dat is niet kritiek — het is gewoon wiskunde.
Wat Dit Betekent voor WordPress-Agentschappen
EmDash bedreigt WordPress vandaag niet. Maar het is een geloofwaardige visie van wat volgt.
Het WordPress-ecosysteem heeft echte structurele problemen — en we weten het allemaal. We hebben er jaren over gesproken in Slack-kanalen en conferentiegangenhalten. PHP-prestatiebeperkingen, plugin-veiligheidsnachtmerries, hosting-complexiteit, een block editor die niemand volledig tevreden stelt, en Automattic-bestuur van Zaagvertoon dat het vertrouwen van de gemeenschap door 2025 en tot 2026 fractureerde. Het is ruw geweest. Eerlijk gezegd? Het is vermoeiend geweest.
EmDash behandelt de meeste van deze op architectuurniveau. Als het project momentum opbouwt — als het plugin-ecosysteem groeit, als content-modelling volwassen wordt, als de admin UI pariteit bereikt — zou het binnen twee tot drie jaar een serieuze concurrent kunnen worden. Dat is een groot "als," maar het is niet onredelijk.
Onze Mening bij Social Animal
We kijken nauwlettend naar EmDash. De Astro-basis sluit aan bij hoe we al bouwen — we hebben ruim een jaar lang headless Astro-sites geleverd. De Cloudflare Workers-runtime is infrastructuur die we kennen en vertrouwen. TypeScript is onze primaire taal.
Maar we bevelen het nog niet aan voor clientprojecten. Wanneer we vandaag headless-sites bouwen, koppelen we Astro of Next.js met beproefde headless CMS-platforms — Sanity, Storyblok, wat het project past. Dat is nog steeds de verantwoorde keuze voor productiewerk, en dat zal zo blijven tot EmDash zichzelf in de echte wereld bewijst.
Wanneer EmDash v1.0 bereikt en een functionerend plugin-ecosysteem heeft, zullen we onder de eerste agentschappen zijn om het aan te nemen. De architectuur verdient het. De huidige staat doet dat niet.
Het Onderstel
EmDash CMS is de architecturaal gezondste WordPress-alternatief die we hebben gezien. Het sandbox-plugin-systeem alleen verdient de aandacht van de open-source gemeenschap — het is het soort idee dat je afvraagt waarom niemand dit eerder heeft gedaan. Ernstig, waarom heeft niemand dit eerder gedaan?
Maar architectuur is geen product. Ecosysteem, stabiliteit, documentatie en tooling — dat is wat een CMS voor professioneel gebruik levensvatbaar maakt. Je kunt geen mooi bouwplan niet leveren.
Bewak dit project. Draag bij als je kunt. Zet het nog niet voor clients in.