Por qué usaría Three.js y Pixi.js

Una página en el navegador es un documento: títulos, botones, formularios, enlaces que un crawler lee. CSS, GSAP y Framer Motion mueven ese documento. Es la herramienta correcta para casi cada sitio de marketing que entrego. Three.js y Pixi.js existen para el otro trabajo: una escena que pinta la GPU, no un árbol de divs. Los equipos los eligen cuando el DOM pierde frames, cuando el objeto es un SKU 3D, o cuando dos mil monedas deben quedarse en pantalla a 60 fps.

Ya escribí cuándo GSAP y Framer Motion merecen su sitio en un handoff de Figma a código. Este no es ese artículo. Aquí: cuándo saldría del DOM, para qué es de verdad cada librería, y la factura en Core Web Vitals, SEO y accesibilidad si pone un canvas WebGL en una URL de negocio.

1. El DOM es un documento. Un canvas es una superficie de dibujo

Cada nodo del DOM carga layout, estilo, hit-testing y un sitio en el árbol de accesibilidad. Ese coste es el sentido de la web: el texto se selecciona, el formulario se recorre con tab, Google indexa el título. Por eso mil divs en position absolute dan tirones en un teléfono de gama media. Un canvas es un bitmap. Usted dice a la GPU qué dibujar este frame. Un sprite no tiene layout. Tampoco tiene título para el crawler ni nombre para el lector de pantalla, salvo que lo construya al lado del canvas.

WebGL crudo (y ahora WebGPU) son cámaras, buffers, shaders y draw calls. Se puede escribir. La mayoría de equipos de producto no deberían. Three.js y Pixi.js envuelven esa superficie en un grafo de escena, loaders y una bolsa de contratación. Paga con peso de bundle y una caja negra en medio de la página. La pregunta nunca es «qué cool es el render en GPU». Es si el producto necesita de verdad una escena.

2. Three.js: un mundo 3D en la pestaña

Three.js es un motor 3D para el navegador. Obtiene escena, cámara, luces, meshes, materiales y texturas. La librería habla con WebGL; hay un renderer WebGPU para GPUs más nuevas. Se usa porque un modelo GLTF de un sofá, una cocina o una turbina es más barato de girar en la pestaña que filmar cada ángulo, y porque una cámara que se puede orbitar vende mejor que un carrusel de PNG.

El trabajo típico que veo: configuradores de producto (color, tela, extras), recorridos de arquitectura, datos científicos o financieros en el espacio, stands WebXR, escenas hero en un sitio de marca que deben sentirse como un fotograma que se puede tocar. Babylon.js es una alternativa real, con un editor más fuerte. Three.js ganó los ejemplos, las respuestas de Stack Overflow y React Three Fiber - así cablearía una escena en una app Next.js que ya piensa en componentes.

• Three.js cuando el objeto tiene profundidad: orbitar, explosionar una pieza, cambiar un material, recorrer una habitación.
• Mantenga el GLTF delgado. Un sofá de 40 MB mata el móvil. LOD, texturas comprimidas y una imagen póster hasta que arranque la escena.
• No ponga el precio, el CTA ni el checkout dentro del canvas. HTML al lado. La escena vende el objeto; el documento cierra el trato.

3. Pixi.js: 2D a 60 fps, no un motor de juego

Pixi.js es un renderer 2D. Sprites, display list, filtros, sistemas de partículas, animación esquelética al estilo Spine. Agrupa draw calls en la GPU, así que un rodillo de slot, un tablero educativo o un mapa con unos miles de pines no funde el main thread como una lista DOM. Se usa porque Canvas 2D es demasiado lento a esa cantidad, y porque la app web ya está: nadie quiere adoptar un framework de juego entero solo para pintar rápido.

Phaser es un framework de juego: escenas, física, input, audio. Pixi es la capa de debajo cuando React, el routing y el auth ya son suyos. Anuncios interactivos, minijuegos de marca, dashboards con más puntos de los que SVG debería cargar, y UI estilo casino: el brief habitual. Si el producto es un juego de verdad con niveles y un mundo físico, empiece con un motor de juego. Si el producto es una app Next.js que necesita un escenario 2D caliente en una ruta, Pixi es la librería a la que iría.

• Pixi cuando el problema es cantidad y suavidad en 2D: partículas, sprite sheets, filtros, un escenario que se redibuja cada frame.
• Meta los sprites en un atlas. Diez mil PNG sueltos atascan la carga aunque la GPU luego esté contenta.
• Pause el ticker cuando la pestaña esté oculta. Un escenario Pixi que sigue latiendo en segundo plano es una queja de batería que aún no llegó.

4. Cómo elijo: CSS, GSAP, Pixi, Three

El error caro es usar un motor 3D para fundir un botón. Ya escribí: el scroll storytelling premium es GSAP y ScrollTrigger; el estado de una UI React es Framer Motion. Esas librerías animan nodos que se quedan en el documento. Three y Pixi crean un mundo que no es el documento. Mezclarlos vale. Sustituir la capa equivocada es cómo un landing publica un hero WebGL de 800 KB que nadie pidió orbitar.

• Hover, acordeón, transición de página, feedback de formulario: CSS o Framer Motion. Quédese en el DOM.
• Secciones fijadas, timeline con scrub, scroll cinematográfico: GSAP. Sigue siendo el documento, solo coreografiado.
• Miles de objetos 2D, partículas, un escenario que debe sostener 60 fps: Pixi.js.
• Profundidad, cámara, luces, un modelo que se orbita: Three.js. No un rodillo de slot 2D.

5. La factura: vitals, SEO, a11y, teléfonos baratos

Un canvas WebGL es invisible para un crawler. Lo que el usuario debe leer - nombre, precio, legal, FAQ - vive en el HTML alrededor del escenario, no pintado en una textura. Ya escribí cómo Core Web Vitals mueven ingresos. Un hero 3D ansioso en la home es un autogol clásico de LCP e INP: el GLTF pelea con el first paint, luego el bucle de render roba el input. Cargue la escena con lazy load cuando el documento ya sea útil. Primero un póster estático. Destruya el renderer en el unmount o la GPU se filtra por las navegaciones del cliente.

La accesibilidad es una UI paralela, no un atributo del canvas. Órbita con teclado, alternativa de texto para el modelo, reduced-motion que para el bucle. Un Android barato limita térmicamente un fragment shader ocupado. Tope el pixel ratio, ofrezca un fallback «fotos 2D» y no haga del contexto WebGL que no arrancó el único camino al SKU.

6. Next.js: isla de cliente, no un Server Component

En el servidor no hay WebGL. La escena es un client component, cargado con next/dynamic y ssr: false, detrás de un póster o un skeleton. React Three Fiber si el resto de la app es React. @pixi/react si el escenario debe hablar con el mismo árbol de estado. No haría SSR de un canvas «para SEO»: el crawler sigue viendo un bitmap vacío. Ponga el texto en el HTML renderizado en servidor. Deje que la isla arranque cuando el usuario quiera jugar con el objeto.

Conclusión: elija la superficie que encaja con el objeto

Los equipos usan Three.js porque un SKU 3D vende mejor cuando el cliente puede orbitarlo. Usan Pixi.js porque dos mil sprites a 60 fps no sobreviven como divs. Ninguna librería sustituye CSS, GSAP o un documento rápido. Si el brief es «que se sienta premium», empiezo con movimiento en el DOM. Si el brief es «gire esta cocina» o «mantenga las monedas en pantalla», salgo del DOM a propósito, aíslo el canvas y dejo en HTML el texto que Google y un lector de pantalla necesitan. Cierro esto como ingeniera web senior: islas Next.js, WebGL perezoso, GSAP donde la página sigue siendo página. Escriba por el formulario el recuento de objetos, si es 2D o 3D, y si la misma URL debe posicionar. No empezaremos tirando un canvas a la home «para que se vea moderno».