Perché userei Three.js e Pixi.js

Una pagina nel browser è un documento: titoli, bottoni, form, link che un crawler legge. CSS, GSAP e Framer Motion muovono quel documento. È lo strumento giusto per quasi ogni sito marketing che consegno. Three.js e Pixi.js esistono per l’altro mestiere: una scena che dipinge la GPU, non un albero di div. I team li prendono quando il DOM perde frame, quando l’oggetto è uno SKU 3D, o quando duemila monete devono restare a schermo a 60 fps.

Ho già scritto quando GSAP e Framer Motion valgono il loro posto in un handoff da Figma al codice. Questo non è quell’articolo. Qui: quando lascerei il DOM, a cosa serve davvero ogni libreria, e il conto in Core Web Vitals, SEO e accessibilità se mettete un canvas WebGL su un URL business.

1. Il DOM è un documento. Un canvas è una superficie di disegno

Ogni nodo del DOM porta layout, stile, hit-testing e un posto nell’albero di accessibilità. Quel costo è il senso del web: il testo si seleziona, il form si tabba, Google indicizza il titolo. Ed è anche perché mille div in position absolute scattano su un telefono di fascia media. Un canvas è un bitmap. Dite alla GPU cosa disegnare in questo frame. Uno sprite non ha layout. Non ha nemmeno un titolo per il crawler né un nome per lo screen reader, se non lo costruite accanto al canvas.

Il WebGL crudo (e ora WebGPU) sono camere, buffer, shader e draw call. Si può scrivere. La maggior parte dei team di prodotto non dovrebbe. Three.js e Pixi.js avvolgono quella superficie in un grafo di scena, loader e un bacino di hiring. Pagate con il peso del bundle e una black box in mezzo alla pagina. La domanda non è mai «quanto è figo il render GPU». È se il prodotto ha davvero bisogno di una scena.

2. Three.js: un mondo 3D nella scheda

Three.js è un motore 3D per il browser. Avete scena, camera, luci, mesh, materiali e texture. La libreria parla con WebGL; esiste un renderer WebGPU per le GPU più nuove. Si usa perché un modello GLTF di un divano, una cucina o una turbina costa meno da far girare nella scheda che filmare ogni angolo, e perché una camera che si può orbitare vende meglio di un carousel di PNG.

Il lavoro tipico che vedo: configuratori di prodotto (colore, tessuto, extra), walkthrough di architettura, dati scientifici o finanziari nello spazio, stand WebXR, scene hero su un sito di brand che devono sembrare un fotogramma che si può toccare. Babylon.js è un’alternativa vera, con un editor più forte. Three.js ha vinto gli esempi, le risposte su Stack Overflow e React Three Fiber - così aggancierei una scena in un’app Next.js che già pensa a componenti.

• Three.js quando l’oggetto ha profondità: orbitare, esplodere un pezzo, cambiare un materiale, camminare in una stanza.
• Tenete il GLTF magro. Un divano da 40 MB uccide il mobile. LOD, texture compresse e un’immagine poster finché la scena non parte.
• Non mettete prezzo, CTA o checkout dentro il canvas. HTML accanto. La scena vende l’oggetto; il documento chiude l’affare.

3. Pixi.js: 2D a 60 fps, non un motore di gioco

Pixi.js è un renderer 2D. Sprite, display list, filtri, sistemi di particelle, animazione scheletrica in stile Spine. Accorpa i draw call sulla GPU, così un rullo di slot, una lavagna per bambini o una mappa con qualche migliaio di pin non fonde il main thread come una lista DOM. Si usa perché Canvas 2D a quel volume è troppo lento, e perché l’app web c’è già: nessuno vuole adottare un framework di gioco intero solo per dipingere in fretta.

Phaser è un framework di gioco: scene, fisica, input, audio. Pixi è lo strato sotto quando React, routing e auth sono già vostri. Ads interattive, minigiochi di brand, dashboard con più punti di quanti SVG dovrebbe portare, e UI in stile casinò: il brief abituale. Se il prodotto è un gioco vero con livelli e un mondo fisico, partite da un motore di gioco. Se il prodotto è un’app Next.js che su una route ha bisogno di un palco 2D caldo, Pixi è la libreria che prenderei.

• Pixi quando il problema è quantità e fluidità in 2D: particelle, sprite sheet, filtri, un palco che si ridisegna ogni frame.
• Mettete gli sprite in un atlas. Diecimila PNG sparsi bloccano il load anche se la GPU poi è contenta.
• Mettete in pausa il ticker quando la scheda è nascosta. Un palco Pixi che continua a ticchettare in background è un reclamo sulla batteria che deve ancora arrivare.

4. Come scelgo: CSS, GSAP, Pixi, Three

L’errore costoso è usare un motore 3D per far dissolvere un bottone. L’ho già scritto: lo scroll storytelling premium è GSAP e ScrollTrigger; lo stato di una UI React è Framer Motion. Quelle librerie animano nodi che restano nel documento. Three e Pixi creano un mondo che non è il documento. Mischiarli va bene. Sostituire lo strato sbagliato è come una landing spedisce un hero WebGL da 800 KB che nessuno ha chiesto di orbitare.

• Hover, fisarmonica, transizione di pagina, feedback di form: CSS o Framer Motion. Restate nel DOM.
• Sezioni pinnate, timeline con scrub, scroll cinematografico: GSAP. È ancora il documento, solo coreografato.
• Migliaia di oggetti 2D, particelle, un palco che deve tenere 60 fps: Pixi.js.
• Profondità, camera, luci, un modello da orbitare: Three.js. Non un rullo di slot 2D.

5. Il conto: vitals, SEO, a11y, telefoni economici

Un canvas WebGL è invisibile a un crawler. Quello che l’utente deve leggere - nome, prezzo, legale, FAQ - vive nell’HTML intorno al palco, non dipinto in una texture. Ho già scritto come i Core Web Vitals muovono i ricavi. Un hero 3D impaziente in home è un autogol classico su LCP e INP: il GLTF lotta col first paint, poi il loop di render ruba l’input. Lazy-loadate la scena quando il documento è già utile. Prima un poster statico. Distruggete il renderer all’unmount o la GPU perde attraverso le navigazioni client.

L’accessibilità è una UI parallela, non un attributo del canvas. Orbita da tastiera, alternativa testuale per il modello, reduced-motion che ferma il loop. Un Android economico limita termicamente un fragment shader occupato. Tappate il pixel ratio, offrite un fallback «foto 2D» e non fate del contesto WebGL che non è partito l’unico percorso verso lo SKU.

6. Next.js: isola client, non un Server Component

Sul server non c’è WebGL. La scena è un client component, caricato con next/dynamic e ssr: false, dietro un poster o uno skeleton. React Three Fiber se il resto dell’app è React. @pixi/react se il palco deve parlare con lo stesso albero di stato. Non farei SSR di un canvas «per la SEO»: il crawler vede comunque un bitmap vuoto. Mettete il testo nell’HTML renderizzato sul server. L’isola si avvii quando l’utente è pronto a giocare con l’oggetto.

Conclusione: scegliete la superficie che sta con l’oggetto

I team usano Three.js perché uno SKU 3D vende meglio quando il cliente può orbitarlo. Usano Pixi.js perché duemila sprite a 60 fps non sopravvivono come div. Nessuna libreria sostituisce CSS, GSAP o un documento veloce. Se il brief è «fatelo sentire premium», parto dal movimento nel DOM. Se il brief è «fate girare questa cucina» o «tenete le monete a schermo», lascio il DOM di proposito, isolo il canvas e lascio nell’HTML il testo che servono a Google e a uno screen reader. Chiudo questo da senior web engineer: isole Next.js, WebGL pigro, GSAP dove la pagina è ancora una pagina. Scrivete dal form il conteggio oggetti, se è 2D o 3D, e se lo stesso URL deve posizionarsi. Non partiremo buttando un canvas in home «per sembrare moderni».