Open UI de OpenAI vs. Stitch y v0
La especificación Open UI de OpenAI apuesta diferente a Google Stitch o Vercel v0. Esto es lo que el enfoque de estándar abierto significa para los flujos de trabajo de diseño de UI.
Existe una versión de la historia de las UI generadas por IA que va así: cada gran plataforma construye su propia herramienta cerrada, los diseñadores las rodean, y el ecosistema se fragmenta en una docena de pipelines prompt-a-UI incompatibles. Google Stitch genera código que no puedes mover fácilmente. Vercel v0 está profundamente ligado a Next.js. Ambas son apuestas propietarias por un flujo de trabajo amurallado.
El proyecto Open UI de OpenAI es algo completamente distinto — y la distinción importa más de lo que la mayoría de la cobertura ha reconocido.
No es un Producto. Es una Propuesta.
Open UI no es una herramienta de diseño. Es un grupo comunitario bajo el paraguas del W3C que trabaja para estandarizar cómo se definen los componentes de UI en la web — nombres, comportamientos, anatomía, expectativas de accesibilidad. El objetivo es dar a los fabricantes de navegadores, autores de frameworks y equipos de design systems un vocabulario compartido, de modo que un elemento "select" o un componente "tabs" signifique lo mismo en todas partes, y no diecisiete cosas incompatibles.
Ese es un proyecto fundamentalmente diferente al de Stitch o v0, que son herramientas de generación: introduces un prompt o una captura de pantalla y obtienes código. Open UI trabaja una capa por debajo de eso — en la especificación que haría que el código generado sea más portable, más interoperable y más confiable.
Piénsalo así. Stitch y v0 intentan cerrar la brecha diseño-a-código hoy, con la IA haciendo el trabajo de traducción. Open UI intenta hacer que los componentes subyacentes sean más coherentes para que esa brecha sea menor desde el principio — ya sea para la IA o para los humanos.
Por Qué la Capa de Especificación Realmente Importa
Si has trabajado en un design system maduro, conoces el problema de los nombres. Un componente que tu equipo llama "popover" es un "tooltip" en Material, un "floating panel" en otro sistema, y algo completamente distinto en la implementación nativa del navegador. Cuando las herramientas de IA generan UI, heredan toda esa ambigüedad — y la tapan con código de aspecto seguro que no coincide del todo con lo que tu sistema espera.
La investigación de componentes de Open UI documenta cómo varía la anatomía de los componentes en los design systems existentes — analizando todo, desde Bootstrap hasta Fluent y Ant Design — para encontrar definiciones consensuadas. Esa investigación alimenta luego propuestas reales para los navegadores. ¿El elemento <selectlist> que actualmente está en desarrollo en los navegadores? Open UI impulsó esa conversación.
La implicación práctica: a medida que el trabajo de Open UI sea adoptado por los navegadores y los design systems, las herramientas de generación de UI como v0 o Stitch — o lo que venga después — tendrán mejores primitivas hacia las que generar. Menos ambigüedad en la especificación significa menos alucinaciones en el resultado.
Stitch y v0 son Herramientas. Open UI es Infraestructura.
Esta comparación se confunde en muchas coberturas, así que vale la pena ser preciso:
- Vercel v0 es una herramienta de UI generativa. Prompt de entrada, código React/Tailwind de salida. Optimizado para el stack de Vercel. Útil si ya estás ahí, limitante si no.
- Google Stitch es un generador de UI multimodal. Capturas de pantalla, prompts y assets de marca existentes alimentan la generación de componentes de UI. Salida propietaria, profundamente ligada al ecosistema de Google.
- Open UI es un esfuerzo de estandarización. Sin generación. Sin interfaz de prompts. Solo investigadores, ingenieros de navegadores y autores de frameworks intentando ponerse de acuerdo en lo que los componentes son.
Los dos primeros compiten entre sí. El tercero podría mejorar silenciosamente a ambos — o hacerlos irrelevantes para una generación de herramientas que se construyan sobre especificaciones sólidas y portables.
Qué Significa Esto para Tu Design System
Si mantienes un design system, o si estás especificando componentes que eventualmente se entregan a los ingenieros, el trabajo de Open UI ya debería estar en tu radar. Algunas cosas que vale la pena saber:
La documentación de anatomía es cada vez más el estándar. El enfoque de Open UI — catalogar las partes nombradas de cada componente — ha influido en cómo se estructuran las propiedades de componentes de Figma y en cómo se documentan los design tokens en los sistemas modernos. Si la documentación de tus componentes no desglosa la estructura interna (trigger, panel, overlay, etc.), está desactualizada.
Los componentes nativos del navegador son cada vez más capaces. El trabajo de <selectlist>, la popover API (que Smashing Magazine y CSS-Tricks han cubierto recientemente), el elemento <dialog> — todos estos son logros adyacentes a Open UI. Diseñar con estas primitivas en lugar de rodearlas reduce la deuda de componentes que carga tu sistema.
La portabilidad supera a la velocidad de generación. El atractivo actual de Stitch y v0 es la velocidad — obtener algo en pantalla rápidamente. Pero si esa salida está ligada a un framework o sistema de componentes propietario, estás acumulando deuda de migración. Los componentes alineados con Open UI, en cambio, están diseñados para ser portables entre herramientas y stacks.
La Tensión Real
Esto es lo que nadie dice claramente en voz alta: la participación de OpenAI en Open UI — han tenido colaboradores involucrados en el trabajo de especificación — se sitúa de forma incómoda junto a su movimiento más amplio hacia la construcción de productos. Un estándar abierto que hace que los componentes de UI sean interoperables e independientes de las herramientas está, estructuralmente, en tensión con un mundo donde ChatGPT genera interfaces que pasan por las APIs de OpenAI.
No es una conspiración. Los estándares abiertos y los productos propietarios coexisten todo el tiempo — Google contribuye a las especificaciones web mientras gestiona Chrome en su beneficio. Pero vale la pena ser claro: el éxito de Open UI haría que la capa de generación sea más competitiva, no menos. Si los componentes están bien definidos y son portables, hay menos ventaja de lock-in para cualquier herramienta de generación individual.
Eso es, en realidad, bueno para los diseñadores. Significa que las herramientas compiten en la calidad del resultado, no en quién es dueño de la especificación.
Qué Vigilar
Open UI es un trabajo genuinamente poco glamoroso — documentos de investigación de componentes, issues en GitHub, notas de reuniones del W3C. Pero es el tipo de decisión de infraestructura que parece obvia en retrospectiva. Los equipos que hoy construyen con alineación a Open UI pasarán menos tiempo reconstruyendo cuando la UI generada por IA se convierta en una parte estándar de su pipeline.
El explorador de componentes de Open UI y el repositorio de GitHub son los principales lugares para seguir este trabajo. Si contribuyes a un design system, sus documentos de investigación valen la pena guardar en favoritos — no porque vayan a cambiar tu flujo de trabajo mañana, sino porque están dando forma al vocabulario que hablarán tus herramientas en dos años.
Stitch y v0 están compitiendo por cerrar la brecha. Open UI está decidiendo silenciosamente qué hay al otro lado.
Fuentes: Proyecto Open UI, CSS-Tricks sobre Popover vs Dialog, Open UI GitHub, Smashing Magazine, Sidebar.io