Performative-UI y el frontend de los clichés

Performative-UI parece una broma interna, pero toca un punto bastante serio: el frontend moderno vive de reciclar patrones visuales hasta convertirlos en bloques casi automáticos. Lo que antes diseñabas como una pieza única ahora suele terminar en un componente con props, estados y variantes. Y eso no pasa solo por comodidad técnica; pasa porque el producto, el equipo y el negocio necesitan moverse rápido sin rediseñar la rueda cada dos semanas.

La librería usa el humor para señalar algo que cualquiera que haya trabajado en UI reconoce enseguida: banners de cookies, cards de pricing, modales de confirmación, tabs, badges, empty states, alertas de “último paso”, formularios con ayuda contextual y CTA con urgencia artificial. No es solo una colección de piezas. Es una caricatura de cómo la industria empaqueta decisiones de diseño en componentes reutilizables y luego les pone una capa delgada de producto encima.

Qué es Performative-UI y por qué llama la atención

Performative-UI es una librería de componentes de React que se presenta como una colección de “design tropes”, o sea, de clichés visuales del frontend. En lugar de venderte una solución seria para formularios o dashboards, te muestra patrones que ya has visto mil veces en SaaS, landing pages y productos B2B. La gracia está en que no intenta esconder el artificio; lo exhibe.

Si revisas su propuesta, el chiste funciona porque no se burla del código, sino del lenguaje visual que usamos para vender, guiar o empujar decisiones. El típico banner de “solo hoy” no existe porque el producto cambió. Existe porque sabemos que ese patrón mueve clics. La tarjeta con borde suave y sombra leve no es casualidad. Está ahí porque ya aprendimos que comunica jerarquía sin pelearse con el layout.

Eso hace que la librería sea más interesante como comentario cultural que como dependencia técnica. Te obliga a mirar algo que normalmente das por sentado: muchas interfaces no están hechas para expresar una identidad única, sino para repetir fórmulas probadas. Y sí, eso también es diseño.

El chiste funciona porque conoces el patrón

El humor de Performative-UI depende de tu memoria visual. Si nunca has visto una app con un “upgrade now” pegado en un panel lateral, la broma pierde fuerza. Pero si trabajas en producto, ves el patrón en segundos. La interfaz te resulta familiar antes de leer el texto, y ahí está el punto.

Ese reconocimiento inmediato es lo que vuelve tan potente a los componentes de UI. Un botón primario azul, un breadcrumb, una card con título y descripción, un toast de éxito. Son piezas que no necesitas explicar cada vez. El usuario ya sabe cómo leerlas. El equipo ya sabe cómo implementarlas. La empresa ya sabe cómo reutilizarlas.

La librería lo exagera para que notes algo incómodo: cuando un patrón se vuelve demasiado familiar, también se vuelve casi invisible. Y cuando algo es invisible, lo sigues usando sin preguntarte si todavía sirve.

No es solo estética, también es proceso

En frontend, un componente no es solo una decisión visual. Es una decisión de proceso. Cuando conviertes una idea en componente, también conviertes una intención en algo que puede repetirse, medirse y versionarse. Eso es útil, pero también crea inercia.

Piensa en una empresa que lanza 20 experimentos al mes. Si cada experimento requiere diseñar desde cero la misma estructura de pricing, la velocidad se cae. Entonces aparece el sistema de componentes: el pricing block, el testimonial card, el hero con CTA, el modal de consentimiento. Todo queda listo para ensamblarse.

Performative-UI exagera esa lógica para recordarte que muchas interfaces modernas no nacen de una gran idea visual, sino de una biblioteca de piezas conocidas. La creatividad se desplaza del pixel único a la combinación, al copy y a los pequeños matices de interacción.

La capa delgada entre diseño y producto

Hay una razón por la que estas piezas sobreviven tanto: funcionan como una capa delgada entre el sistema de diseño y la promesa comercial del producto. Esa capa no suele ser profunda. Más bien, toma componentes estándar y los viste con un mensaje específico: onboarding, conversión, retención, upsell o activación.

En términos prácticos, esa delgadez es útil. Un equipo pequeño puede sostener una UI consistente sin dedicar semanas a cada pantalla. Y en productos que cambian rápido, eso vale oro. Pero también tiene costo: muchas interfaces empiezan a parecerse entre sí, aunque vendan cosas muy distintas.

La crítica de Performative-UI apunta justo ahí. Cuando todo se resuelve con el mismo set de bloques, el producto puede terminar sintiéndose intercambiable. Cambia el color, cambia el logo, cambia el copy. La estructura sigue siendo la misma.

La reutilización como ventaja y como límite

Reutilizar componentes ahorra tiempo y reduce errores. Eso no está en discusión. Si tienes un sistema bien armado, un botón no se rompe en una pantalla y en otra no. La consistencia mejora, el mantenimiento baja y el onboarding de nuevos devs se vuelve más simple.

Pero la reutilización también fija expectativas. Si tu librería interna define que toda alerta debe verse como un banner amarillo con icono de advertencia, luego cuesta salirse de ahí aunque el contexto pida otra cosa. El componente deja de ser una herramienta y se vuelve una norma.

Ahí aparece la parte performativa del asunto. Muchas veces el componente no solo resuelve una necesidad, también comunica madurez, orden y escalabilidad. Es decir, el frontend no solo sirve al usuario; también sirve para demostrar que el producto “está bien armado”.

Ejemplos reales que seguro has visto

No hace falta buscar demasiado para reconocer estos clichés:

1. El modal de salida con un descuento del 10 %.
2. La card de testimonio con foto circular, nombre y cargo.
3. El panel lateral con progreso de onboarding en 3 pasos.
4. El empty state con ilustración y CTA principal.
5. El pricing table con plan destacado en el centro.

Todos esos patrones existen porque resuelven un problema concreto, pero también porque ya aprendimos que la gente los interpreta rápido. El costo es que su repetición los vuelve previsibles. Y cuando algo es previsible, también se vuelve fácil de parodiar.

Qué nos dice sobre el frontend moderno

La gracia de Performative-UI no está en que invente algo nuevo, sino en que señala una verdad bastante incómoda: el frontend moderno está lleno de convenciones que ya no cuestionamos. Si trabajas con React, Next.js o cualquier stack de componentes, sabes que buena parte del trabajo consiste en ensamblar bloques conocidos con pequeñas diferencias.

Eso no es necesariamente malo. De hecho, es una de las razones por las que hoy puedes lanzar productos mucho más rápido que hace 10 años. La web dejó de ser un lugar donde cada pantalla se construía como una pieza única. Ahora es más parecido a un sistema de ensamblaje con reglas compartidas.

El problema aparece cuando confundes velocidad con criterio. Un componente reutilizable no garantiza una buena experiencia. Solo garantiza que vas a repetir una decisión. Si la decisión era mala, la estás escalando.

Componentes, props y una ilusión de control

React y sus ecosistemas hicieron muy fácil pensar la UI como una composición de piezas. Eso ayuda a ordenar el código, pero también puede dar una sensación falsa de control total. Parece que si todo está encapsulado, todo está resuelto. No siempre.

Un ejemplo simple: un botón con variantes primary, secondary, ghost y destructive. Técnicamente, eso es elegante. Pero si cada variante se usa sin criterio, terminas con pantallas que parecen consistentes solo porque comparten la misma API, no porque comuniquen bien.

Performative-UI se burla de esa confianza automática. No porque los componentes sean malos, sino porque a veces los usamos como sustituto de pensamiento de producto. El bloque existe, así que lo usamos. El sistema lo permite, así que lo repetimos.

El frontend también vende

Hay otra capa que conviene decir sin rodeos: muchas de estas piezas existen para vender. Un hero con tres bullets y un CTA no solo organiza información. También empuja una decisión. Un pricing card no solo compara planes. También orienta la percepción de valor.

Por eso la interfaz moderna está llena de fórmulas. No son neutras. Son estructuras diseñadas para mover atención y reducir fricción. Si una landing page usa el mismo patrón que viste en otras 50, es porque ese patrón ya fue validado para conversión.

La librería lo pone en evidencia de una forma útil: cuando el diseño se vuelve demasiado estándar, la frontera entre patrón útil y cliché comercial se vuelve muy delgada. Y ahí es donde el frontend deja de ser solo interfaz para convertirse en discurso.

Cómo pensar estos patrones sin caer en el cliché

No se trata de pelearte con los componentes ni de volver a diseñar todo desde cero. Se trata de usar mejor lo que ya existe. Si tú trabajas en producto, diseño o frontend, hay varias preguntas que vale la pena hacer antes de aceptar un patrón por inercia.

Primero: ¿el patrón resuelve una necesidad real del usuario o solo facilita el pitch interno? Segundo: ¿el componente ayuda a la comprensión o solo a la consistencia? Tercero: ¿la variante que estás agregando aporta valor o solo suma complejidad visual?

Una buena UI no necesita inventar todo el tiempo. Pero sí necesita saber cuándo repetir y cuándo romper la fórmula. Ahí está la diferencia entre un sistema útil y una plantilla agotada.

Una forma práctica de revisar tus componentes

Si estás auditando una interfaz o un design system, puedes usar este checklist:

1. Identifica los componentes que se repiten en al menos 3 pantallas.
2. Revisa si su comportamiento cambia según el contexto o solo cambia el texto.
3. Mide si el componente reduce decisiones del usuario o solo ocupa espacio.
4. Detecta variantes que nadie usa desde hace meses.
5. Pregunta si el patrón sigue siendo legible en móvil, desktop y estados vacíos.

Este tipo de revisión no requiere una gran ceremonia. Basta con mirar la interfaz como usuario y como equipo. Si un componente existe solo porque “siempre lo hemos hecho así”, probablemente ya merece una revisión.

Cuándo conviene mantener el cliché

No todo cliché es malo. Algunos patrones sobreviven porque funcionan. El breadcrumb sigue siendo útil cuando la jerarquía importa. El skeleton loader ayuda a percibir progreso. El toast de confirmación evita dudas después de una acción importante.

La clave no es eliminar patrones conocidos, sino entender su costo. Si el patrón mejora la lectura, reduce errores o acelera una decisión, tiene sentido. Si solo está ahí para parecer moderno, ya no suma tanto.

En equipos pequeños de LatAm esto pesa más todavía. Muchas veces no tienes un equipo de diseño enorme ni tiempo para iterar 15 veces una pantalla. Entonces la reutilización bien pensada es una ventaja real. Lo que no conviene es convertir esa limitación en dogma.

Lo que puedes aprender si trabajas con React o producto

Si usas React, esta librería te recuerda algo práctico: una API limpia no garantiza una experiencia buena, pero sí puede esconder muchas decisiones detrás de una fachada ordenada. Eso sirve para escalar, pero también puede maquillar problemas de fondo.

También te deja una lección sobre documentación y criterio. Un sistema de componentes claro no solo describe props y variantes. También explica cuándo usar cada cosa y cuándo no. Sin ese contexto, tu biblioteca interna se convierte en un menú de clichés disponibles.

Desde producto, el aprendizaje es parecido. Si tu equipo depende demasiado de patrones prearmados, quizá estás optimizando ejecución, pero no diferenciación. Y si todo el valor de la interfaz se reduce a usar componentes estándar con un copy distinto, el producto pierde voz propia.

Herramientas que sí vale la pena revisar

Si quieres profundizar en cómo se documentan y estructuran estos sistemas, hay fuentes oficiales útiles:

• La documentación de React sobre composición y props: https://react.dev
• La guía de componentes en Storybook: https://storybook.js.org/docs
• La documentación de Next.js para UI y renderizado: https://nextjs.org/docs

No necesitas seguirlas al pie de la letra para entender el punto del artículo, pero sí ayudan a ver cómo la industria formaliza estas decisiones. La diferencia entre una UI improvisada y una UI mantenible suele estar en cómo documentas y gobiernas esos patrones.

Qué haríamos nosotros en un equipo real

Si nosotros tuviéramos que revisar una interfaz con demasiados clichés, empezaríamos por separar tres capas:

• Lo que es necesario para el usuario.
• Lo que existe por consistencia interna.
• Lo que solo está ahí por hábito o por marketing.

Después miraríamos qué componentes merecen quedarse como estándar, cuáles necesitan variantes más simples y cuáles conviene eliminar. No porque el minimalismo sea una religión, sino porque cada componente extra tiene costo de mantenimiento, aprendizaje y decisión.

Tabla resumen

Performative-UI funciona porque no intenta esconder lo obvio: gran parte del frontend moderno está hecho de fórmulas repetidas. Eso no es una falla por sí misma. Es una consecuencia natural de trabajar con sistemas, equipos distribuidos y ciclos de entrega cortos.

La parte útil de la broma es que te obliga a mirar tus propias interfaces con menos fe y más criterio. Si un componente existe, pregúntate por qué. Si un patrón se repite, pregúntate qué resuelve. Y si todo en tu producto parece correcto pero también intercambiable, quizá el problema no está en la tecnología, sino en la costumbre.