Un primer vistazo a Astryx, el sistema de diseño de Meta

Astryx es la reconstrucción de código abierto que Meta hizo del sistema de diseño que creció dentro de la empresa, anunciada en el blog de Astryx el 18 de junio de 2026 y publicada como beta pública bajo la licencia MIT, con más de 150 componentes accesibles de React, siete temas listos para usar, plantillas y una CLI, construidos sobre React 19 o posterior y StyleX.

Si has trabajado con MUI, conoces una versión del dilema: los componentes funcionan, y luego te pasas un sprint peleándote con un objeto de tema para que un botón deje de parecerse al botón de otra persona. Si eres dueño del código fuente de shadcn/ui, conoces la otra: cuarenta archivos de componentes en tu repositorio, enteramente tuyos, sin un upstream del que traer una corrección de gestión de foco.

La propuesta de Meta es que Astryx se sitúa entre ambas. La lista de características es fácil de encontrar; lo que realmente determina el coste de adoptarlo es la escalera de personalización de cinco peldaños y en qué peldaño de esa escalera acaba viviendo tu equipo. Este artículo cubre qué es Astryx, cómo se instala y se consume, cómo funciona el theming, qué te cuesta cada peldaño de esa escalera y dónde se ubica frente a shadcn/ui y Base UI.

¿Qué es Astryx?

Astryx es una biblioteca de componentes con todo un sistema envolviéndola: componentes de React tipados distribuidos junto a CSS precompilado, además de theming a nivel de marca, modo oscuro, plantillas de página y una CLI, todo distribuido como un único conjunto de paquetes. El artículo técnico de Meta lo presenta como la reconstrucción de código abierto de un sistema que creció dentro de la empresa durante ocho años, alcanzó más de 13.000 productos y recibió aproximadamente la mitad de sus actualizaciones de la comunidad de desarrolladores interna. Los estilos se escriben con StyleX, el compilador de Meta que convierte objetos de estilo en CSS atómico y libre de colisiones en tiempo de compilación, lo cual importa si tu objeción al CSS-in-JS es el coste en tiempo de ejecución: no hay ningún motor de estilos corriendo en el navegador.

La CLI es donde ocurre la mayor parte del trabajo con el proyecto, tanto para personas como para máquinas. La documentación de componentes, los design tokens, las plantillas de página, las herramientas de theming y los codemods de actualización salen todos de ahí, ya sea que la invoques desde una terminal, leas su salida JSON tipada o importes sus funciones, y tanto los agentes como las herramientas de build pasan por la misma API. La manera en que el propio proyecto se describe como “AI-fluent” y preparado para agentes es posicionamiento, no un resultado medido; el banco de pruebas de evaluación que describe Meta no tiene resultados publicados en ninguna de las dos entradas del anuncio.

¿Cómo se consume Astryx en la práctica?

React 19 es el mínimo: @astryxdesign/core declara react y react-dom en 19.0.0 o superior como peer dependencies. Esa es la primera barrera. La segunda es la madurez: @astryxdesign/core se publica en una línea 0.x en npm, y @astryxdesign/vega y @astryxdesign/charts solo distribuyen builds reales bajo el dist-tag @canary, con su tag latest todavía apuntando a una release de marcador de posición.

Instala el paquete core, un paquete de tema y el peer de StyleX, con la CLI como dependencia de desarrollo:

npm install @astryxdesign/core @astryxdesign/theme-neutral @stylexjs/stylex
npm install -D @astryxdesign/cli
npx @astryxdesign/cli init

El paso init escribe el índice de componentes de Astryx en tu AGENTS.md o CLAUDE.md, algo que puedes omitir si ningún agente toca el repositorio. En la vía simple, después importas tres hojas de estilo, en orden, y envuelves la aplicación en un proveedor de tema:

@import '@astryxdesign/core/reset.css';
@import '@astryxdesign/core/astryx.css';
@import '@astryxdesign/theme-neutral/theme.css';

Según el propio repositorio, esa es toda la configuración: las tres importaciones, el proveedor y ningún cambio en tu cadena de herramientas de build. La vía avanzada compila desde el código fuente TypeScript y StyleX usando @astryxdesign/build, que incluye los plugins de Babel, PostCSS y Vite, de modo que el bundler emite estilos solo para los componentes que realmente importas. Meta sitúa esa vía en aproximadamente un tercio de la hoja de estilo completa en su propia aplicación de referencia, lo cual es su medición sobre su propio código, no una regla general. Cada componente proviene de su propio subpath y no de la raíz del paquete.

Theming: el comportamiento en el sistema, la apariencia en los tokens

Astryx divide la responsabilidad por la mitad. El comportamiento y la accesibilidad viven en la biblioteca; la apariencia vive en una capa de tokens, de modo que una configuración de tema contiene color, tipografía, radio, espaciado y movimiento, y editar un solo valor reestiliza todos los componentes que lo leen sin que nadie abra el código de un componente. Los valores de modo claro y oscuro conviven en el mismo tema en lugar de en dos archivos paralelos, y un tema puede intercambiarse en tiempo de ejecución o compilarse en una hoja de estilo estática. Los temas van más allá de las variables CSS: pueden sobrescribir componentes individuales y partes de componentes, y añadir variantes propias.

El proyecto incluye siete temas listos para usar, y partes de uno en lugar de partir de cero: theme list muestra lo disponible, incluidos los temas de integraciones instaladas, y theme add <slug> deposita el que elijas en tu proyecto como código fuente editable. Esa es la apuesta de diseño en una línea. El diseñador es dueño de un archivo de configuración, y nadie tiene que bifurcar o envolver un componente para cambiar su aspecto.

La ruta de personalización gradual

La personalización en Astryx escala a través de cinco peldaños: usar los componentes tal como vienen, ajustar los tokens del tema, añadir nombres de clase, superponer tu propio CSS y, finalmente, hacer swizzle del código fuente de un componente hacia tu repositorio. Cada peldaño te compra más control y te cuesta más propiedad. Los primeros cuatro te mantienen en la ruta de actualización compartida; el quinto saca a ese componente de ella de forma permanente.

El swizzle es la puerta de un solo sentido. Algunos internos simplemente no están expuestos por la API pública, como el estado privado, la estructura del DOM o listeners de eventos a los que no puedes llegar, y expulsar el código fuente es la única vía hacia ellos; a partir de ese momento mantienes tú el componente, no la biblioteca. La CLI expulsa el código fuente de componentes y ejecuta codemods de versión con astryx swizzle Button y astryx upgrade --apply:

npx @astryxdesign/cli swizzle Button

Usa la forma con scope para ejecuciones puntuales: hasta que @astryxdesign/cli sea una dependencia, npm resuelve un astryx sin scope hacia un paquete que no tiene relación. El movimiento práctico antes de adoptar Astryx es contrastar tus dos o tres componentes más difíciles con el quinto peldaño: si la personalización que necesitas requiere acceso a los internos, contabiliza desde el primer día el coste de ser dueño de ese código.

Interoperabilidad de estilos: xstyle, className y Tailwind

Los componentes de Astryx aceptan tanto una prop tipada xstyle para sobrescrituras con StyleX como un className simple, así que conviven con Tailwind, CSS Modules u hojas de estilo convencionales. El mismo componente, de tres maneras:

import * as stylex from '@stylexjs/stylex';
import {Button} from '@astryxdesign/core/Button';

const styles = stylex.create({
  save: {alignSelf: 'flex-end', marginBlockStart: 24},
});

// 1. As shipped
<Button label="Save" variant="primary" />;

// 2. Typed StyleX override, compiled at build time
<Button label="Save" variant="primary" xstyle={styles.save} />;

// 3. Plain className, no compiler involved
<Button label="Save" variant="primary" className="ml-auto mt-6" />;

En la vía precompilada, la opción tres no necesita ninguna herramienta adicional: StyleX es la forma en que Astryx escribe sus estilos, no algo que tengas que configurar. Aplica una condición. Astryx carga sus hojas de estilo en cascade layers, @layer reset para el reset y @layer astryx-base para los estilos de componentes, y las capas no responden a la especificidad: cualquier cosa que quede fuera de una capa, o que esté colocada en una capa declarada después, gana de todos modos. Así que un proyecto que ya arrastra CSS global, un reset antiguo o Tailwind tiene que establecer el orden de capas por sí mismo y colocar deliberadamente cada hoja de estilo en una capa.

Astryx frente a shadcn/ui y Base UI: ¿en qué se diferencian?

Meta plantea Astryx frente a dos escenarios que menciona en el artículo de lanzamiento: adoptas el sistema de diseño de una gran empresa y heredas su marca, o ensamblas componentes copiados y pegados y ganas libertad mientras renuncias a la coherencia compartida, a las correcciones upstream y a una ruta de actualización, con la accesibilidad recayendo en tu equipo por defecto. Ese es el argumento de Meta a favor de su propio producto, y vale la pena contrastarlo con lo que dicen de sí mismas las alternativas. shadcn/ui se describe justo al revés: no es una biblioteca que instalas, sino una forma de construir la tuya, entregándote el código de los componentes para que lo edites directamente. Ser dueño del código es la característica, no un efecto secundario, como cubre con más profundidad nuestro análisis de por qué los equipos se pasan a shadcn/ui. Base UI ofrece componentes y hooks de React headless sin CSS propio, así que el aspecto del resultado depende enteramente de ti.

Léelo como restricciones y no como veredictos: Base UI te da comportamiento accesible y ninguna opinión, shadcn/ui te da el código fuente y el mantenimiento que viene con él, y Astryx te da un sistema con theming del que aún puedes expulsar componente a componente. El quinto peldaño de Astryx llega a la posición de shadcn/ui por otra ruta, un componente a la vez y solo cuando tú lo eliges.

Las salvedades son claras. Es una beta pública en 0.x sin línea estable, exige React 19 y es un proyecto de un único proveedor; la discusión en torno al lanzamiento planteó preguntas sobre gobernanza y mantenimiento a largo plazo que nada público resuelve. La rotación propia de una beta no es hipotética: la versión 0.6.0 rompe a cualquiera que llame directamente a useStepperContext, eliminando los campos de diseño compacto de ese hook y reduciendo StepperContextValue al historial de transiciones y al registro de pasos. Por otro lado, la página de comunidad describe un Discord oficial e issues de GitHub triadas semanalmente.

¿Quién debería probar Astryx ahora y quién debería esperar?

Pruébalo ahora si estás empezando una herramienta interna o un dashboard desde cero sobre React 19, quieres componentes accesibles sin tener que diseñarlos y cuentas con un diseñador que preferiría ser dueño de los tokens antes que revisar pull requests de CSS. Espera si estás por debajo de React 19, si mantienes un producto de cara al público donde una versión menor 0.x que cambie la forma de un contexto te costaría una release, o si la gobernanza de un único proveedor es una cuestión de compras que aún no puedes responder. Un punto intermedio útil es una sola ruta de una aplicación existente: hojas de estilo precompiladas, un orden explícito de @layer y una única pantalla construida sobre componentes que de otro modo habrías escrito tú mismo.

Lo que hay que evaluar no es el número de componentes. Es a qué peldaño de la escalera de personalización te empujan tus requisitos de diseño, porque eso es lo que estarás pagando dentro de un año. Elige los dos componentes con los que tu producto no puede transigir, ejecuta npx @astryxdesign/cli component <Name> sobre cada uno y comprueba si los tokens y className te llevan hasta ahí antes que la expulsión del código fuente.

Preguntas frecuentes

¿Cuál es la diferencia entre Astryx y StyleX?

StyleX es el compilador CSS-in-JS en tiempo de compilación de Meta que convierte objetos de estilo en CSS atómico y libre de colisiones. Astryx es el sistema de diseño de componentes de React cuyos estilos están escritos con él. Astryx instala @stylexjs/stylex como peer dependency, pero consumir las hojas de estilo precompiladas no necesita ningún plugin de build, ni PostCSS, ni configuración de Babel. Solo las compilaciones desde código fuente incorporan los plugins de StyleX de @astryxdesign/build.

¿Funciona Astryx con Next.js, Vite o una configuración simple por CDN?

Sí. El README de @astryxdesign/core documenta configuraciones para Next.js, Tailwind, Vite y CDN. En la vía precompilada importas el reset, la hoja de estilo de componentes y una hoja de estilo de tema, y luego envuelves la aplicación en un proveedor de tema, de modo que no interviene ningún plugin de bundler. Compilar en cambio desde el código fuente TypeScript y StyleX requiere los plugins de Babel, PostCSS o Vite incluidos en @astryxdesign/build.

¿Necesito la CLI de Astryx para usar la biblioteca?

No. Los componentes y el CSS precompilado funcionan solo con los paquetes instalados, y la CLI es una dependencia de desarrollo. La necesitas para theme list y theme add, la documentación completa de componentes, las plantillas, los codemods de actualización y el swizzling. Ejecutar astryx init escribe el índice de componentes de Astryx en AGENTS.md o CLAUDE.md, lo cual solo importa cuando hay agentes de IA trabajando en el repositorio.

¿Están los componentes de gráficos de Astryx listos para producción?

No. @astryxdesign/vega, el wrapper de Vega, y @astryxdesign/charts, la biblioteca de gráficos basada en d3, publican builds reales en npm solo bajo el dist-tag canary; su tag latest apunta a una release de marcador de posición que npm te indica no instalar. El paquete experimental @astryxdesign/lab, donde aterrizan los componentes nuevos antes de graduarse hacia core, se publica de la misma manera. Por tanto, los gráficos quedan por detrás de los paquetes core, que ya de por sí están en beta 0.x, y necesitan su propio plan alternativo.