Deine WordPress-Installation startet 47 Datenbankabfragen, bevor ein Besucher deine Startseite sieht. EmDash startet null. Es ist ein Open-Source-CMS, das am 1. April 2026 als v0.1.0 Beta veröffentlicht wurde — gebaut mit TypeScript auf Astro, läuft serverless auf Cloudflare Workers, wird unter der MIT-Lizenz bereitgestellt. Die Betreuer nannten es nicht eine WordPress-Alternative oder einen WordPress-Konkurrenten. Sie nannten es den WordPress Nachfolger — die nächste Generation der Open-Source-CMS-Architektur. Das ist eine kühne Behauptung für ein v0.1-Release. Also haben wir es installiert, eine echte Website migriert, ein paar Dinge kaputt gemacht und dokumentiert, was funktioniert, was Vaporware ist, und ob dein nächstes Client-Projekt darauf laufen sollte.

Das ist eine massive Behauptung. Also schauen wir uns an, was tatsächlich vorhanden ist, was vielversprechend ist, und was immer noch nur ein Roadmap-Folie ist.

Die Architektur: Warum sie interessant ist

EmDash trifft grundlegend andere architektonische Entscheidungen als WordPress. Die meisten davon sind gute.

Gebaut auf Astro

Astro ist bereits unser Favorit-Framework für inhaltsreiche Websites bei Social Animal. Null JavaScript standardmäßig, Islands-Architektur für wenn du tatsächlich Interaktivität brauchst (React, Svelte, Vue — wähle dein Gift), und schnelle statische Seiten mit selektiver Hydration. Ein CMS auf Astro zu bauen bedeutet, dass EmDash das alles kostenlos erbt. Du kämpfst nicht gegen das Framework, um Performance-Ziele zu erreichen — du startest schon dort.

Deine Content-Website lädt keine PHP-Laufzeit bei jeder Anfrage. Sie bedient vorab gerenderte HTML vom Edge. Das ist wichtiger als die meisten Menschen realisieren.

Serverless auf Cloudflare Workers

Das Admin-Panel und die API-Schicht laufen auf Cloudflare Workers — keine Server zum Betreuen, automatische globale Verteilung, Pay-per-Request-Preisgestaltung. Falls du Jahre damit verbracht hast, WordPress-Hosting-Infrastruktur zu verwalten — Server um 2 Uhr morgens zu patchen, in Panik zu verfallen bei Traffic-Spitzen, mit PHP-Speicherlimits zu kämpfen, weil ein Plugin beschlossen hat, alles in den RAM zu laden — ja. Eine völlig andere Welt.

Kaltstarts im Millisekundenbereich, nicht Sekunden. Die DX ist hier wirklich gut.

TypeScript überall

Kein PHP. Keine gemischten Sprachen. Der gesamte Stack ist TypeScript — Plugin-Entwicklung, Theme-Vorlagen, Core-CMS-Logik, alles davon. Für moderne Web-Teams tötet dies die Context-Switching-Gebühren. Deine Frontend-Entwickler können zum CMS selbst beitragen, ohne zuerst eine separate Sprache zu lernen. Falls du jemals versucht hast, einen React-Entwickler dazu zu begeistern, in functions.php zu tauchen, weißt du, wie wichtig das ist.

Der Plugin-Sicherheitsdurchbruch

Hier macht EmDash etwas wirklich Neuartiges. Pass auf.

WordPress's größte Sicherheitslücke waren schon immer Plugins. Wir alle wissen das — es ist der Elefant in jedem Raum auf jedem WordCamp. Jedes Plugin kann beliebiges PHP ausführen, direkt auf die Datenbank zugreifen, Netzwerkanfragen machen, das Dateisystem lesen — im Grunde alles tun, was der Server-Benutzer tun kann. Ein kompromittiertes Plugin bedeutet eine kompromittierte Website. Das ist nicht theoretisch; es ist der Angriffsvektor hinter der Mehrheit von WordPress-Verstößen. Wir haben diese Durcheinander bereinigt. Du wahrscheinlich auch.

EmDash führt Sandboxed-Plugins mit Capability-Manifesten ein. Jedes Plugin muss genau deklarieren, was es zugreifen muss — spezifische Datenbanktabellen, Netzwerk-Endpunkte, Dateipfade, API-Bereiche. Die Laufzeit erzwingt diese Deklarationen. Ein Kontaktformular-Plugin, das Schreibzugriff auf eine submissions-Tabelle deklariert, kann buchstäblich nicht deine Benutzertabelle lesen, selbst wenn der Code böswillig oder kompromittiert ist.

Denk an Mobile-App-Berechtigungen, aber für CMS-Plugins. Es ist ein fundamental besseres Sicherheitsmodell als WordPress's "Plugins können alles tun und wir hoffen einfach auf das Beste"-Ansatz. Die meisten Agenturen verstehen das falsch, wenn sie neue Plattformen bewerten — sie schauen zuerst auf Features. Schaue zuerst auf die Sicherheitsarchitektur. Immer.

Wie Capability-Manifeste funktionieren

Jedes Plugin wird mit einer manifest.yaml (oder JSON) Datei bereitgestellt, die deklariert:

  • Storage-Zugriff: Welche D1-Datenbanktabellen oder R2-Buckets es lesen/schreiben kann
  • Netzwerkzugriff: Welche externen Domains es aufrufen kann
  • Route-Zugriff: Welche URL-Muster es verarbeiten kann
  • Hook-Zugriff: Welche CMS-Lebenszyklusereignisse es abonnieren kann
  • UI-Zugriff: Wo es Admin-Panel-Komponenten injizieren kann

Die EmDash-Laufzeit validiert diese Deklarationen und Sandboxen die Ausführung entsprechend. Website-Administratoren können Berechtigungen vor der Installation überprüfen, spezifische Funktionen widerrufen und das Plugin-Verhalten gegen das überprüfen, was deklariert wurde.

Falls die Ausführung der Vision entspricht, löst es ein Problem, das seit zwanzig Jahren schwelt. Das ist keine Übertreibung.

Was EmDash richtig macht

  • Performance standardmäßig: Astro's statisch-first Rendering plus Edge-Deployment bedeutet, dass Websites schnell sind, ohne dass du zusätzliche Optimierungsarbeit leisten musst
  • Moderne Developer Experience: TypeScript, HMR, Component-basierte Themes, Git-basierte Workflows — das Zeug, das wir 2026 bereits erwarten
  • Sicherheitsarchitektur: Das Capability-Manifest-System ist ein echter Fortschritt, vollständig
  • Deployment-Einfachheit: wrangler deploy und du bist global live. Keine nginx-Konfiguration. Kein Server-Provisioning. Kein Anrufen deines Hosting-Anbieters um Mitternacht
  • MIT-Lizenz: Wirklich Open Source, keine kommerziellen Lizenzierungsfallen, kein Open-Core-Köder-und-Wechsel
  • Edge-native Daten: Verwendet Cloudflare D1 (SQLite am Edge) und R2 für Assets, hält Daten global nahe bei Benutzern

Was fehlt (Und es ist viel)

EmDash v0.1.0 ist ein Beta. Die Versionsnummer ist ehrlich — ich gebe ihnen das. Hier ist, was nicht bereit ist:

Kein Plugin-Ökosystem

WordPress hat 60.000+ Plugins. EmDash hat eine Handvoll First-Party-Beispiele. Das Capability-Manifest-System ist gut entworfen, aber ein leerer Plugin-Marketplace bedeutet, dass du alles Custom baust. Brauchst du E-Commerce? Baue es. SEO-Tools? Baue sie. Formularverarbeitung über die Grundlagen hinaus? Du kennst die Idee.

Das ist das Kaltstart-Problem, dem sich jedes neue CMS stellt. Es dauert Jahre, es zu lösen. Es gibt keine Abkürzung, und jeder, der dir das Gegenteil sagt, verkauft dir etwas.

Begrenzte Content-Modellierung

Das Content-Type-System existiert, aber es ist längst nicht so reif wie WordPress's Custom-Post-Types-Ökosystem — oder sogar Headless-Plattformen wie Sanity oder Contentful. Komplexe Content-Beziehungen, Versionsverlauf, Workflow-Zustände — diese sind entweder rudimentär oder sitzen auf der Roadmap. Und "auf der Roadmap" stellt keine Features bereit. Wir haben das alle auf die harte Tour gelernt.

Kein Migrationspfad von WordPress

Es gibt keine WordPress-Importfunktion. Das Verschieben vorhandener Inhalte bedeutet manuelle Arbeit oder benutzerdefiniertes Scripting. Für Agenturen, die Dutzende von WordPress-Sites verwalten, ist das gerade jetzt ein No-Go. Nicht "unbequem". Ein No-Go.

Admin-UI ist früh dran

Das Admin-Panel funktioniert, aber es fühlt sich genau wie das an, was es ist — eine v0.1-Schnittstelle. Content-Bearbeitung fehlt der Poliertheit von WordPress's Block-Editor (der, okay, Gutenberg hat seine eigenen Probleme — fang nicht an) oder eines reifen CMS. Media-Management ist grundlegend. Benutzerrollenverwaltung ist minimal. Es erledigt die Arbeit, aber kaum.

Dokumentationslücken

Docs decken die Grundlagen ab, aber überspringen Edge Cases völlig. Stoß auf ein komisches Problem? Du liest Source Code. Das ist in Ordnung für erfahrene Entwickler, die gerne durch TypeScript schnüffeln — es ist ein Deal-Breaker für Agenturen, die Junior-Entwickler schnell einarbeiten müssen. Wir wurden von diesem anderen "Developer-First"-Tools schon verbrannt, und es dauert immer länger zu beheben, als jemand erwartet.

Keine Multisite, Keine mehrsprachig, Keine eingebaute SEO

Features, die WordPress-Agenturen für selbstverständlich halten, existieren einfach noch nicht. Das ist nicht verhandelbar für die meisten Production-Arbeiten.

Wer sollte EmDash heute verwenden

Entwickler, die zum Projekt beitragen möchten. Falls du an die Vision glaubst und diese Sache prägen möchtest, ist jetzt der richtige Zeitpunkt. Frühe Mitwirkende zu Open-Source-Projekten haben überproportionalen Einfluss auf Architekturentscheidungen — das ist, wenn du wirklich EmDash's Zukunft beeinflussen kannst. Dieses Fenster schließt sich schnell.

Teams, die neue persönliche Projekte oder interne Tools bauen. Low-Stakes-Umgebungen, wo du Breaking Changes zwischen Versionen tolerieren kannst und keine reifes Plugin-Ökosystem brauchst. Side-Projekte. Experimente. Kratze-deinen-eigenen-Juckreiz-Sachen.

Agenturen, die die Plattform für zukünftige Adoption bewerten. Baue ein Proof of Concept. Werde mit der Architektur vertraut. Figur heraus, wo die Lücken sind, die du mit benutzerdefinierten Plugins in Zukunft füllen könntest.

Wer sollte EmDash heute NICHT verwenden

Jeder mit Production Client Sites. Das Projekt selbst sagt, es ist nicht produktionsbereit. Glaub ihnen.

Agenturen, die einen WordPress Drop-in Replacement erwarten. Es ist keiner. Das Content-Modell, Theme-System und Plugin-Architektur sind fundamental unterschiedlich. Das ist eine Migration, keine Upgrade. Plan entsprechend — und budgetier entsprechend, denn deine Schätzung ist wahrscheinlich falsch.

Teams ohne starke TypeScript-Entwickler. Falls dein Team PHP-first ist, ist die Lernkurve real. Unterschätze sie nicht — und nimm nicht an, "JavaScript ist JavaScript" wird dich durchbringen. Das wird es nicht.

Websites, die E-Commerce, Membership, LMS oder andere komplexe Funktionalität benötigen. Das Ökosystem ist einfach noch nicht da. WooCommerce allein hat mehr Features als EmDash's gesamter Plugin-Katalog. Das ist keine Kritik — es ist einfach Mathe.

Was das für WordPress-Agenturen bedeutet

EmDash bedroht WordPress heute nicht. Aber es ist eine glaubwürdige Vision dessen, was kommt.

Das WordPress-Ökosystem hat echte strukturelle Probleme — und wir alle kennen es. Wir sprechen darüber seit Jahren in Slack-Kanälen und auf Konferenzen. PHP-Performance-Limitierungen, Plugin-Sicherheitsnachtalben, Hosting-Komplexität, ein Block-Editor, der niemandem vollständig zufriedenstellt, und Automattic-Governance-Bedenken, die Gemeinschaftsvertrauen durch 2025 und 2026 zersplitterten. Es war rau. Ehrlich? Es war erschöpfend.

EmDash adressiert die meisten davon auf der architektonischen Ebene. Falls das Projekt Momentum aufbaut — falls das Plugin-Ökosystem wächst, falls Content-Modellierung reift, falls die Admin-UI Parität erreicht — könnte es zu einem ernsthaften Konkurrenten innerhalb von zwei bis drei Jahren werden. Das ist ein großes "Falls", aber es ist nicht unvernünftig.

Unser Take bei Social Animal

Wir beobachten EmDash genau. Die Astro-Foundation passt zu wie wir bereits bauen — wir liefern seit über einem Jahr Headless-Astro-Sites. Die Cloudflare Workers Runtime ist Infrastruktur, der wir kennen und vertrauen. TypeScript ist unsere primäre Sprache.

Aber wir empfehlen es noch nicht für Client-Projekte. Wenn wir heute Headless-Sites bauen, paaren wir Astro oder Next.js mit bewährten Headless-CMS-Plattformen — Sanity, Storyblok, was auch immer zum Projekt passt. Das ist immer noch die verantwortungsvolle Wahl für Production-Arbeit, und das wird so bleiben, bis EmDash sich in der realen Welt beweist.

Wenn EmDash v1.0 trifft und ein funktionierendes Plugin-Ökosystem hat, werden wir zu den ersten Agenturen gehören, die es adoptieren. Die Architektur verdient es. Der aktuelle Zustand nicht.

Das Endergebnis

EmDash CMS ist die architektonisch solideste WordPress-Alternative, die wir gesehen haben. Allein das sandboxed Plugin-System verdient die Aufmerksamkeit der Open-Source-Community — es ist die Art von Idee, die dich fragen lässt, warum das niemand früher gemacht hat. Ernsthaft, warum hat das niemand früher gemacht?

Aber Architektur ist kein Produkt. Ökosystem, Stabilität, Dokumentation und Tooling — das ist, was ein CMS für berufliche Nutzung lebensfähig macht. Du kannst keinen schönen Blueprint versenden.

Beobachte dieses Projekt. Trag bei, falls du kannst. Deploy es noch nicht für Clients.