Non ho mai usato WordPress. Non per snobismo, semplicemente il mio stack è sempre stato un altro: Astro, Next.js, Node.js, TypeScript, infrastrutture serverless. Quando si è trattato di scegliere cosa usare per fnbit.net, però, mi sono scontrato con un problema che chiunque lavori con Astro conosce bene: se vuoi un CMS vero, con admin panel, gestione contenuti, plugin, finisci quasi sempre per uscire dal tuo stack e appoggiarti a qualcosa di esterno, spesso proprio WordPress in modalità headless.
Con EmDash questo problema non si pone. Ed è per questo che l'ho scelto per il mio blog.
Perché WordPress resta un compromesso, anche in headless
WordPress ha quasi 24 anni e resta lo standard de facto per un motivo semplice: funziona, ha un ecosistema enorme, ed è accessibile a chi non scrive codice. Ma per chi costruisce con Astro, integrarlo — anche solo come sorgente di contenuti in modalità headless — significa portarsi dietro un'architettura pensata per un mondo completamente diverso: PHP, plugin con accesso libero a filesystem e database, un modello di sicurezza che oggi definiremmo fragile. Gran parte delle vulnerabilità note su WordPress nasce proprio da lì: i plugin non hanno confini, e uno solo compromesso può compromettere tutto il sito.
Non è un problema di implementazione, è strutturale. E per uno stack TypeScript-first, è anche semplicemente attrito inutile.
Cosa fa EmDash diversamente
EmDash è un CMS open source costruito da Cloudflare, nativo su Astro, pensato da zero per architetture serverless. Non è un adattamento, è scritto per lo stesso mondo in cui lavoro ogni giorno:
- Integrazione diretta con Astro: si aggiunge come integration nel config e basta, niente API esterne da orchestrare
- Contenuti come schema di database, non come codice: chi non sviluppa crea le collezioni dall'admin, io genero i tipi TypeScript direttamente dallo schema live con
npx emdash types - Query tramite le Live Collections di Astro, senza rebuild e senza un layer API separato da mantenere
- Storage flessibile: D1, Turso o PostgreSQL per i dati, R2 o qualsiasi storage S3-compatibile per i media
Il punto che mi ha convinto di più, da sviluppatore, è però il modello di sicurezza dei plugin: ogni plugin gira isolato in un Worker isolate di Cloudflare, con un manifest che dichiara esplicitamente le proprie capability. Un plugin per l'invio email dichiara solo quello e non può toccare nient'altro. È il tipo di sandboxing che in un progetto enterprise pretenderei comunque di costruire a mano — qui è già parte dell'architettura.
C'è anche un dettaglio che guarda avanti più di quanto sembri: EmDash è pensato per essere interrogato anche da agenti AI, con un server MCP dedicato, una CLI che risponde in JSON e documentazione strutturata apposta per essere consumata da un modello. Non è un aggiunta cosmetica, è coerente con la direzione in cui sta andando tutto lo sviluppo software.
Perché lo scelgo per fnbit.net
Non sto dicendo che WordPress sia morto — gira ancora su una fetta enorme del web e continuerà a farlo. Ma per chi parte da zero oggi con uno stack Astro/TypeScript, come faccio io ogni giorno lavorando su prodotti enterprise e progetti personali, forzare WordPress dentro l'equazione comincia a essere una scelta di abitudine più che di reale convenienza tecnica.
fnbit.net parte da qui: raccontare tecnologia, AI e sviluppo usando gli strumenti che considero davvero il prossimo passo, non quelli che restano per inerzia.
