React o Vue, cosa scelgo? Nuxt.js: perché è il framework con cui lavoro ogni giorno

Quando un'agenzia mi chiede su cosa costruire un progetto nuovo, la domanda di solito è «React o Vue?». La mia risposta è un terzo nome: Nuxt.js. Tra i tecnici è meno conosciuto di quanto meriti, quindi qui spiego da dove nasce la scelta: prima perché preferisco Vue a React, che pure ho usato in produzione, poi perché di Vue da solo non mi accontento quasi mai.

React e Vue: simili nei fini, diversi nel modo

React e Vue risolvono lo stesso problema: costruire interfacce a componenti che si aggiornano quando cambiano i dati. Entrambi usano un DOM virtuale, entrambi hanno un ecosistema solido, entrambi reggono progetti grandi. Ho scritto la struttura e il frontend di un wallet come estensione Chrome in React, TypeScript e Redux, quindi non parlo per sentito dire. La differenza che conta, per me, sta nel modo in cui si scrive il codice ogni giorno.

Il componente a file singolo

In Vue un componente è un file .vue con tre blocchi separati: <template> per il markup, <script setup> per la logica, <style scoped> per lo stile limitato a quel componente. Ogni cosa ha il suo posto, e aprendo un file si capisce subito dove guardare.

In React il markup dei componenti viene comunemente descritto con JSX, insieme alla logica che lo compone; gli stili possono vivere in file separati, CSS Modules o altri sistemi. È una scelta coerente, e c'è chi la preferisce proprio per questo. A me ha sempre dato fastidio: preferisco la separazione esplicita dei componenti Vue. In entrambi gli ecosistemi la leggibilità dipende anche da dimensione dei componenti e convenzioni del progetto.

Piccoli attriti quotidiani

C'è poi un dettaglio che sembra banale e non lo è: in JSX l'attributo class diventa className, for diventa htmlFor, gli stili in linea diventano oggetti. In Vue il template è HTML, con le direttive (v-if, v-for, v-model) aggiunte dove servono. Copio un frammento da un prototipo o da un file di design e funziona; con JSX va riscritto.

La reattività

Con Vue dichiaro uno stato con ref o reactive e un valore derivato con computed: il framework traccia da solo le dipendenze e aggiorna solo ciò che serve. In React gli aggiornamenti seguono un modello diverso e gli effetti richiedono attenzione alle dipendenze. useMemo e useCallback sono ottimizzazioni da valutare, non requisiti per ogni componente; nei progetti che adottano React Compiler parte della memoizzazione è automatica. Anche Vue richiede attenzione a effetti, dipendenze e aggiornamenti costosi. Per il mio modo di lavorare il suo modello resta più immediato.

Per tutte queste ragioni, tra i due ho scelto Vue: non perché React sia peggiore, ma perché con Vue scrivo meglio, più in fretta e con meno errori. E programmando dal 1999 ho imparato che lo strumento con cui si lavora bene conta più della classifica di popolarità.

Perché non uso Vue da solo

Vue è un framework per costruire interfacce. Per un sito vero servono molte altre cose: indirizzi e routing, rendering lato server per SEO e velocità, recupero dei dati, metadati, lingue, una parte server per le API. Con Vue da solo vanno scelte, collegate e mantenute a mano. Nuxt.js è Vue con tutto questo già integrato e coerente: posso fare tutto quello che farei con Vue, ma con dei superpoteri.

Routing basato sui file

Nella struttura predefinita di Nuxt 4, un file in app/pages/ definisce una pagina; app/pages/servizi/[slug].vue definisce una rotta dinamica. Niente configurazione del router da tenere allineata. Layout e middleware di navigazione seguono le convenzioni del framework. I middleware possono gestire i reindirizzamenti, ma autenticazione e autorizzazione devono essere applicate anche agli endpoint sul server.

Rendering ibrido, pagina per pagina

Nuxt.js può rendere le pagine sul server a ogni richiesta, generarle in anticipo come HTML statico, o fare le due cose nello stesso progetto. Con le routeRules decido rotta per rotta: le pagine di contenuto generate in fase di build, un'area riservata renderizzata solo nel browser, un elenco aggiornato con una cache che si rinnova in background. Il motore che gira sotto è lo stesso.

Un server incluso

Nuxt.js include Nitro, un motore server: un file in server/api/ diventa un endpoint. In questo sito la chat AI, la sitemap e i feed RSS sono server route di Nitro. Nitro offre preset per più piattaforme, ma il passaggio richiede di verificare API disponibili, dipendenze, storage, limiti di esecuzione e configurazione.

Dati senza doppie richieste

useFetch e useAsyncData recuperano i dati sul server e li passano al browser insieme alla pagina: in fase di idratazione il client non rifà la stessa chiamata. Sembra un dettaglio, ma è uno degli errori più comuni nelle applicazioni costruite a mano.

Moduli invece di colla

Le lingue con @nuxtjs/i18n (con indirizzi localizzati: /servizi in italiano, /en/services in inglese), i contenuti in Markdown con Nuxt Content, i font ottimizzati con @nuxt/fonts, la SEO con useSeoMeta. Ogni modulo si aggiunge alla configurazione e si integra con il resto, invece di essere una libreria da collegare a mano.

Meno codice di servizio

Componenti e composable si importano da soli, TypeScript è configurato fin dall'inizio, Vite rende lo sviluppo istantaneo. I componenti pesanti si caricano solo quando servono: la scena 3D di questa home, in three.js, viene caricata solo nel browser e solo dove compare.

Dove ho usato Nuxt.js

Questo sito è in Nuxt 4: contenuti in Markdown, due lingue, generazione statica e pubblicazione con GitHub e Netlify (lo racconto in Pubblicare un sito con GitHub e Netlify). Altura Vela è un gestionale su misura in Nuxt 4 collegato a una REST API, con calendario, aree per soci e skipper, contratti e pagamenti. Fix and Sail è un'applicazione Nuxt.js su Strapi. Tre progetti molto diversi, una sola base.

Quando Nuxt.js non è la scelta giusta

• Il team conosce solo React, o il progetto è obbligato a usarlo. Se devo scegliere React, ragiono come per Vue: non lo uso da solo ma con il framework che gli sta sopra, quindi Next.js, l'equivalente di Nuxt.js. Stessi motivi (routing sui file, rendering ibrido, parte server), stessa disciplina; imporre Vue sarebbe un costo.
• Il sito ha bisogno di un pannello ricco usato ogni giorno da molte persone. Lì WordPress resta spesso la scelta più sensata, come spiego in Da WordPress a Nuxt.js, GitHub e Netlify.
• Serve una libreria disponibile solo per React. Succede, soprattutto con alcuni componenti di interfaccia molto specifici: va verificato prima di scegliere.

SSR, idratazione e dati riservati

Il primo HTML e il primo rendering del browser devono descrivere lo stesso stato. Valori casuali, date calcolate in fusi diversi e letture del browser durante il rendering server possono produrre differenze di idratazione. Isolo le API disponibili solo nel browser e verifico gli avvisi durante l’accesso diretto alle pagine.

Con useFetch e useAsyncData il payload può evitare il recupero duplicato durante l’idratazione, purché chiavi e opzioni siano coerenti. Non trasferisco al client segreti o campi che l’utente non deve vedere: nasconderli nel template non li rimuove dal payload. Lo stato sensibile deve essere isolato per richiesta, senza singleton condivisi tra utenti. Cache e prerendering non vanno applicati indistintamente a risposte personali.

Questi vincoli contano più della preferenza sintattica per Vue o React quando si progetta un’area riservata.

Come la vedo io

Nuxt.js è il centro di un insieme di scelte che si tengono insieme: Vue e TypeScript per i componenti, Tailwind v4 con i token del design in @theme per lo stile (ne parlo in Tailwind CSS: perché lo uso), contenuti in Markdown versionati, pochi moduli e poche dipendenze, componenti caricati solo dove servono, ogni modifica con la sua anteprima prima di arrivare online. La chat di questo sito, ancorata a un unico file di conoscenza, e la pagina 404 con il videogioco sono nate così: piccole parti di codice che stanno al loro posto. È questo che cerco in uno strumento, più della sua popolarità.

Perché affidarlo a me

Dal 1999 ho consegnato più di 300 progetti, e da freelance collaboro con più di 30 agenzie, da Roma e da remoto. Con Nuxt.js costruisco siti veloci, multilingua e facili da far evolvere, e gestionali su misura che crescono senza cambiare base tecnica.

Se stai valutando lo stack di un nuovo progetto, scrivimi: in una chiacchierata di circa 20 minuti capiamo se Nuxt.js è la scelta giusta. Il servizio è in Creazione siti web.