Li ho usati tutti e tre in produzione: Strapi per un progetto con content model custom, WordPress headless dietro un frontend Astro/Vue, EmDash per questo stesso blog. Ognuno vince in uno scenario preciso e perde male fuori da quello scenario. Ecco il confronto diretto, senza girarci intorno.
Il confronto in una tabella
Criterio | Strapi | WordPress headless | EmDash |
|---|---|---|---|
Hosting | Self-hosted (Node) | Self-hosted o gestito | Nativo Cloudflare |
Costo infrastruttura | Server dedicato da gestire | Server o hosting managed | Incluso nel consumo Cloudflare |
Curva di apprendimento | Media-alta | Bassa (per chi conosce WP) | Bassa (per chi conosce Astro) |
Editor per non-tecnici | Buono, ma da configurare | Ottimo, il migliore dei tre | Essenziale, ancora giovane |
Maturità plugin/ecosistema | Alta | Altissima | Bassa, in crescita |
Fit con stack JS-first | Buono (API generica) | Discreto, richiede attrito | Ottimo, nativo per Astro |
Content model custom | Il più flessibile | Limitato senza plugin extra | Semplice, meno flessibile |
Scenario ideale | Prodotto con content model custom e team dev | Cliente non tecnico che edita da solo | Sito Astro con un solo editor |
Tre scenari, tre scelte diverse
Sito di contenuti solo tuo, su Astro → EmDash. Se sei l'unico editor e il sito è già su Astro, l'integrazione nativa con Cloudflare toglie di mezzo un intero livello di complessità (niente webhook, niente server separato). Il prezzo è un ecosistema ancora giovane, che per un progetto personale è un compromesso accettabile.
Cliente che deve editare da solo e ha bisogno di plugin SEO o e-commerce maturi → WordPress headless. Nessuno dei tre batte WordPress quando il criterio è "un non-tecnico deve poter lavorare senza formazione, con plugin production-ready per ogni esigenza". L'attrito dell'architettura headless (API custom, caching da ripensare) è il prezzo per tenere l'admin che il cliente già conosce.
Prodotto con content model custom e un team dev → Strapi. Quando il progetto ha bisogno di relazioni complesse tra contenuti, ruoli granulari, e logiche di business che nessun CMS "a blocchi" replica facilmente, la flessibilità di Strapi vale l'overhead di doverlo self-hostare e mantenere nel tempo.
La domanda che taglia la scelta
Prima ancora del confronto tecnico, la domanda utile è: chi edita i contenuti, e cosa deve poter fare senza il tuo aiuto? Se la risposta è "un cliente non tecnico" → WordPress. Se è "solo io, su un progetto Astro" → EmDash. Se è "un content model che nessun CMS pronto replica" → Strapi. Il resto — performance, costi, maturità — conta, ma è secondario rispetto a questa prima risposta.
Per i dettagli e le esperienze specifiche con ciascuno, i tre pezzi della serie restano il posto giusto dove approfondire.
Serie completa: Strapi in produzione · WordPress headless in produzione · EmDash in produzione
Perché ho scelto EmDash per questo blog l'ho spiegato in EmDash: il CMS che uno sviluppatore Astro aspettava. Se il dubbio vero è il database sotto il CMS, la logica è la stessa di SQLite vs Postgres per un prodotto indie: parti dal vincolo, non dalla moda.
