3 puntos por GN⁺ 5 시간 전 | 1 comentarios | Compartir por WhatsApp
  • A partir de julio de 2026, shadcn/ui cambiará el flujo predeterminado de los nuevos proyectos y la documentación para centrarse en Base UI, dejando atrás la configuración por defecto basada en Radix que había mantenido desde su lanzamiento en 2023
  • Base UI ya alcanzó la versión estable 1.6.0 y supera los 6 millones de descargas semanales; además, en los proyectos creados con shadcn/create se elige más que Radix en una proporción de 2:1
  • Radix no será discontinuado: las apps existentes pueden mantenerse como están y, salvo los componentes exclusivos de Base UI, las actualizaciones y los componentes nuevos seguirán llegando a ambas bibliotecas
  • La migración no se ofrece como codemod sino como una skill de agente, lo que permite mover de forma gradual componentes modificados y sus usos, componente por componente, dejando reportes en .migration/ y commits en git
  • Con componentes de UI para chat, un registry basado en repositorios de GitHub, shadcn eject y el nuevo estilo Rhea, el alcance de shadcn/ui se amplía hacia la distribución de componentes y la composición general de interfaces de producto

Base UI se convierte en la biblioteca de componentes predeterminada

  • Desde julio de 2026, Base UI será la biblioteca de componentes predeterminada de shadcn/ui
  • Cuando shadcn/ui se lanzó en enero de 2023, fue construido sobre Radix, que en ese momento era una opción con componentes headless sin estilos, una buena API, accesibilidad y experiencia de uso en aplicaciones reales
  • Base UI es una nueva biblioteca creada por las mismas personas que hicieron Radix, y shadcn/ui rehízo todos sus componentes para Base UI manteniendo la abstracción existente
  • En diciembre de 2025, npx shadcn create pasó a permitir elegir entre ambas bibliotecas, y en enero de 2026 se completó la documentación de Base UI

Por qué se cambió el valor predeterminado

  • Estabilidad y flujo de uso de Base UI

    • La versión de Base UI es la 1.6.0
    • Tiene más de 6 millones de descargas semanales
    • El equipo de Base UI publica componentes nuevos y útiles con regularidad
    • Los nuevos proyectos de shadcn/ui ya están usando Base UI
    • Los proyectos generados con shadcn/create eligen Base UI sobre Radix en una proporción de 2:1
    • shadcn/ui refleja oficialmente esa tendencia en su configuración predeterminada

Qué cambia en los nuevos proyectos y en la documentación

  • Al ejecutar npx shadcn init en un proyecto nuevo, Base UI será la opción predeterminada
  • shadcn/create mostrará primero Base UI
  • Las páginas de componentes en la documentación se abrirán por defecto en la pestaña de Base UI, y la documentación de Radix seguirá accesible con un clic

Lo que deben saber los usuarios de Radix

  • Radix seguirá recibiendo soporte

    • shadcn/ui mantendrá el soporte para Radix
    • Excepto por los componentes que existen solo en Base UI, todas las actualizaciones y los componentes nuevos estarán disponibles en ambas bibliotecas
    • Las apps existentes no necesitan migrar
    • Radix es una biblioteca madura y probada
    • shadcn/ui también sigue usando Radix en producción y tampoco migrará sus propios proyectos
    • Si prefieres Radix en un proyecto nuevo, puedes usar un flag
    • Si tienes scripts o CI que ejecutan shadcn init de forma no interactiva y esperan Radix, debes agregar -b radix para mantener el flujo anterior
    • Si quieres fijar un registry a una biblioteca específica, puedes usar la configuración registry:base
    • Los elementos sin esa configuración ahora se inicializarán con Base UI
    • Base UI es la opción recomendada para proyectos nuevos

Cómo migrar a Base UI

  • La migración no es obligatoria, pero si quieres puedes usar la skill
  • Puedes pedirle esto a un agente de código
    • migrate accordion to base-ui
  • El enfoque predeterminado es una migración gradual
    • Se migra un componente y sus usos a la vez
    • El proyecto se mantiene en estado green y desplegable en todo momento
    • Durante el proceso, ambas bibliotecas pueden convivir
    • Puedes pausar a mitad del trabajo y retomarlo después
    • Si quieres, también puedes pedir la migración de todo el proyecto de una sola vez

Por qué se eligió una skill en lugar de un codemod

  • Como los componentes de shadcn/ui son código que el usuario posee y modifica, un codemod puede funcionar para componentes no tocados, pero romperse en componentes personalizados
  • La skill incluye revisión manual de cambios de nombres, cambios de props y diferencias de comportamiento entre ambas bibliotecas
  • El agente detecta qué partes modificó el usuario y refleja esos cambios también en la migración
  • Los cambios que pueden hacerse de forma mecánica se aplican en todo el proyecto
    • Ejemplo: asChild pasa a render
  • Los cambios de comportamiento no se parchean silenciosamente: se señalan y la decisión final queda en manos del usuario

Qué deja como resultado la migración

  • Cada ejecución deja tres resultados
    • Código funcional: antes de reportar éxito se ejecutan typecheck y build
    • Reporte por componente: en .migration/ dentro de la raíz del proyecto se dejan los cambios realizados, lo que se dejó intacto y una checklist de verificación manual
    • Historial limpio de git: se deja un commit por componente sobre la rama, y para revertir basta con borrar la rama
  • Un ejemplo de reporte es .migration/accordion.md, que incluye estas secciones
    • Changed
    • Left alone
    • Behavior changes
    • Verify by hand
  • Como el progreso queda registrado en archivos y en el historial de git, sin estado oculto, cualquier agente o sesión puede retomar el trabajo
  • Funciona en agentes que soportan skill, como Claude Code y Cursor
  • En pruebas reales sobre un proyecto, 36 de más de 60 componentes usaban Radix; la migración completa tomó unos 25 minutos y alrededor de 10 mil tokens por componente
  • El build pasó limpio y las personalizaciones se conservaron

Se agregan componentes para interfaces de chat

  • En junio de 2026 se agregaron nuevos componentes para construir interfaces de chat
  • La primera etapa cubre las piezas clave de la capa de conversación
    • scroll
    • filas de mensajes
    • burbujas
    • adjuntos
    • marcadores
  • MessageScroller es un contenedor de scroll para conversaciones
    • anchored turns
    • streamed replies
    • saved thread restore
    • prepended history
    • jump-to-message
    • scroll controls
    • visibility tracking
  • MessageScroller no administra mensajes, estado de IA, envíos, guardado ni estado del modelo; el renderizador de contenido lo provee el usuario
  • MessageScroller también se ofrece como componente headless sin estilos dentro de @shadcn/react

Función de Message, Bubble, Attachment y Marker

  • Message organiza una fila de conversación
    • avatar
    • alineación
    • encabezado
    • contenido
    • pie
    • mensajes agrupados
  • Bubble renderiza la superficie del mensaje
    • variants
    • alineación
    • reactions
    • links
    • buttons
    • contenido colapsable
  • Attachment renderiza archivos e imágenes
    • media
    • metadata
    • upload state
    • actions
    • ofrece un full-card trigger que mantiene acciones separadas y clicables
  • Marker renderiza actualizaciones de estado, notas del sistema, filas divisorias y separadores con etiquetas
    • streaming state
    • tool activity
    • se usa para casos como date breaks
  • Estos componentes están diseñados para ser pequeños y combinables en chat con IA, bandejas de soporte, hilos de equipo, chats grupales e interfaces conversacionales de producto

Utilidades CSS para chat y @shadcn/react

  • Se agregaron dos nuevas utilidades CSS
    • scroll-fade: agrega un fade de indicación de scroll en los bordes del contenedor
    • shimmer: agrega shimmer a textos de estado en vivo como "Thinking…", "Generating response…", ejecución de herramientas o marcadores de streaming
  • Ambas utilidades están incluidas en shadcn/tailwind.css
    • Los proyectos inicializados con npx shadcn@latest init ya las incluyen
  • @shadcn/react es un nuevo paquete para componentes React headless sin estilos
    • Su primer primitive es @shadcn/react/message-scroller
    • Los componentes del registry se envuelven con el estilo de shadcn/ui, pero comportamientos de scroll como anchoring, auto-follow, preservación al prepend, comandos de scroll y visibilidad viven en el paquete
  • Este enfoque entrega comportamiento sin atarlo a un estilo visual y permite probar en un solo lugar la lógica compleja de interacción
  • Se puede usar tanto con Radix como con Base UI

Relación con AI Elements

  • Los nuevos componentes de chat no reemplazan a AI Elements
  • Los componentes y patrones de interfaz de IA de AI Elements siguen siendo utilizables
  • Este lanzamiento se enfoca en llevar una por una las piezas centrales del chat a shadcn/ui
  • Si ya usas componentes de AI Elements, no necesitas reescribir tu app
  • Si necesitas abstracciones más nuevas, estilos actualizados y soporte tanto para Radix como para Base UI, puedes probar la versión de shadcn/ui

Usar repositorios de GitHub como registry

  • Desde junio de 2026, los repositorios públicos de GitHub pueden usarse como registry
  • Si agregas registry.json en la raíz del repositorio y defines qué elementos distribuir, los usuarios podrán instalarlos directamente desde GitHub con el CLI de shadcn
  • El registry de GitHub es un source registry
    • No hace falta ejecutar shadcn build
    • No hace falta publicar archivos JSON de items generados
    • No hace falta configurar un servidor de registry
  • El CLI lee el registry.json de la raíz, resuelve los elementos de include, busca el item solicitado e instala los archivos correspondientes
  • Los items del registry no están limitados a componentes
    • components
    • hooks
    • utilities
    • design tokens
    • feature kits
    • convenciones de proyecto
    • instrucciones para agentes
    • configuración de testing
    • workflows de CI
    • workflows de release
    • templates
    • codemods
    • kits de migración
    • y otros archivos del proyecto
  • Las direcciones de registry de GitHub funcionan con los mismos comandos que los registry existentes
    • list
    • search
    • view
    • install

shadcn eject y shadcn/tailwind.css

  • Al dar soporte a Radix y Base UI al mismo tiempo, se necesitaba un lugar para poner las utilidades compartidas de Tailwind de las que dependen ambas bibliotecas
    • Ejemplo: custom variants como data-open: y data-closed:
    • Ejemplo: utilidades como no-scrollbar
  • También fue más fácil corregir en un solo lugar algunos bugs encontrados durante el trabajo de soporte RTL, en vez de duplicar el arreglo en todos los componentes
  • Para eso se creó shadcn/tailwind.css
    • Al ejecutar init, se agrega @import "shadcn/tailwind.css" al archivo CSS global
    • Funciona como un import de CSS similar a tw-animate-css
    • En producción es una dependencia pequeña que se tree-shakea y se resuelve en build
  • Si no quieres depender del CSS del paquete shadcn, puedes usar shadcn eject
    • Inserta en línea shadcn/tailwind.css dentro del archivo CSS global
    • Elimina la dependencia de shadcn del proyecto
  • En un monorepo, el comando debe ejecutarse desde el workspace que contiene components.json y el archivo CSS global

Nuevo estilo Rhea

  • En mayo de 2026 se agregó el nuevo estilo de shadcn/ui Rhea
  • Rhea es una versión más compacta de Luma, con menor spacing y superficies más densas, pensada para interfaces de producto más enfocadas
  • Rhea mantiene la suavidad y la forma de Luma, pero ajusta botones, inputs, menús, tarjetas y listas de una manera más cerrada
  • No se eligió simplemente ajustar --spacing de Luma
    • Como --spacing es un multiplicador, cambiarlo alteraría en toda la app el significado de utilidades familiares de Tailwind como p-2, w-4 o m-16
  • Rhea se ofrece como un estilo separado, para poder ajustar directamente tamaño de componentes, gaps y densidad, manteniendo predecible la escala subyacente de utilidades
  • Rhea se puede usar en shadcn/create tanto con Radix como con Base UI

1 comentarios

 
GN⁺ 5 시간 전
Opiniones en Hacker News
  • En este texto se siente bastante claro el estilo característico de Claude, y ya me resulta algo cansador y distante.
    Si ni siquiera un anuncio importante de producto merece que una persona le preste atención de principio a fin, no sé dónde habría que trazar la línea.

    • El texto comunicaba eficazmente lo necesario y parecía estar redactado y estructurado de forma agradable para una persona.
      Si lo escribieron con AI y eso les permitió dedicar más tiempo al desarrollo de este excelente software open source, me parece algo positivo.
    • Entiendo exactamente a qué te refieres. Uso mucho Claude y plannotator, y mejoró muchísimo después de pedirle una guía de estilo específica.
      Tomé como prompt inicial “estilo de la referencia de MSDN de la era del CD y del blog de Raymond Chen”, y mi capacidad para digerir planes generados por AI aumentó mucho. Lo recomiendo bastante: es un estilo humilde, perspicaz y respetuoso con el lector.
    • Leí el texto y no me sonó como si lo hubiera escrito AI.
      Sería un poco gracioso si alguien del equipo saliera a decir que lo escribió una persona.
    • Preguntando en serio: no veo por qué eso sería importante. Puede que hayan escrito un borrador y luego revisado y publicado las frases de Claude.
      No entiendo por qué hay que intentar “pillar” a alguien cada vez que la AI ayuda en el trabajo, y esto no es una empresa F500, sino un proyecto open source. Tienen recursos limitados y puede que el inglés no sea su lengua materna.
    • Más bien creo que no es algo de lo que haya que cansarse. La forma en que se usa y se presenta hoy se acerca a la decepción y la mentira.
      Creo que una cultura de colaboración necesita confianza y verdad, y no quiero textos donde una AI diga falsamente “yo hice/dije esto”.
      Por ejemplo, si este texto realmente lo escribió Claude, me pregunto por qué finge que lo dijo directamente alguien del equipo con frases como “I said” o “I meant it”. Eso es suplantación y es engañoso. En una cultura que preserve la colaboración y la honestidad, debería decir “mi humano dijo”, o al menos identificarse correctamente como una AI que actúa en nombre de un humano.
  • Me pregunto si, en aplicaciones aburridas, la gente prefiere el enfoque de copiar y pegar de shadcn antes que librerías de UI tradicionales como Mantine.
    El enfoque de copiar y pegar facilita modificar, pero también crea problemas nuevos. Algo que antes era solo subir un número de versión ahora termina requiriendo un agente de AI para actualizar.

    • Decir que “solo hay que subir un número de versión” subestima muchísimo los dolores de cabeza que Material UI ha causado en los últimos años.
      En una app muy grande, no una app aburrida, cada actualización de versión mayor cambiaba bastante la API y obligaba a migraciones tediosas. Después de pasar a shadcn, se volvió más fácil porque puedo actualizar un solo componente y agregar componentes nuevos libremente. Con Material UI, para usar una función nueva en cualquier parte había que adaptar todo a la nueva API; con shadcn se puede hacer de forma selectiva.
    • Nunca entendí el enfoque de copiar y pegar. Shadcn simplemente huele a moda, y aun copiándolo y usándolo yo mismo no veo qué tiene de extraordinario.
      Aun así, que lo use quien lo disfrute; una de las ventajas de la AI es que HN ya no se atasca tanto como antes con discusiones sobre frameworks de JavaScript.
    • En proyectos nuevos me inclino cada vez más por el vendoring.
      Incorporar una librería de UI ya hecha es fácil a corto plazo, pero por lo general es demasiado compleja, implementa funciones que no vas a usar, es difícil de modificar cuando quieres diferenciarte de las incontables apps que usan la misma librería, y esas modificaciones se rompen de forma sutil al actualizar. Creo que el mejor enfoque es crear tu propia librería de UI. La posees, la reutilizas en varios proyectos, mantienes el mismo estilo visual si quieres y agregas solo las funciones que necesitas.
    • Mantine es excelente. Permite construir casi cualquier cosa rápido y luego ampliar o personalizar por completo el tema y los componentes individuales.
      Tiene una curva de aprendizaje, pero no me parece enorme.
    • En muchos sistemas, en realidad casi nunca es “solo subir el número de versión”. Eso solo funciona cuando la librería de componentes hace exactamente lo que quieres.
      En la práctica, muchas veces el componente no ofrece por completo el comportamiento necesario, y la gente suele agregar CSS adicional encima del componente. Si la alternativa es una tarea de varias horas, dos líneas de CSS son muy tentadoras, pero incluso esas dos líneas hay que validarlas con cada nueva función de la librería de componentes. Cuando se acumulan muchos de estos parches de CSS, actualizar se convierte en un proyecto.
  • Me molesta que estos toolkits populares de UI rendericen divs en exceso.
    Vi Base UI y casi todos los componentes son del tipo “renderiza un elemento”, aunque para un acordeón existen elementos nativos que pueden hacer lo mismo, como details/summary. No soy evangelista de la web nativa, y creo que las APIs web, especialmente HTML, tienen muchas cosas mal, pero abusar de los divs también está mal.

  • Probé Shadcn y en general me gusta, pero los radio buttons basados en Radix me parecieron un poco excesivos. También hay opciones donde se usan soluciones igual de infladas.
    https://news.ycombinator.com/item?id=46688971

  • Es interesante la tendencia de que las tareas de migración pasen de codemod a LLM
    Aunque codemod es más determinista, me pregunto si su era está llegando a su fin

    • Me pregunto qué tal sería usar un LLM para crear un codemod determinista
      Luego se podría ejecutar el codemod, agregar otras salvaguardas deterministas e iterar, y volver a pasar los resultados al LLM para mejorar el codemod
    • El enfoque del artículo original es una forma de pensar peligrosa. El codemod en sí puede estar o no
      Lo que se quiere no es un archivo de skills para LLM, sino documentación para personas. Basta con escribir una guía de migración para personas. Al final, tomará un tiempo darse cuenta de que el archivo de skills y la documentación deberían ser lo mismo
    • Me pregunto qué significa aquí codemod
    • Creo que ambos se complementan perfectamente y lo seguirán haciendo
      Para reglas flexibles sigo usando archivos AGENTS.md, y para reglas fuertes uso reglas personalizadas de linter; creo que así se aprovecha lo mejor de ambos mundos
  • Quiero usar shad-CN, pero siempre termino volviendo a Mantine
    Es mucho más rápido que recordar qué contexto hay que conectar

  • Me pregunto si este cambio les da a los usuarios mejores resultados, como una reducción del tamaño del bundle
    O si es más bien un cambio que mejora la calidad de vida de los mantenedores de Shadcn

  • Me pregunto cuál es el equivalente de shadcn/ui en Angular
    PrimeNG cambió recientemente su licencia, así que estoy buscando una alternativa adecuada para proyectos nuevos

    • Dos intentos[1] de llevar el cambio de licencia de PrimeNG a HN fracasaron, pero si usas las bibliotecas de componentes de PrimeTek deberías conocer este cambio
      PrimeNG, PrimeReact y PrimeVue pasarán a ser completamente de código cerrado, y a partir de 2027 la licencia de uso continuo costará 800 dólares por asiento de desarrollador[2]. Los repositorios existentes serán archivados[3]. PrimeFaces seguirá siendo open source, pero ahora lo desarrollarán y mantendrán desarrolladores voluntarios independientes que no son empleados de PrimeTek
      [1]: https://hn.algolia.com/?q=The+Next+Chapter+of+PrimeTek
      [2]: https://primeui.dev/nextchapter
      [3]: https://github.com/primefaces/primeng
    • Estoy en la misma situación. En el trabajo hemos usado PrimeNG en varias apps, y parece que quedaremos atados a Angular 21 hasta encontrar un reemplazo adecuado
      Dicho eso, un grupo hizo un fork de PrimeNG y dice que planea mantenerlo. El nuevo nombre aún no está definido
      https://github.com/openng-org/open-prime
    • https://spartan.ng/
    • Estoy creando Lily Design System como respuesta a que todavía no existe un sistema similar a Shadcn disponible para usar directamente en varios stacks como Svelte, Angular y Nunchucks
      Todo es gratis y open source, y si envías feedback o sugerencias se pueden agregar fácilmente a Lily
      https://lilydesignsystem.github.io
    • https://www.zardui.com
  • Extraño las antiguas guías de estilo esqueumórficas
    Creo que la última fue Blueprint

  • La URL debería ser https://ui.shadcn.com/docs/changelog/2026-07-base-ui-default