Qué resuelve cada modelo en la práctica

La teoría de los tres modelos se aprende en diez minutos; saber cuál toca en un problema que aún no está definido del todo es lo que cuesta años. Esta lección recorre los casos que aparecen de verdad en producción —gráficas, editores, mapas, iconos, efectos, juegos— y para cada uno explica no solo qué modelo gana, sino qué señal concreta te avisará de que te equivocaste.

Los casos que gana SVG

SVG gana siempre que la escena tenga pocos elementos y cada uno signifique algo. La palabra clave es “significar”: si un elemento tiene identidad —es este botón, este país, esta serie de datos— y el usuario va a interactuar con él o un lector de pantalla va a nombrarlo, el elemento quiere ser un nodo del DOM.

El caso arquetípico es el icono. Un icono tiene entre cinco y cuarenta segmentos de ruta, se escala a cualquier tamaño sin perder nitidez, hereda el color del texto con currentColor y se puede animar con CSS. Meter iconos en canvas es un error que nadie comete dos veces.

El segundo caso es la gráfica de datos con pocos puntos. Un gráfico de barras de doce meses, un diagrama de dispersión de doscientos puntos, un mapa coroplético de cincuenta regiones: en todos ellos el usuario espera pasar el ratón por encima y ver un tooltip, y espera que la exportación a PDF salga nítida. Eso es exactamente lo que un árbol de nodos hace bien y una rejilla de píxeles hace mal.

El tercero es el diagrama con estructura: organigramas, flujos, esquemas técnicos. Cada caja y cada flecha tiene nombre, y el documento resultante es tan útil en un <img> como dentro de la página.

<!-- Un icono SVG en línea: hereda el color, escala y se anima con CSS -->
<button class="fav">
  <svg viewBox="0 0 24 24" width="20" height="20" aria-hidden="true">
    <path d="M12 3l2.6 5.8 6.4.7-4.8 4.3 1.4 6.2L12 17l-5.6 3 1.4-6.2L3 9.5l6.4-.7z"
          fill="currentColor" />
  </svg>
  Favorito
</button>
<style>
  .fav { color: #f9e2af; }
  .fav:hover svg { transform: scale(1.15); transition: transform .15s; }
</style>

Los casos que gana canvas

El canvas gana cuando la escena no cabe en el DOM o cuando no es una escena sino una imagen.

El primer grupo es el del volumen. Un diagrama de dispersión con cien mil puntos, un mapa de calor de una matriz de un millón de celdas, un editor de líneas de tiempo con miles de eventos, la vista general de una forma de onda de audio. En todos ellos ningún elemento individual tiene identidad para el usuario: le importa la nube, no el punto. Y el coste por nodo del DOM multiplicado por cien mil es sencillamente inviable.

El segundo grupo es el de la pintura. Una aplicación de dibujo, un editor de fotos, un filtro en vivo sobre una cámara, un efecto de partículas. Aquí no hay formas que retener: hay píxeles que se acumulan. Preguntar “¿qué objeto es este trazo?” no tiene sentido, porque el trazo es el resultado.

El tercer grupo es el del fotograma completo: juegos, visualizaciones que se recalculan enteras cada tick, simulaciones. Si el fotograma N no se parece al N-1 en nada estructural, el modo retenido no aporta nada y solo cobra.

<canvas id="nube" width="800" height="500"></canvas>
<script>
  const ctx = document.getElementById('nube').getContext('2d');
  const N = 100000;
  // 100.000 puntos: en SVG serian 100.000 nodos. Aqui es un bucle.
  ctx.fillStyle = 'rgba(137, 180, 250, 0.35)';
  for (let i = 0; i < N; i++) {
    const x = Math.random() * 800;
    const y = 250 + (Math.random() + Math.random() + Math.random() - 1.5) * 120;
    ctx.fillRect(x, y, 1, 1);
  }
</script>

Ese bucle se ejecuta en unos pocos milisegundos. El equivalente en SVG haría que la pestaña dejase de responder durante segundos, y después seguiría lenta para siempre.

Los casos que gana CSS, y los híbridos

CSS sigue siendo la respuesta para todo lo que sea decoración de una caja que ya existe: fondos con degradado, sombras, bordes redondeados, recortes sencillos con clip-path, filtros, y cualquier transición o animación de esas propiedades. La ventaja no es sintáctica sino de arquitectura: esas propiedades las anima el compositor sin pasar por el hilo principal, y el elemento sigue siendo accesible y clicable sin trabajo adicional.

El error más habitual no es elegir mal entre canvas y SVG, sino no darse cuenta de que el problema era de CSS. Un fondo animado, un indicador de progreso circular, una tarjeta con un brillo que sigue al ratón: los tres se resuelven con propiedades personalizadas y degradados, y los tres acaban demasiado a menudo dentro de un requestAnimationFrame que repinta un canvas sesenta veces por segundo para lograr algo que el compositor haría gratis.

El enfoque híbrido merece un párrafo propio porque es lo que hacen las aplicaciones gráficas serias. La regla que funciona es separar por capa según el papel, no según la tecnología: el fondo denso y no interactivo va en canvas, los elementos con identidad e interacción van en SVG encima, y el cromo de la interfaz va en HTML y CSS por encima de todo. Las tres capas se apilan con posicionamiento absoluto y comparten un mismo sistema de coordenadas que tú defines. Un mapa de teselas, un editor de nodos, una línea de tiempo de vídeo: todos tienen esa forma.

Señales de que elegiste mal

Hay síntomas que aparecen antes del desastre y que conviene saber leer.

Estás en SVG y deberías estar en canvas cuando el perfil de rendimiento muestra que el tiempo se va en Recalculate Style y Layout, no en Paint; cuando el número de nodos crece con los datos y no tienes techo; o cuando has empezado a reciclar nodos a mano para no crear y destruir.

Estás en canvas y deberías estar en SVG cuando has escrito tu propio sistema de eventos por elemento, cuando llevas un mapa de identificadores a rectángulos para saber sobre qué está el ratón, cuando el diseñador pide un tooltip por elemento, o cuando alguien pregunta por la accesibilidad y no tienes respuesta. Todo eso es el modo retenido pidiendo que lo dejes salir.

Estás en cualquiera de los dos y deberías estar en CSS cuando lo que dibujas es rectangular, va pegado a un elemento del documento y se anima en una sola propiedad.