
Vue contro Svelte: entrambi usano un compilatore, e questo cambia il confronto
- vuetelemetry
- Stack
- 6 min di lettura
L'impostazione abituale contrappone il compilatore di Svelte al virtual DOM di Vue. La documentazione di Vue chiama però il proprio approccio Compiler-Informed Virtual DOM. Cosa fa davvero ciascun compilatore, e cosa decide realmente la scelta.
Vue e Svelte vengono quasi sempre presentati attraverso una sola contrapposizione: Svelte compila, Vue usa un virtual DOM. È una sintesi comoda ed è fuorviante, perché entrambi i framework si appoggiano fortemente a un compilatore. Ciò che cambia è quello che produce ciascun compilatore e quello che resta da fare a runtime.
Svelte si descrive come un framework che usa un compilatore per trasformare componenti dichiarativi scritti in HTML, CSS e JavaScript in JavaScript essenziale e fortemente ottimizzato. Il passaggio di build è il centro del progetto: il lavoro di capire cosa deve cambiare viene spinto il più possibile dentro la compilazione.
Anche Vue compila, e lo dice esplicitamente. La sua documentazione afferma che il framework controlla sia il compilatore sia il runtime, il che gli permette di implementare ottimizzazioni in fase di compilazione che solo un renderer fortemente accoppiato può sfruttare. Vue chiama questo approccio ibrido Compiler-Informed Virtual DOM. Il virtual DOM c'è ancora, ma il compilatore dice al runtime dove non ha bisogno di guardare.
Tre di queste ottimizzazioni vale la pena conoscerle per nome, perché spiegano perché confrontare 'virtual DOM' e 'nessun virtual DOM' manca il punto. Static hoisting: il renderer crea i vnode delle parti immutabili durante il render iniziale, li mette in cache e riutilizza gli stessi vnode a ogni re-render successivo. Non viene ri-diffato nulla che non possa cambiare.
Patch flags: Vue codifica il tipo di aggiornamento direttamente alla creazione del vnode, così il runtime usa operazioni bitwise per decidere se deve svolgere un determinato lavoro. Non pone domande ampie sull'albero, controlla un flag.
Tree flattening: ogni blocco tiene traccia dei nodi discendenti che portano patch flags, non solo dei figli diretti. Quando il componente si ri-renderizza, il runtime attraversa l'albero appiattito anziché quello completo, il che secondo la documentazione riduce fortemente il numero di nodi attraversati durante la reconciliation.
Lette insieme, queste tre significano che il virtual DOM di Vue non è il diff ingenuo che il confronto abbreviato lascia intendere. Il compilatore ha già ristretto lo spazio di ricerca prima che il runtime inizi a cercare. È un progetto diverso da quello di Svelte, ma non è l'assenza di un compilatore.
Allora dove sta la scelta vera? Meno nella teoria pura del rendering che in ciò che le sta attorno. Vue arriva con più decisioni già prese, con librerie ufficiali di routing e di stato e una struttura consigliata, il che tende ad accorciare il percorso verso la produttività nei team piccoli. Il progetto di Svelte insiste di più sul fatto che il passaggio di build produca un output minimo, cosa che attira quando la dimensione del payload e il lavoro all'avvio sono i vincoli che senti davvero.
La maturità dell'ecosistema è l'altro fattore onesto. Vue è diffuso su larga scala da più tempo, e questo si vede nel volume di librerie, strumenti e profili disponibili sul mercato del lavoro. L'ecosistema di Svelte è più piccolo, cosa che pesa di più su un'applicazione grande e di lunga vita che su una mirata.
Il consiglio pratico non è affascinante: nessuna delle due scelte sarà ciò che rende la tua interfaccia veloce o lenta. La struttura dei componenti, il recupero dei dati, la gestione delle immagini e quanto JavaScript spedisci domineranno. Scegli quello che il tuo team sarà a suo agio a mantenere, e investi la discussione risparmiata nel misurare ciò che si carica davvero.


