Vue.js: cos’è, come funziona, a cosa serve e quando usarlo

Vue.js è un framework JavaScript per costruire interfacce utente. Il suo modello combina componenti, rendering dichiarativo e un sistema di reattività che permette all’interfaccia di aggiornarsi quando cambiano i dati da cui dipende.

Definirlo semplicemente “un framework per creare Single Page Application” è però riduttivo. Vue può essere introdotto in una pagina HTML già esistente, utilizzato per costruire componenti isolati oppure diventare la base di applicazioni front-end molto più articolate. La stessa documentazione ufficiale di Vue lo presenta come un framework progressivo e adottabile in modo incrementale.

Vue non sostituisce JavaScript, né elimina la necessità di comprendere HTML, CSS e browser. Aggiunge piuttosto un modello strutturato per risolvere un problema che diventa sempre più difficile man mano che un’interfaccia cresce: mantenere sincronizzati dati, stato e ciò che l’utente vede sullo schermo.

In questa guida vediamo come funziona realmente Vue.js, che rapporto ha con il DOM, come iniziare un progetto moderno, quali ruoli hanno Vite, Vue Router e Pinia, quando ha senso utilizzare TypeScript e soprattutto quando Vue è una buona scelta e quando introduce complessità di cui non hai bisogno.

Cos’è Vue.js

Vue.js è un framework open source dell’ecosistema JavaScript progettato principalmente per costruire interfacce web reattive e basate su componenti.

L’idea fondamentale è dichiarativa: invece di impartire continuamente istruzioni manuali al browser del tipo “trova questo elemento, sostituisci il testo, aggiungi questa classe, nascondi quell’altro elemento”, descrivi quale interfaccia deve risultare da un determinato stato.

Quando lo stato cambia, Vue si occupa di aggiornare le parti interessate dell’interfaccia.

Il modello concettuale può essere sintetizzato così:

stato → rendering → interfaccia → aggiornamento quando lo stato cambia

Dietro questa apparente semplicità ci sono diversi meccanismi — reattività, componenti, template, compilazione e aggiornamento del DOM — che vale la pena distinguere.

Perché Vue viene definito un framework progressivo

“Progressivo” non significa che Vue si aggiorni automaticamente o che rappresenti una fase intermedia verso un altro framework.

Significa soprattutto che puoi adottarlo con livelli di coinvolgimento differenti.

In una pagina prevalentemente server-rendered potresti utilizzare Vue soltanto per una sezione interattiva. In un progetto più grande puoi invece organizzare tutta l’interfaccia attraverso componenti Vue, introdurre routing, stato condiviso e una vera architettura applicativa.

La documentazione sui diversi modi di utilizzare Vue contempla infatti scenari molto differenti:

• miglioramento di HTML statico senza una build complessa;
• Web Components;
• Single Page Application;
• Server-Side Rendering;
• Static Site Generation;
• applicazioni più articolate costruite attraverso framework basati su Vue.

Questa gradualità è una delle caratteristiche che distinguono maggiormente Vue. L’adozione non deve necessariamente essere “tutto o niente”.

Vue, Vue.js e Vue JS significano la stessa cosa?

Sì. Vue, Vue.js, Vue JS e VueJS vengono normalmente utilizzati per indicare lo stesso framework.

Il nome ufficiale è Vue.js, spesso abbreviato semplicemente in Vue.

Non esistono quindi una tecnologia “Vue” e una distinta tecnologia “Vue JS”: cambiano soltanto le modalità con cui il nome viene scritto.

Vue 3 e Vue 2 non sono la stessa cosa

Quando leggi un tutorial Vue devi controllare a quale generazione del framework si riferisce.

Vue 3 è la major corrente sulla quale dovrebbero basarsi i nuovi progetti. Vue 2 ha raggiunto la fine del supporto ufficiale il 31 dicembre 2023.

Questo dettaglio ha conseguenze molto concrete. Molti tutorial ancora ben posizionati nei motori di ricerca utilizzano strumenti, pattern o raccomandazioni appartenenti all’ecosistema precedente.

Per esempio:

• Vue CLI compare ancora in numerose guide come metodo standard per iniziare;
• Vuex viene spesso presentato come soluzione predefinita per lo stato globale;
• alcuni esempi utilizzano convenzioni pensate soprattutto per Vue 2.

Il codice legacy non diventa automaticamente inutile, ma non va confuso con il percorso consigliato per un nuovo progetto Vue.

Come funziona Vue.js: reattività, componenti e DOM

Per capire Vue non serve imparare subito tutte le direttive o memorizzare le API.

Conviene comprendere prima tre concetti:

1. lo stato contiene informazioni;
2. il template descrive l’interfaccia che dipende da quelle informazioni;
3. il sistema di reattività permette a Vue di sapere quando qualcosa deve essere aggiornato.

Rendering dichiarativo e stato reattivo

Immagina un contatore.

Con JavaScript imperativo potresti conservare un numero, cercare un elemento nel documento e modificarne manualmente il testo dopo ogni click.

Con Vue puoi invece definire uno stato reattivo:

<script setup>
import { ref } from 'vue'

const conteggio = ref(0)
</script>

<template>
  <button @click="conteggio++">
    Click: {{ conteggio }}
  </button>
</template>

ref(0) crea uno stato reattivo inizializzato a zero.

Nel template:

{{ conteggio }}

dichiara che quella parte dell’interfaccia dipende da conteggio.

Quando l’utente fa click:

@click="conteggio++"

lo stato cambia e Vue può aggiornare ciò che deve essere visualizzato.

La differenza concettuale è importante: non stiamo dicendo direttamente al DOM quale testo sostituire. Stiamo modificando lo stato dell’applicazione e lasciando che Vue riconcili l’interfaccia con il nuovo valore.

Che rapporto c’è tra Vue e il DOM

Il browser continua a lavorare con il DOM, Document Object Model. Vue non lo elimina.

Il DOM rimane la rappresentazione ad albero del documento con cui il browser lavora.

Quello che cambia è il livello al quale programmi normalmente l’interfaccia.

In JavaScript nativo puoi fare:

const contatore = document.querySelector('#contatore')

contatore.textContent = 'Click: 1'

Qui individui direttamente un nodo e ne modifichi il contenuto.

Con Vue tenderai invece a descrivere il risultato:

<p>Click: {{ conteggio }}</p>

Il framework si occupa della relazione fra stato corrente e DOM risultante.

Capire il DOM resta quindi utile anche se lavori quasi sempre attraverso Vue. Quando devi diagnosticare un problema di rendering, capire un evento, integrare una libreria esterna o usare API native del browser, devi sapere che cosa il framework sta astraendo.

Reattività: come Vue sa che qualcosa è cambiato

Un’interfaccia diventa difficile da mantenere quando molte parti dipendono dagli stessi dati.

Immagina un carrello ecommerce. Il numero di prodotti può influenzare contemporaneamente:

• badge dell’icona carrello;
• totale degli articoli;
• prezzo complessivo;
• stato del pulsante checkout;
• messaggio “carrello vuoto”;
• eventuali soglie per la spedizione gratuita.

Aggiornare manualmente ogni elemento a ogni modifica significa creare una rete di sincronizzazioni fragile.

Il sistema reattivo di Vue permette invece di esprimere dipendenze fra stato e interfaccia. Quando cambia una dipendenza osservata, il framework può aggiornare le parti interessate.

Non significa che “Vue rende automaticamente qualsiasi applicazione veloce”. La reattività è un meccanismo per coordinare aggiornamenti; performance, architettura e qualità del codice dipendono da molti altri fattori.

Template e direttive

Vue utilizza template basati su HTML ai quali aggiunge una sintassi specifica.

Le direttive iniziano normalmente con v-.

Per esempio:

<p v-if="utenteAutenticato">
  Bentornato!
</p>

v-if controlla se il nodo debba essere renderizzato.

Per una lista puoi utilizzare:

<li v-for="prodotto in prodotti" :key="prodotto.id">
  {{ prodotto.nome }}
</li>

Per collegare dinamicamente un attributo:

<a :href="url">Visita la pagina</a>

La forma:

:href

è l’abbreviazione di:

v-bind:href

Per gli eventi:

<button @click="salva">
  Salva
</button>

@click è invece una forma abbreviata di v-on:click.

Un’altra direttiva molto conosciuta è v-model, utile per collegare determinati input a uno stato:

<input v-model="nome">

Il valore dell’input e lo stato vengono così coordinati attraverso il modello fornito dal framework.

L’obiettivo non è imparare a memoria la lista delle direttive. È capire che il template Vue permette di esprimere relazioni fra dati, condizioni, eventi e struttura dell’interfaccia.

Componenti: suddividere l’interfaccia per responsabilità

Le applicazioni Vue vengono normalmente costruite attraverso componenti.

Un componente può rappresentare una piccola unità dell’interfaccia, per esempio:

• un pulsante;
• una card prodotto;
• un campo di ricerca;
• una finestra modale.

Oppure una parte molto più grande:

• una navbar;
• un checkout;
• un pannello amministrativo;
• un’intera vista dell’applicazione.

Il vantaggio non consiste semplicemente nel “dividere tutto in file piccoli”.

Un buon componente possiede normalmente una responsabilità riconoscibile, riceve dati attraverso un’interfaccia comprensibile e comunica con gli altri componenti in modo prevedibile.

Spezzare qualsiasi elemento in un componente autonomo non rende automaticamente il progetto più modulare. Può perfino rendere più difficile seguirne il flusso.

Props ed eventi: come comunicano i componenti

Le props consentono a un componente padre di passare informazioni a un figlio.

Per esempio:

<!-- ProdottoCard.vue -->
<script setup>
defineProps({
  nome: String,
  prezzo: Number
})
</script>

<template>
  <article>
    <h3>{{ nome }}</h3>
    <p>{{ prezzo }} €</p>
  </article>
</template>

Il componente può poi essere utilizzato così:

<ProdottoCard
  nome="Tastiera"
  :prezzo="79"
/>

Il flusso inverso può essere gestito attraverso eventi emessi dal componente.

Questa separazione è utile perché evita che ogni parte dell’interfaccia acceda arbitrariamente a qualsiasi dato.

Quando il progetto cresce, capire da dove arriva un valore, chi può modificarlo e quali componenti ne dipendono diventa più importante della quantità di componenti presenti.

Virtual DOM: utile, ma non è una garanzia automatica di velocità

Vue utilizza un Virtual DOM nel proprio modello di rendering.

Il termine descrive una rappresentazione dell’interfaccia che il framework utilizza per determinare come aggiornare il DOM reale.

È però sbagliato trasformarlo nella formula:

Virtual DOM = applicazione sempre più veloce

La performance reale dipende anche da:

• quantità di JavaScript caricata;
• dimensione e frequenza degli aggiornamenti;
• struttura dei componenti;
• codice eseguito sul main thread;
• dipendenze;
• richieste di rete;
• immagini e font;
• strategia di rendering;
• caching;
• caratteristiche dei dispositivi degli utenti.

Vue utilizza inoltre informazioni ottenute durante la compilazione dei template per ottimizzare il rendering. È quindi più utile comprendere il Virtual DOM come parte del meccanismo di aggiornamento, non come un benchmark di performance incorporato nel nome del framework.

Un esempio Vue.js per capire davvero il modello

Consideriamo un componente leggermente più utile di un semplice “Hello World”.

<script setup>
import { computed, ref } from 'vue'

const prezzo = ref(25)
const quantita = ref(1)

const totale = computed(() => prezzo.value * quantita.value)
</script>

<template>
  <section>
    <h2>Ordine</h2>

    <label>
      Quantità
      <input
        v-model.number="quantita"
        type="number"
        min="1"
      >
    </label>

    <p>Prezzo unitario: {{ prezzo }} €</p>
    <p>Totale: {{ totale }} €</p>
  </section>
</template>

Qui entrano in gioco tre concetti differenti.

prezzo e quantita sono stato reattivo.

const prezzo = ref(25)
const quantita = ref(1)

totale non è invece un altro stato che dobbiamo ricordarci di aggiornare manualmente. È un valore derivato:

const totale = computed(() => prezzo.value * quantita.value)

Quando cambia quantita, Vue sa che totale ne dipende e può ricalcolarlo.

Nel template:

<input v-model.number="quantita">

colleghiamo l’input alla quantità.

Il flusso diventa:

input utente → cambia quantita → cambia totale → Vue aggiorna l’interfaccia

Questo modello è molto più interessante della sintassi in sé.

Potresti naturalmente ottenere lo stesso risultato con JavaScript senza Vue. La questione non è quindi se Vue renda possibile una funzionalità che JavaScript non potrebbe realizzare.

La domanda è:

quando stato, dipendenze e interazioni aumentano, il modello fornito da Vue riduce abbastanza la complessità da giustificare il framework?

È questo il criterio che dovrebbe guidare la scelta.

Come iniziare un progetto Vue.js

Per un nuovo progetto strutturato non partirei da vecchi tutorial basati su Vue CLI.

Il percorso corrente raccomandato dalla documentazione utilizza create-vue e Vite.

Cosa conviene conoscere prima di Vue

Prima di studiare seriamente Vue conviene avere almeno familiarità con:

• HTML e struttura dei documenti;
• CSS e layout;
• JavaScript moderno;
• funzioni, oggetti e array;
• moduli import ed export;
• eventi;
• Promise e async/await;
• DOM;
• richieste HTTP di base.

Non serve conoscere ogni API del browser.

Serve però una base sufficiente per riconoscere se un comportamento appartiene:

• a JavaScript;
• al browser;
• a Vue;
• alla toolchain.

Senza questa distinzione il debugging diventa una ricerca casuale di soluzioni.

Creare un progetto con create-vue e Vite

La Quick Start ufficiale utilizza create-vue, lo scaffolding tool ufficiale.

Con Node.js installato puoi eseguire:

npm create vue@latest

Il wizard permette di configurare diverse opzioni, fra cui TypeScript, routing e strumenti di testing.

Al termine:

cd nome-progetto
npm install
npm run dev

Vite gestisce l’ambiente di sviluppo e il processo di build.

È importante non confondere però le responsabilità.

Node.js viene utilizzato qui per eseguire strumenti di sviluppo e package manager sul computer. Questo non significa che una normale applicazione Vue debba necessariamente utilizzare Node.js come backend.

Il codice Vue destinato al client verrà eseguito nel browser. Il backend può essere costruito con Node.js oppure con PHP, Python, Java, .NET, Go o qualsiasi altro stack capace di comunicare con il front-end.

Perché non inizierei più un nuovo progetto con Vue CLI

Vue CLI ha avuto un ruolo centrale nell’ecosistema Vue e molti tutorial continuano legittimamente a mostrarlo per progetti esistenti.

Per un nuovo progetto, però, la documentazione sul tooling Vue indica Vite come percorso raccomandato e Vue CLI è in maintenance mode.

Questo è uno dei segnali più semplici per riconoscere una guida da contestualizzare.

Se trovi:

vue create mia-app

non significa che tutto il tutorial sia sbagliato.

Significa che la parte relativa alla toolchain non rappresenta più il punto di partenza consigliato per un nuovo progetto.

Single File Components: perché i file .vue sono centrali

Nei progetti Vue strutturati incontrerai normalmente i Single File Components, abbreviati in SFC.

Un file può avere una struttura come questa:

<script setup>
import { ref } from 'vue'

const aperto = ref(false)
</script>

<template>
  <button @click="aperto = !aperto">
    Menu
  </button>

  <nav v-if="aperto">
    <!-- link -->
  </nav>
</template>

<style scoped>
button {
  font-weight: 600;
}
</style>

Tre livelli rimangono riconoscibili:

• <script> contiene la logica;
• <template> descrive il markup;
• <style> gestisce gli stili.

Non significa che Vue abbia “fuso HTML, CSS e JavaScript in un nuovo linguaggio”.

Gli SFC rappresentano piuttosto un formato di componente che la toolchain compila in risorse utilizzabili dal browser.

Per SPA, SSG e front-end non banali, la documentazione sui Single File Components considera gli SFC l’approccio raccomandato.

Composition API e Options API: quale usare

Vue permette di scrivere componenti attraverso due principali stili API:

• Options API;
• Composition API.

Entrambi appartengono a Vue 3 e sono supportati.

Non è quindi corretto descrivere semplicemente Options API come “vecchia” e Composition API come “nuova” nel senso di API deprecata e sostitutiva.

Come funziona Options API

Con Options API la logica viene organizzata in sezioni come:

export default {
  data() {
    return {
      conteggio: 0
    }
  },

  computed: {
    doppio() {
      return this.conteggio * 2
    }
  },

  methods: {
    incrementa() {
      this.conteggio++
    }
  }
}

La struttura è immediatamente leggibile perché raggruppa il codice per tipo di opzione:

• dati;
• computed properties;
• metodi;
• lifecycle hook.

Per componenti piccoli o per chi sta imparando il modello, questo può essere molto intuitivo.

Come funziona Composition API

Con Composition API la logica viene costruita importando direttamente le API necessarie:

<script setup>
import { computed, ref } from 'vue'

const conteggio = ref(0)
const doppio = computed(() => conteggio.value * 2)

function incrementa() {
  conteggio.value++
}
</script>

La differenza più interessante emerge quando il componente cresce.

Invece di organizzare necessariamente il codice per categoria — dati da una parte, metodi dall’altra, computed altrove — puoi avvicinare le parti che appartengono allo stesso comportamento.

Questo facilita anche l’estrazione della logica riutilizzabile nei cosiddetti composable.

Quale sceglierei

Per imparare Vue puoi comprendere entrambi gli stili.

Per un progetto moderno basato su SFC, soprattutto se prevedi:

• logica articolata;
• riuso attraverso composable;
• forte utilizzo di TypeScript;
• componenti complessi;

tenderei a utilizzare Composition API con <script setup>.

La documentazione stessa raccomanda <script setup> quando Composition API e SFC vengono usati insieme.

Options API resta però perfettamente valida. Se rende il componente più comprensibile al team e il progetto non trae beneficio dalla diversa organizzazione della Composition API, non esiste un premio per convertirlo soltanto per seguire una moda.

Vue.js e TypeScript

Vue possiede supporto TypeScript di prima classe e gli strumenti ufficiali permettono di creare direttamente un progetto configurato per utilizzarlo.

Questo non significa che Vue richieda TypeScript.

Per imparare i concetti fondamentali puoi lavorare tranquillamente con JavaScript.

Quando però il progetto cresce, TypeScript può diventare particolarmente utile per descrivere:

• props;
• eventi;
• oggetti ricevuti dalle API;
• stato;
• parametri di funzioni;
• valori restituiti;
• contratti condivisi fra componenti.

Per esempio:

<script setup lang="ts">
interface Prodotto {
  id: number
  nome: string
  prezzo: number
}

defineProps<{
  prodotto: Prodotto
}>()
</script>

Il componente dichiara esplicitamente quale forma deve avere prodotto.

L’editor può quindi individuare più errori prima dell’esecuzione e offrire autocompletamento più preciso.

La documentazione Vue dedicata a TypeScript evidenzia proprio il valore dell’analisi statica e del supporto ai refactoring nelle applicazioni più grandi.

Il criterio rimane comunque quello del costo-beneficio. In un piccolo esperimento didattico, introdurre immediatamente ogni livello possibile di tipizzazione può distogliere l’attenzione dal modello di Vue. In una codebase mantenuta da un team, i contratti espliciti diventano molto più preziosi.

L’ecosistema Vue: Router, Pinia e framework SSR

Vue non deve necessariamente essere utilizzato insieme a tutte le librerie del suo ecosistema.

Un piccolo componente inserito in una pagina potrebbe non richiedere né router né store globale.

Quando invece costruisci un’applicazione più articolata emergono problemi che vanno risolti in modo strutturato.

Vue Router per la navigazione

In una Single Page Application più viste possono corrispondere a URL differenti senza caricare necessariamente un nuovo documento completo a ogni navigazione.

È qui che entra in gioco Vue Router.

Può gestire:

• rotte;
• parametri dinamici;
• viste annidate;
• navigazione;
• history del browser;
• guardie di navigazione.

La presenza di Vue Router non trasforma però automaticamente un progetto in una buona SPA.

La progettazione degli URL, il comportamento del server, la gestione degli errori e l’accessibilità della navigazione restano responsabilità reali.

Pinia per lo stato condiviso

Non tutto lo stato deve essere globale.

Se l’apertura di un accordion riguarda soltanto un componente, spostarla in uno store centrale significa probabilmente complicare una cosa semplice.

Quando invece dati e operazioni devono essere condivisi fra parti distanti dell’applicazione può avere senso utilizzare uno store.

La documentazione Vue sullo state management raccomanda Pinia per le nuove applicazioni che richiedono una soluzione di stato su scala più ampia.

Vuex, che troverai in numerosissimi corsi e tutorial storici, continua a funzionare ma è in maintenance mode.

Il cambiamento è importante:

nuovo progetto che necessita di store globale → valuta Pinia

non:

sto usando Vue → devo installare automaticamente Pinia

Un’applicazione piccola può gestire perfettamente lo stato senza uno store globale.

Vite non è Vue

Vite e Vue vengono spesso incontrati contemporaneamente e possono quindi sembrare parti della stessa tecnologia.

Non lo sono.

Vue fornisce il modello per costruire l’interfaccia.

Vite si occupa invece della toolchain di sviluppo e build.

Questa distinzione diventa evidente perché Vite può essere utilizzato anche con altre tecnologie.

Capirla aiuta molto nel debugging: un errore della configurazione di build non è necessariamente un errore del framework Vue.

Quando basta Vue + Vite e quando valutare Nuxt

Per un’applicazione client-side che non richiede un framework applicativo superiore, Vue con Vite può essere una configurazione molto lineare.

Quando invece hai bisogno di Server-Side Rendering, routing integrato nel framework, strategie ibride di rendering o altre capacità applicative, può avere senso valutare un framework costruito sopra Vue.

Nuxt è l’esempio più conosciuto.

La guida ufficiale Vue sul Server-Side Rendering sottolinea che configurare manualmente un’applicazione SSR pronta per la produzione richiede di coordinare numerosi aspetti. Per questo, quando l’SSR è realmente necessario, la raccomandazione generale è usare una soluzione di livello superiore.

Il criterio è importante:

non scegliere Nuxt soltanto perché è “più completo”. Sceglilo quando risolve problemi che il progetto possiede realmente.

Ogni livello aggiuntivo porta anche convenzioni, dipendenze e complessità da mantenere.

A cosa serve Vue.js nella pratica

Vue è particolarmente adatto alle interfacce in cui ciò che appare cambia frequentemente in funzione di dati, stato e interazioni.

Non esiste però una lista chiusa di “siti che devono usare Vue”.

Conta il tipo di problema.

Aggiungere interattività a una pagina esistente

Uno degli aspetti più interessanti di Vue è la possibilità di introdurlo gradualmente.

Immagina un’applicazione server-rendered nella quale soltanto un configuratore prodotto richiede una UI complessa.

Non sei necessariamente obbligato a trasformare tutto il sito in una SPA.

Potresti utilizzare Vue soltanto per quella porzione interattiva.

Questo può ridurre il costo di migrazione e permette di valutare il framework su una parte del prodotto in cui produce un vantaggio concreto.

Single Page Application

Vue può naturalmente essere utilizzato per costruire SPA.

È un caso d’uso comune quando l’applicazione presenta numerose interazioni client-side e deve gestire viste, stato e aggiornamenti senza richiedere un documento HTML completamente nuovo a ogni azione.

Esempi plausibili includono:

• dashboard;
• CRM;
• pannelli amministrativi;
• aree riservate;
• strumenti SaaS;
• editor;
• configuratori;
• applicazioni gestionali;
• interfacce di ricerca complesse.

La parola SPA non deve però diventare un requisito.

Se una normale architettura multipagina risolve meglio il problema, costruire una SPA soltanto perché stai usando Vue significa lasciare che lo strumento decida l’architettura al posto dei requisiti.

Applicazioni che consumano API

Molte applicazioni Vue mostrano dati ottenuti da un backend.

Il percorso può essere:

database → backend → API → browser → stato Vue → interfaccia

Vue non stabilisce come debba essere costruita l’API.

Il front-end può consumare API sviluppate con qualsiasi tecnologia capace di esporre un’interfaccia HTTP compatibile.

Nel mondo PHP, Laravel è un esempio particolarmente pertinente: può esporre il backend e le API consumate da Vue, oppure entrare in uno stack più integrato quando non vuoi separare completamente client e server.

Il framework gestisce il livello client; autenticazione, autorizzazione, validazione dei dati e logica di business sensibile devono continuare a essere progettate correttamente sul server.

Dashboard e applicazioni con molto stato visuale

Pensa a una dashboard nella quale puoi:

• cambiare filtri;
• ordinare tabelle;
• aprire pannelli;
• modificare intervalli temporali;
• caricare dati;
• cambiare vista;
• selezionare elementi;
• aggiornare form.

Il problema non è creare singolarmente ciascuna interazione.

Il problema è mantenere comprensibile il rapporto fra tutte queste informazioni.

È in scenari simili che un modello basato su componenti e stato reattivo può produrre un vantaggio netto rispetto a una lunga sequenza di manipolazioni manuali del DOM.

Vue.js e SEO: una SPA non è automaticamente un problema, ma il rendering conta

La domanda “Vue è SEO friendly?” è troppo generica.

Vue non decide da solo come il contenuto viene consegnato al crawler e all’utente. È l’architettura di rendering a fare una parte importante della differenza.

Una pagina Vue può utilizzare:

• client-side rendering;
• server-side rendering;
• generazione statica;
• combinazioni di strategie differenti.

Google è in grado di eseguire JavaScript. La documentazione Google sulla SEO per JavaScript distingue però chiaramente scansione, rendering e indicizzazione e continua a indicare server-side rendering o pre-rendering come soluzioni valide.

Questo significa che non dobbiamo usare lo slogan:

JavaScript = Google non vede il contenuto

ma nemmeno l’opposto:

Google esegue JavaScript = architettura indifferente

Se il contenuto importante arriva soltanto dopo molto lavoro client-side devi considerare:

• time-to-content;
• quantità di JavaScript;
• errori durante il rendering;
• gestione degli status HTTP;
• link crawlable;
• metadata;
• canonical;
• prestazioni;
• esperienza degli altri crawler e sistemi che non eseguono JavaScript allo stesso modo.

La stessa documentazione Vue sulle performance suggerisce di non utilizzare automaticamente una SPA puramente client-side quando il caricamento iniziale dei contenuti è particolarmente importante.

Per pagine editoriali, landing e contenuti destinati alla ricerca, SSR o SSG possono quindi essere molto interessanti.

La decisione deve nascere dal prodotto, non da una formula “Vue sì/no per la SEO”.

Vantaggi di Vue.js

Vue ha diversi punti di forza, ma conviene collegarli a problemi concreti anziché trasformarli in slogan.

Caratteristica	Vantaggio reale	Dove conta	Limite da ricordare
Adozione incrementale	Puoi introdurlo senza riscrivere necessariamente tutto	Progetti esistenti e progressive enhancement	Aggiungere un framework per una micro-interazione può comunque essere eccessivo
Reattività	Riduce la sincronizzazione manuale fra stato e UI	Interfacce dinamiche	Stato progettato male rimane stato progettato male
Componenti	Favoriscono confini, composizione e riuso	Applicazioni che crescono	Componentizzazione eccessiva aumenta l’indirezione
Template	Mantengono una sintassi vicina a HTML	Team provenienti dallo sviluppo web classico	Va comunque imparata la sintassi specifica Vue
SFC	Riuniscono struttura, logica e stile del componente	Front-end modulari	Richiedono una toolchain
Ecosistema ufficiale	Router e Pinia coprono problemi comuni	Applicazioni strutturate	Non vanno installati automaticamente
TypeScript	Supporto di prima classe	Codebase grandi e team	La tipizzazione aggiunge complessità iniziale
Vite	Setup moderno e sviluppo rapido	Nuovi progetti	Vite è tooling, non sostituisce una buona architettura

Un modello relativamente accessibile

Per chi conosce già HTML, CSS e JavaScript, i template Vue possono risultare familiari.

Un elemento come:

<button @click="salva">
  Salva
</button>

mantiene visivamente riconoscibile la struttura del markup.

Non significa che Vue non abbia una curva di apprendimento. Appena entrano in gioco reattività avanzata, lifecycle, composable, routing, stato globale, testing e SSR, la profondità aumenta rapidamente.

Il vantaggio è piuttosto un punto di ingresso relativamente graduale.

Ecosistema coeso

Vue fornisce un core chiaramente definito e possiede soluzioni ufficiali per diversi problemi frequenti.

Questo riduce parte della frammentazione decisionale che puoi incontrare in ecosistemi in cui il nucleo lascia volutamente più scelte all’applicazione.

Non elimina comunque le decisioni architetturali.

Database, API, autenticazione, data fetching, caching, deployment e struttura complessiva restano problemi del progetto.

La flessibilità dell’adozione

Puoi utilizzare Vue in un progetto esistente oppure costruire un’applicazione completa.

Questo rende il framework interessante anche quando una migrazione totale sarebbe troppo costosa.

In pratica puoi testare il valore del modello su un’area specifica prima di estenderlo.

Limiti di Vue.js e quando non conviene usarlo

Un framework non dovrebbe essere giudicato soltanto da ciò che permette di fare.

Bisogna valutare anche la complessità che introduce.

Una pagina semplice può non avere bisogno di Vue

Immagina un sito prevalentemente statico con:

• menu mobile;
• accordion FAQ;
• un paio di modali;
• form relativamente semplice.

Puoi costruire tutto con Vue.

Ma “si può fare” non significa “è la scelta migliore”.

Aggiungere un framework può significare introdurre:

• dipendenze;
• package manager;
• build;
• bundle JavaScript;
• aggiornamenti;
• convenzioni;
• nuove competenze nel team.

Per interazioni isolate, JavaScript nativo può essere sufficiente.

La domanda corretta è quindi:

Vue elimina più complessità di quella che aggiunge?

Se la risposta è no, non utilizzarlo soltanto perché è una tecnologia piacevole.

La flessibilità richiede comunque decisioni

Vue è più opinionato di una semplice libreria UI, ma non decide ogni parte dell’architettura.

Devi comunque scegliere come gestire:

• chiamate ai servizi;
• errori;
• autenticazione;
• cache;
• stato locale e globale;
• struttura dei componenti;
• test;
• strategie di rendering;
• deployment.

Un team può quindi costruire una codebase Vue eccellente oppure una codebase difficile da mantenere.

Il framework riduce alcune classi di problema; non sostituisce la progettazione.

La disponibilità di competenze conta

Una tecnologia tecnicamente adatta può diventare una scelta debole se nessuno nel team sa mantenerla e non esiste un motivo sufficiente per introdurla.

Nella scelta reale valuterei anche:

• competenze esistenti;
• facilità di recruiting nel mercato di riferimento;
• maturità della codebase;
• librerie già adottate;
• durata prevista del prodotto;
• necessità di integrazione con sistemi legacy.

Il confronto fra framework non dovrebbe quindi ridursi alla sintassi che preferisce un singolo sviluppatore.

Vue.js vs React vs Angular: cosa cambia

Vue, React e Angular vengono spesso messi nella stessa classifica.

È utile confrontarli, ma bisogna farlo sapendo che non hanno esattamente lo stesso livello di astrazione.

React si presenta come libreria per costruire interfacce utente.

Vue è un framework progressivo con un ecosistema ufficiale particolarmente coeso.

Angular è un framework applicativo più strutturato e opinionated.

Criterio	Vue	React	Angular
Posizionamento	Framework progressivo	Libreria UI	Framework applicativo
UI	Componenti + template	Componenti + JSX	Componenti + template
Adozione incrementale	Molto naturale	Possibile	Normalmente più strutturata
Tooling iniziale	create-vue + Vite	Dipende dall’architettura scelta	Tooling Angular integrato
Stato globale	Pinia quando necessario	Soluzioni differenti in base al progetto	Strumenti/pattern dell’ecosistema Angular
TypeScript	Supporto di prima classe, opzionale	Molto comune ma opzionale	Centrale nell’esperienza Angular
Grado di convenzione	Medio	Più aperto	Alto
Curva iniziale	Generalmente graduale	Core accessibile, ecosistema più aperto	Maggiore superficie concettuale
Fit tipico	UI progressive, SPA, applicazioni medio-complesse	Ampio spettro di UI e applicazioni	Applicazioni strutturate e team che vogliono molte convenzioni

Questa tabella non produce un vincitore assoluto.

Serve a capire che tipo di decisioni vuoi che la tecnologia prenda al posto tuo.

Vue vs React

La differenza più evidente è nel modo in cui viene descritta l’interfaccia.

Vue usa normalmente template:

<button @click="incrementa">
  {{ conteggio }}
</button>

React usa comunemente JSX:

<button onClick={incrementa}>
  {conteggio}
</button>

Entrambe le tecnologie sono component-based e dichiarative, ma organizzano l’esperienza di sviluppo in modo differente.

Vue offre inoltre un insieme molto riconoscibile di soluzioni ufficiali come Router e Pinia.

React mantiene il nucleo maggiormente focalizzato sulla UI e lascia più spazio alla scelta degli strumenti che compongono l’applicazione.

Sceglierei Vue rispetto a React quando apprezzo:

• template molto vicini al modello HTML;
• un ecosistema ufficiale più coeso;
• adozione incrementale particolarmente naturale;
• convenzioni sufficienti senza arrivare alla struttura di Angular.

Sceglierei React quando il suo ecosistema, le competenze del team o il framework applicativo che voglio adottare risultano più adatti al progetto.

“Quale sintassi mi piace di più?” è un criterio legittimo per un progetto personale. In un prodotto destinato a durare, non dovrebbe essere l’unico.

Vue vs Angular

Angular offre una superficie applicativa molto più strutturata.

Questa caratteristica può sembrare inizialmente un costo perché ci sono più concetti e convenzioni da apprendere.

In una grande codebase, però, un livello maggiore di standardizzazione può diventare un vantaggio: riduce il numero di decisioni lasciate ai singoli team.

Vue è generalmente più graduale.

Puoi utilizzarne poco, molto o costruire progressivamente un’applicazione completa.

Angular tende invece a entrare nel progetto come piattaforma più organica.

Sceglierei fra i due chiedendomi soprattutto:

• quanto vogliamo che l’architettura sia prescritta dal framework?
• quanto deve essere facile inserire la tecnologia in un sistema esistente?
• che competenze possiede già il team?
• quali standard interni dobbiamo mantenere?
• quale ecosistema si integra meglio con il resto della piattaforma?

Quale sceglierei in base allo scenario

Per aggiungere una UI reattiva a un sistema esistente, Vue è particolarmente interessante grazie alla sua adozione incrementale.

Per una SPA o applicazione front-end di dimensioni medio-grandi, Vue e React sono entrambe scelte credibili: deciderei soprattutto in base a team, ecosistema, convenzioni e architettura complessiva.

Per un ambiente enterprise che vuole molte convenzioni integrate e una piattaforma fortemente strutturata, Angular può risultare più coerente.

Per un sito prevalentemente statico con interattività minima, prima di scegliere uno dei tre mi chiederei se serva realmente un framework JavaScript client-side.

Questa quarta opzione viene spesso dimenticata nei confronti.

Cosa studiare prima e dopo Vue.js

Vue è uno strumento all’interno di un percorso più ampio.

Imparare soltanto l’API del framework può permetterti di completare un tutorial, ma non rende automaticamente solida la comprensione dello sviluppo front-end.

Prima di Vue: HTML, CSS, JavaScript e DOM

Un percorso sensato è:

HTML → CSS → JavaScript → DOM e browser → Vue

Non devi aspettare di “sapere tutto” prima di creare il primo componente.

Dovresti però saper distinguere almeno:

• markup HTML;
• regole CSS;
• sintassi JavaScript;
• eventi del browser;
• DOM;
• Promise;
• richieste di rete;
• moduli.

Se ogni errore viene percepito come “un errore Vue”, diventa molto difficile diagnosticare il problema reale.

Dopo le basi: TypeScript, API e testing

Una volta compresi componenti, props, eventi, stato e reattività puoi approfondire:

• TypeScript;
• Vue Router;
• Pinia;
• composable;
• chiamate API;
• gestione degli errori;
• autenticazione;
• testing;
• performance;
• accessibilità;
• SSR e SSG quando necessari.

Evita la tentazione di installare immediatamente tutto.

Il modo più efficace di capire perché serve uno strumento è incontrare prima il problema che risolve.

Vue nel percorso di un web developer

Se il tuo obiettivo è diventare web developer, Vue dovrebbe arrivare dopo le fondamenta della piattaforma web, non sostituirle.

Un framework cambia.

La capacità di capire:

• HTTP;
• DOM;
• JavaScript;
• dati;
• stato;
• errori;
• rete;
• accessibilità;
• performance;

rimane trasferibile anche quando cambi stack.

Vue può diventare una specializzazione front-end molto concreta, ma è molto più utile se sai spiegare cosa accade sotto l’astrazione.

Vue in un percorso full stack

In un percorso da full stack developer Vue può occuparsi del livello front-end, mentre il server utilizza uno stack indipendente.

Con JavaScript end-to-end una combinazione possibile è:

Vue → API → Node.js → database

ma non è “lo stack Vue”.

Potresti avere:

Vue → API PHP → database

oppure:

Vue → API Python → database

oppure qualsiasi altra combinazione coerente.

La competenza full stack consiste nel comprendere come i livelli comunicano, non nell’accumulare loghi di tecnologie.

Vue.js è difficile da imparare?

Le basi di Vue sono relativamente accessibili se conosci già HTML, CSS e JavaScript.

Creare un componente, usare una direttiva e gestire uno stato semplice richiede poco codice.

La difficoltà aumenta quando passi dal tutorial alla progettazione di applicazioni reali.

A quel punto devi prendere decisioni su:

• confini dei componenti;
• stato locale e globale;
• composable;
• routing;
• richieste asincrone;
• gestione degli errori;
• cache;
• autenticazione;
• performance;
• testing;
• accessibilità;
• deployment.

È una dinamica comune a quasi tutti i framework.

La sintassi iniziale può essere semplice; costruire software mantenibile rimane un problema di ingegneria.

Per questo eviterei di valutare Vue soltanto in base a quanto rapidamente riesci a creare il primo contatore.

Un framework va giudicato anche dopo che il progetto è cresciuto e deve essere compreso da altre persone.

Quando sceglierei Vue.js e quando no

Sceglierei Vue quando devo gestire un’interfaccia abbastanza dinamica da beneficiare realmente di:

• stato reattivo;
• componenti;
• rendering dichiarativo;
• riuso;
• struttura;
• ecosistema front-end coerente.

Lo prenderei particolarmente in considerazione se voglio introdurre gradualmente un framework in un sistema già esistente oppure se il team apprezza il modello dei template e le convenzioni dell’ecosistema Vue.

Non lo sceglierei automaticamente per una pagina semplice soltanto perché “è moderno”.

E non lo sceglierei soltanto perché un confronto online assegna a Vue qualche punto in più di React o Angular.

Le tecnologie cambiano. Le domande da fare restano abbastanza stabili:

1. quale complessità dobbiamo gestire?
2. quale complessità aggiunge il framework?
3. il team sa mantenerlo?
4. l’ecosistema copre i requisiti del progetto?
5. come dovremo renderizzare e distribuire l’applicazione?
6. quanto sarà costoso cambiare decisione in futuro?

Se Vue rende queste risposte più semplici, è probabilmente una buona scelta.

Se aggiunge un nuovo livello senza risolvere un problema reale, una soluzione più piccola può essere migliore.

Conclusione

Vue.js offre un equilibrio interessante fra accessibilità iniziale, struttura e possibilità di crescita.

Puoi utilizzarlo per aggiungere una piccola area reattiva a un progetto esistente oppure costruire applicazioni a componenti con routing, stato condiviso, TypeScript e strategie di rendering più sofisticate.

Il punto decisivo, però, non è quanti strumenti puoi aggiungere allo stack.

Per iniziare bene bastano fondamenta solide, Vue, la toolchain necessaria e un problema abbastanza concreto da giustificare il framework. Router, Pinia, SSR e framework superiori dovrebbero arrivare quando il progetto li richiede, non perché compaiono in una checklist.

Se devi imparare Vue, partirei quindi da JavaScript e DOM, poi costruirei alcuni componenti reali con Composition API e <script setup>. Solo dopo introdurrei routing, stato globale e TypeScript dove rendono il codice realmente più comprensibile.

Se invece devi scegliere Vue per un progetto professionale, la domanda finale è ancora più semplice: il modello di Vue riduce il costo di costruire e mantenere questa interfaccia rispetto alle alternative?

È lì che un framework smette di essere una tecnologia interessante e diventa una scelta architetturale sensata.