Come abbiamo fatto convivere il tema WordPress e un frontend headless in Vue, senza riscrivere tutto da zero.

/ INTRODUZIONE

Negli ultimi 4 anni abbiamo lavorato su un progetto WordPress che non rientra nella classica dicotomia headless Vs monolite. Stiamo parlando di un progetto e-commerce molto importante. Esso è costituito da due negozi online che gestiscono 3 funzioni principali:

• Funnel di vendita senza carrello: i prodotti venduti arrivano da Api di terze parti;
• Landing pages mirate: circa 30 templates di landings di tipo “Scarcity & Urgency”;
• Area profilo utente per gestione metodi di pagamento e abbonamenti attivi.

La situazione iniziale da cui siamo partiti era un tema WordPress consolidato, un plugin per le rotte degli endpoint e circa 30 templates .php statici per le landing.  

Riassumendo: tanto PHP,  jQuery e poca flessibilità.

/ IL NOSTRO OBIETTIVO

Modernizzare e garantire una delivery continua, mantenendo gli aggiornamenti e la retrocompatibilità.

/ IL METODO

Abbiamo iniziato a valutare React. Tuttavia, non avendo un background solido con React, e sapendo che Vue stava crescendo, abbiamo deciso di fare dei tests con Vue.js. Da subito, abbiamo capito che Vue era più veloce e versatile, quindi abbiamo deciso di adottarlo come strumento principe di tutte le nostre future lavorazioni per il cliente.

/ COSA ABBIAMO CAPITO

Reattività Automatica e Performance

In Vue.js, la reattività è basata su dependency tracking.

Quando usi ref o reactive, Vue:

1. intercetta le letture delle variabili;
2. registra quali componenti le usano;
3. aggiorna solo ciò che dipende da quella variabile.

In React la filosofia è diversa.

Quando cambia uno state:

1. l’intero componente viene rieseguito;
2. React fa il diff del Virtual DOM;
3. aggiorna il DOM reale.

Meno boilerplate: Non ci siamo preoccupati di ottimizzare manualmente le performance tanto quanto si farebbe in React; Vue lo fa per te “sotto il cofano”. Inoltre abbiamo capito da subito che, andando a realizzare piccole app, non ci sarebbe servito un framework capace di gestire grandi progetti enterprise.

Documentazione e dipendenze

Uno dei vantaggi storici di Vue è la qualità della sua documentazione ufficiale.

Ecosistema ufficiale

Vue fornisce soluzioni ufficiali e integrate per i problemi comuni:

• Router: Vue Router;
• State Management: Pinia o Vuex (abbiamo usato Pinia ed è molto comodo);
• Tooling: Vite, che è molto più veloce di Webpack (inizialmente abbiamo usato webpack ma era troppo lento nella compilazione).

In React, abbiamo avuto l’impressione di dover scegliere tra decine di librerie di terze parti e sperare di trovare un giusto setup mantenibile nel tempo.

Flessibilità di Vue: Options API vs Composition API

Anche se sembrerebbe più rigido di React, Vue non impone un unico modo di scrivere codice.

• Options API: Perfetta per principianti o piccoli progetti, organizza il codice per “tipo” (data, methods, computed). La prima parte del progetto legata al Funnel è stata realizzata con le Options API.
• Composition API: Introdotta con Vue 3, offre la stessa potenza e riusabilità degli Hooks di React, ma senza le trappole mentali legate al ciclo di vita degli hook stessi. Stiamo convertendo tutto il progetto verso le Composition Api per avere maggiore controllo sulla codebase.

/ LA REALIZZAZIONE

Prima di tutto abbiamo deciso di lasciare alcune parti nel flusso tradizionale di template PHP, mentre altre sono state spinte verso un approccio headless con Vue.

Nello spiecifico abbiamo realizzato 3 Vue single page applications (SPA) montate dentro dei template .php dedicati:

• SPA per gestire le landing pages in modo dinamico. Un solo file .php gestisce tutte le tipologie di landings necessarie.
• SPA per gestire il funnel di vendita: velocità di acqusito, tracciamenti e thankyou page.
• SPA per l’area profilo: gestione carte, paypal, preferenze privacy tutto in uno.

Il punto di forza ulteriore è che le tre SPA non penalizzano in alcun modo la SEO del resto del sito legacy. Stiamo infatti parlando di un intervento fatto su piattaforme dalla vita ultra decennale, che sono ben piazzate nelle SERP.

/ MA LA DOMANDA CHE SORGE ALLORA È: PERCHÈ NON UNA RISCRITTURA COMPLETA?

Quando si parla di WordPress headless, la tentazione è sempre quella: “rifacciamo tutto quanto”.

Nella pratica però ci siamo trovati davanti a vincoli troppo importanti per essere ignorati.

• il sito aveva già pagine e logiche legacy che funzionavano;
• il team conosceva bene il ciclo classico WordPress (template, hook, plugin);
• tempi e budget non permettevano una transizione radicale totale.

La filosofia è stata introdurre Vue dove serviva in modo graduale. L’inserimento di Vue non è partito da un obiettivo ideologico (“dobbiamo essere headless”), ma da esigenze specifiche:

• componenti interattivi difficili da gestire in puro PHP/jQuery;
• UX più dinamiche in sezioni ad alta interazione;
• necessità di separare meglio presentazione e logica lato client.

In pratica, Vue è entrato come “isola” in aree mirate, lasciando il resto nel modello classico WordPress.

WordPress resta il centro per:

• gestione contenuti editoriali e arricchimento landing pages (uso quotidiano di ACF);
• integrazione plugin di terze parti (vedi Yoast ad esempio);
• endpoint e logica server dove necessario.

VUE prende in carico:

• UX più fluide dove il tema tradizionale risultava rigido da modificare;
• rendering dinamico di specifiche sezioni;
• stato lato client più ricco.

/ COSA ABBIAMO GUADAGNATO?

Migrazione progressiva senza downtime architetturale: abbiamo potuto intervenire per priorità, evitando blocchi lunghi e riscritture massive.

Meno rischio operativo: lasciare intatti i flussi stabili WordPress ci ha permesso di ridurre regressioni su aree business-critical.

Migliore esperienza utente nei punti giusti: le aree potenziate con Vue hanno guadagnato in reattività e qualità percepita.

/ LE DIFFICOLTÀ REALI E I PUNTI DI DEBOLEZZA DELLA NOSTRA SCELTA.

Duplice complessità

Con due paradigmi insieme, aumentano i punti di attenzione: build frontend, deploy, dipendenze, debugging cross-layer. Inoltre WordPress nasce con React sotto al cofano (vedi Gutemberg). Invece Vue è qualcosa che funziona bene, ma non fa parte dell’ecosistema WordPress.

Costo cognitivo

Nuovi membri del team devono capire entrambe le anime del progetto, non solo una. Essendo Vue meno diffuso, sono necessari KT dedicati ai nuovi sviluppatori alle prime armi con Vue.

/ QUANDO CONSIGLIAMO UN APPROCCIO IBRIDO

• ha senso se hai un progetto WordPress già in produzione con valore reale (vale lo stesso discorso anche con altri CMS);
• vuoi modernizzare senza fermare il business;
• hai bisogno di componenti avanzati solo in parti specifiche.

Ha meno senso se:

• vuoi una separazione totale dei layer fin da subito;
• puoi permetterti una riscrittura completa;
• hai già una pipeline frontend/headless molto matura.

/ CONCLUSIONE

Questa esperienza ci ha insegnato che la soluzione più solida è spesso la terza via: un’architettura ibrida, guidata dal contesto. La migrazione migliore non è quella più radicale, ma quella che il team riesce a sostenere nel tempo.