UnHTML frente a Anima: en qué dirección va realmente la conversión

UnHTML y Anima resuelven problemas opuestos

UnHTML convierte una página web en capas de Figma. Anima convierte un diseño de Figma en código. Dos trabajos distintos. Se agrupan porque ambos tocan Figma y ambos pueden partir de una URL, pero la conversión corre en direcciones opuestas dentro del mismo proceso. Confúndelos y elegirás la herramienta equivocada para el trabajo que realmente tienes.

Esa confusión importa más de lo que parece. Un diseñador que hereda un sitio sin archivo de diseño necesita la dirección de página web a Figma. Un equipo que ya tiene un archivo de Figma y necesita un front end funcional necesita la dirección de Figma a código. Buscar "alternativa a anima" o "unhtml vs anima" suele significar que alguien probó primero la herramienta equivocada: intentó exportar código desde una página que nunca estuvo en Figma, o intentó importar una página web en un plugin que solo lee archivos de Figma. Esto es lo que hace cada herramienta, dónde se superponen realmente los dos flujos de trabajo y dónde los separa el precio.

Qué hace UnHTML

UnHTML toma una página web activa y la convierte en capas nativas y editables de Figma: frames reales, texto, imágenes, vectores y auto layout mapeado desde el propio CSS de la página. El resultado es un archivo de Figma. Nada en él produce código.

Funciona sin conexión por defecto, cero solicitudes de red con la configuración predeterminada. Obtener recursos remotos y ejecutar scripts de la página es una opción única de activación manual, desactivada salvo que la actives tú, así que nada sale de tu máquina de otro modo.

El precio es una compra única, no una suscripción. La versión Free importa hasta 500 capas usando posicionamiento absoluto. Pro cuesta $39 de pago único por editor, elimina el límite de capas y añade la conversión a auto layout. Studio cuesta $119 de pago único y cubre cinco editores.

La importación no es pixel exacta, y no lo intenta. Las fuentes que no están instaladas localmente se sustituyen, por defecto por Inter, y cada sustitución aparece en el informe de importación en lugar de cambiar el diseño en silencio. Las rejillas complejas que no se pueden representar como auto layout de Figma vuelven al posicionamiento absoluto en lugar de producir un diseño que se ve bien hasta que alguien redimensiona un frame.

Lo que no hace: no exporta código, ni React, ni HTML. Si el objetivo es código de front end listo para producción, esta no es la herramienta. Tampoco es una herramienta de diseño para construir algo nuevo. Es una forma de llevar una página existente a un formato que Figma puede editar.

Qué hace Anima

El producto principal de Anima corre en la dirección contraria: entra un diseño de Figma, sale código. El plugin de Figma de Anima exporta una selección de un archivo de Figma ya existente a React, HTML, CSS o Tailwind, Vue, TypeScript, Next.js y más, partiendo de un archivo ya construido en Figma. Anima Playground ofrece la misma exportación a partir de un enlace de Figma pegado, pensada para prototipos rápidos y personas que no son diseñadoras.

Anima también tiene una función de clonar sitios web, y esta es la parte que causa la confusión. Clone website toma una URL activa, el mismo tipo de punto de partida que usa UnHTML, pero produce código, HTML o React, no capas de Figma. El punto de entrada se parece; el punto de salida es el opuesto. Si el objetivo es un archivo de Figma editable, Clone website no te lleva ahí.

Es fácil pasar esto por alto porque técnicamente ambas herramientas pueden partir de "una URL". Lo que importa es qué sale al otro lado. El propio material de Anima presenta el producto en torno a equipos que construyen aplicaciones completas a partir de un diseño de Figma existente, no en torno a recrear una página que no tiene ningún archivo de Figma de origen. Es una herramienta de diseño a código con un atajo de clonado de sitios web añadido, no una herramienta de web a diseño.

Cómo funciona realmente la conversión de auto layout

La razón por la que una conversión de página web a Figma puede sostenerse tiene que ver con lo mucho que el motor de auto layout de Figma ahora refleja el CSS. La propia guía de Figma sobre usar auto layout pensando en CSS Flexbox describe el padding, el gap y el dimensionado de fill container siguiendo el modelo de CSS border-box. Un elemento con padding sigue recibiendo el espacio que necesita en lugar de comprimirse, y los hijos configurados como fill container distribuyen el espacio según su área de contenido en lugar de según su propio tamaño, igual que funciona el dimensionado border-box en CSS.

El espaciado también coincide. Los valores de auto-spacing de Figma Between, Evenly y Around corresponden directamente a los valores CSS space-between, space-evenly y space-around. La propiedad gap de CSS es en sí misma un atajo para row-gap y column-gap en contenedores flex y grid, y es esta propiedad, leída directamente de la hoja de estilos de la página, la que se traduce en el valor de gap de un frame de Figma.

Cuando un diseño no se puede reproducir con fidelidad, rejillas complejas, apilamientos no estándar, la solución de reserva es el posicionamiento absoluto en lugar de adivinar una estructura. Un límite deliberado, no un fallo: una alternativa honesta vale más que un diseño que parece correcto y se rompe en cuanto alguien lo toca.

Ese límite también explica por qué las dos herramientas no pueden simplemente intercambiar sus papeles. El plugin de Anima lee la configuración de auto layout propia de un frame de Figma y la escribe como CSS flexbox, una traducción que funciona porque Figma ya almacena el diseño de forma estructurada e inspeccionable. Ir en la dirección contraria significa leer el CSS calculado de una página ya renderizada y reconstruir qué configuración de auto layout la reproduciría. Leer datos estructurados y escribir CSS es un problema más acotado que leer los estilos renderizados de una página activa y reconstruir su estructura a partir de ellos. Parte de por qué terminaron siendo dos productos separados en lugar de uno que hiciera ambas cosas.

Precio: pago único frente a suscripción

La página de precios de Anima revela los límites diarios del nivel gratuito y el mínimo de Enterprise, pero no publica un precio fijo por puesto para un plan de pago estándar a fecha de esta redacción. Esa cifra queda como no verificada en lugar de adivinada.

La división práctica: quien importa una página de forma ocasional paga una sola vez con UnHTML y ya está. Un equipo que exporta código de forma continua carga con una suscripción que escala según cuánto la use, sin importar qué plan concreto elija.

Cuándo usarías realmente las dos

Los dos flujos de trabajo se encadenan en una sola dirección. Importa una página existente a Figma, rediséñala ahí, y luego entrega el archivo de Figma terminado a Anima para exportar la versión rediseñada como código. Un recorrido real y habitual: desmontar, rediseñar, publicar. Un equipo que reconstruye una página antigua, o que desmonta la página de un competidor para ver cómo está hecha, obtiene un punto de partida editable sin redibujar cada frame a mano, y luego entrega el resultado a la herramienta de exportación de código que ya use el equipo de front end.

Ir en el otro sentido, de Figma a código y de vuelta a Figma, no tiene sentido. Solo reimporta lo que ya existía. Si un diseño ya vive en Figma, no hay nada que UnHTML pueda convertir, y ejecutar una importación sobre una página renderizada desde ese mismo archivo de Figma solo reconstruiría una copia de un archivo que el equipo ya tiene.

La dirección es toda la respuesta

UnHTML y Anima no compiten por el mismo trabajo. Uno convierte una página web en un archivo de Figma editable; el otro convierte un archivo de Figma en código. Elige el primero cuando el destino sea Figma. Elige el segundo cuando el destino sea código listo para publicar. La mayoría de los proyectos que necesitan ambos los usarán en ese orden, no como alternativas entre sí.