Lanzamiento de Tailwind CSS v4.0

 (tailwindcss.com)
1 puntos por GN⁺ 2025-01-24 | 1 comentarios | Compartir por WhatsApp
  • Tailwind CSS v4.0 es una versión en la que el framework fue reescrito desde cero, con una mejora importante en el rendimiento de compilación y un flujo de configuración y personalización más centrado en CSS
  • Según Catalyst, las compilaciones completas pasaron de 378 ms en v3.4 a 100 ms en v4.0, es decir 3.78 veces más rápidas; las compilaciones incrementales sin CSS nuevo mejoraron de 35 ms a 192 µs, una mejora de 182 veces
  • La instalación se simplificó a una sola línea, @import "tailwindcss", y valores predeterminados sin configuración; quienes usen Vite pueden usar @tailwindcss/vite en lugar de PostCSS
  • v4.0 aprovecha funciones modernas de CSS como cascade layers, @property, color-mix() y logical properties, e introduce detección automática de contenido y manejo integrado de @import
  • Container queries, 3D transform, una API de gradient ampliada, @starting-style, not-*, field-sizing, color-scheme, inert y más pasan a ser funciones del core, reduciendo la dependencia de plugins separados

Motor de alto rendimiento reescrito desde cero

  • Tailwind CSS v4.0 es una versión que reescribe desde cero el framework, basada en años de experiencia de arquitectura
  • En benchmarks de sus propios proyectos, las recompilaciones completas son más de 3.5 veces más rápidas y las compilaciones incrementales más de 8 veces más rápidas
  • Según Catalyst, los tiempos medianos de compilación son los siguientes
    • Compilación completa: v3.4 378 ms → v4.0 100 ms, mejora de 3.78 veces
    • Recompilación incremental con CSS nuevo: 44 ms → 5 ms, mejora de 8.8 veces
    • Recompilación incremental sin CSS nuevo: 35 ms → 192 µs, mejora de 182 veces
  • Las compilaciones incrementales que no necesitan compilar CSS nuevo son más de 100 veces más rápidas y se completan en el orden de los microsegundos
    • Cuanto más tiempo trabajas en un proyecto, más común es reutilizar clases que ya usaste, como flex, col-span-2 o font-bold, por lo que te encuentras con este tipo de compilaciones con frecuencia

Aprovechamiento de la plataforma CSS moderna

  • v4.0 aprovecha de forma activa las funciones de la plataforma web que han evolucionado desde Tailwind CSS v3.0
  • Las principales funciones base de CSS son las siguientes
    • Native cascade layers: permiten controlar con más detalle cómo interactúan entre sí distintas reglas de estilo
    • Registered custom properties: habilitan animaciones de gradients y mejoran mucho el rendimiento en páginas grandes
    • color-mix(): permite ajustar la opacidad de cualquier valor de color, incluidas variables CSS y currentColor
    • Logical properties: simplifican el soporte RTL y reducen el tamaño del CSS generado
  • Estas funciones también simplifican la implementación interna de Tailwind, reducen la superficie de bugs y facilitan el mantenimiento

Instalación e integración de build más simples

  • El flujo de instalación se reorganizó para reducir pasos y boilerplate
    • npm i tailwindcss @tailwindcss/postcss
    • Agregar @tailwindcss/postcss al plugin de PostCSS
    • Usar @import "tailwindcss" en el archivo CSS
  • En v4.0, Tailwind puede importarse y usarse con una sola línea de CSS en lugar de las directivas @tailwind
  • Ofrece un flujo sin configuración para empezar sin ninguna configuración, incluidas las rutas de archivos de templates
  • Sin plugins externos separados, bundlea reglas @import y usa internamente Lightning CSS para vendor prefixing y conversión de sintaxis moderna
  • Quienes usen Vite pueden elegir @tailwindcss/vite en lugar de PostCSS
    • Tailwind CSS v4.0 también es rápido como plugin de PostCSS, pero el plugin de Vite permite obtener mejor rendimiento

Detección automática de contenido e import integrado

  • La configuración del array content que se necesitaba en v3 fue reemplazada en v4.0 por heurísticas de detección automática
  • Los elementos en .gitignore se ignoran automáticamente, evitando escanear dependencias o archivos generados no versionados
    • Ejemplos: /node_modules, /coverage, /.next, /build
  • También se ignoran automáticamente extensiones binarias como imágenes, videos y .zip
  • Cuando haga falta agregar explícitamente fuentes que se excluyen por defecto, se puede usar la directiva @source dentro del archivo CSS
    • @source "../node_modules/@my-company/ui-lib";
    • @source también usa las mismas heurísticas, por lo que los tipos de archivo binarios se excluyen sin tener que especificar extensiones aparte
  • Antes de v4.0, para inlinear otros archivos CSS con @import hacía falta un plugin separado como postcss-import, pero ahora no se necesitan otras herramientas gracias al soporte integrado de import
    • El sistema de import fue creado específicamente para Tailwind CSS y está estrechamente integrado con el motor, por lo que funciona más rápido

Configuración CSS-first y theme variables

  • Uno de los grandes cambios de v4.0 es que la configuración del proyecto se hace directamente en CSS en lugar de JavaScript
  • En vez de un archivo tailwind.config.js, se puede personalizar con @theme dentro del archivo CSS que importa Tailwind
    • Configuración de design tokens
    • Definición de utilities personalizadas
    • Definición de variants personalizadas
  • Los design tokens definidos en @theme se exponen por defecto como variables CSS
    • Ejemplos: --font-display, --breakpoint-3xl, --color-avocado-500, --ease-fluid
  • Las variables CSS generadas así pueden referenciarse en runtime como CSS normal
    • Reutilización en estilos inline
    • Pasarlas a librerías como Motion para manejar animaciones

Valores dinámicos de utilities y variants

  • v4.0 simplifica varias utilities y variants para que acepten valores arbitrarios específicos sin configuración
  • En grids, se puede usar el tamaño que quieras sin configuración separada
    • Ejemplo: grid grid-cols-15
  • También se pueden apuntar custom boolean data attributes sin definirlos previamente
    • Ejemplo: data-current:opacity-100
  • Las utilities de spacing como px-*, mt-*, w-* y h-* se derivan dinámicamente desde una única variable de spacing scale
    • Ejemplo: --spacing: 0.25rem
    • w-17 se genera como calc(var(--spacing) * 17)
  • La herramienta de upgrade lanzada junto con v4.0 simplifica automáticamente, en la mayoría de los casos, la sintaxis de valores arbitrarios que ya no es necesaria cuando la detecta

Paleta de colores y container queries

  • Toda la paleta de colores predeterminada se actualizó de rgb a oklch
    • Sale de las limitaciones del espacio de color sRGB y aprovecha un gamut más amplio para lograr colores más vivos
    • Como se intentó mantener el equilibrio entre colores de v3, no debería sentirse como un breaking change al actualizar proyectos existentes
  • El soporte para container queries entró al core en v4.0, por lo que ya no hace falta el plugin @tailwindcss/container-queries
  • Con la nueva variant @max-* se pueden usar container queries de max-width
  • Como con las variants de breakpoints normales, se pueden apilar @min-* y @max-* para definir rangos de container queries

3D transform y API de gradient ampliada

  • v4.0 agrega una API para 3D transform
    • rotate-x-*
    • rotate-y-*
    • scale-z-*
    • translate-z-*
  • También se ampliaron las funciones de gradient, permitiendo crear más efectos sin CSS personalizado
  • Los gradients lineales pueden recibir ángulos como valores
    • Ejemplo: bg-linear-45
    • El nombre de los antiguos bg-gradient-* cambió a bg-linear-*
  • El modo de interpolación de colores del gradient puede controlarse con modifiers
    • bg-linear-to-r/srgb
    • bg-linear-to-r/oklch
    • La interpolación predeterminada de v4.0 es OKLAB, y también pueden usarse modifiers de otros espacios de color
  • Con las nuevas utilities bg-conic-* y bg-radial-* se pueden crear conic y radial gradients
    • Funcionan junto con los from-*, via-* y to-* existentes
    • Incluyen soporte para modifiers que configuran el método de interpolación de colores y para valores arbitrarios que permiten controlar detalles como la posición del gradient

Nuevas variants y utilities

  • La nueva variant starting soporta CSS @starting-style
    • Permite crear transiciones de propiedades cuando un elemento se muestra por primera vez
    • Permite animar elementos que aparecen en la página sin JavaScript
    • El soporte de navegadores quizá todavía no sea suficiente para la mayoría de los equipos, pero se está acercando
  • La nueva variant not-* soporta la pseudo-class CSS :not()
    • Ejemplo: not-hover:opacity-75
    • También permite negar media queries y queries @supports
  • En v4.0 también se agregaron las siguientes utilities y variants
    • inset-shadow-*, inset-ring-*: permiten apilar hasta 4 capas de box shadow en un solo elemento
    • field-sizing: soporta el ajuste automático de tamaño de textarea sin JavaScript
    • color-scheme: permite eliminar scrollbars claros en dark mode
    • font-stretch: ajusta variable fonts que soportan distintos anchos
    • inert: permite estilizar elementos no interactivos marcados con el atributo inert
    • nth-*: soporta estilos de la familia nth
    • in-*: funciona de forma similar a group-* sin la clase group
    • :popover-open: también apunta a popovers abiertos con la variant open existente
    • descendant variant: estiliza todos los elementos descendientes

Cómo empezar y ruta de upgrade

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-01-24
Comentarios de Hacker News

  • En algún momento critiqué duramente varios defectos de Tailwind y su incompatibilidad con enfoques web modernos y realmente “puros”, pero el gran avance de v4 es muy bienvenido
    Poder acceder al tema de Tailwind como variables CSS nativas, e incluso ver en la documentación un ejemplo de componente de botón escrito en variables nativas desde una hoja de estilo externa, es un cambio enorme
    Que también se pueda configurar solo con CSS es excelente, y ahora Tailwind se siente menos como un framework “viral” al estilo JavaScript que se traga arquitecturas razonables, y más como una utilidad que puedes agregar a cualquier proyecto
    Ya sea que las críticas de los últimos años hayan surtido efecto o que hayan llegado por su cuenta a una buena conclusión, gran parte del debate a favor o en contra de Tailwind ahora parece menos relevante, y eso es algo muy bueno. Ahora se puede enfocar uno en crear productos

    • En el uso práctico sigo siendo crítico, pero sorprende lo bien que Tailwind encaja en flujos de trabajo generados por IA
      Como se puede expresar cualquier cosa de forma sistemática, funciona realmente bien, y hay algo muy útil en eso
    • Me cuesta estar de acuerdo con que el debate a favor o en contra de Tailwind ya no sea relevante, y como diseñador/ingeniero de diseño veo dos problemas
      Primero, los ingenieros de JavaScript/Tailwind han terminado dominando la conversación sobre diseño. Más que “utility-first”, “eliminación de código no usado” o “CSS type-safe”, prefiero enfocarme en sistemas de diseño, por ejemplo cuestiones como si en tipografía conviene usar Perfect Fifth o Perfect Fourth
      Segundo, Tailwind dificulta participar en el proceso real de producción. Las decisiones de diseño quedan enterradas dentro de expresiones crípticas de componentes React como flex items-center shadow-lg p-6 hover:bg-gray-50 dark:bg-gray-800 py-[calc(theme(spacing[2.5])-1px)]
      Puede ser comprensible para un ingeniero de JavaScript, pero se vuelve una barrera para un diseño sistemático. En vez de expresar relaciones matemáticas precisas con CSS, termina usándose un estilo inline más cómodo
    • Solo quiero la paleta de colores de Tailwind CSS

  • CSS se ha vuelto mucho más fácil de usar que antes, y la mayoría de los navegadores ahora también se comportan de forma consistente
    Vale la pena aprenderlo porque no requiere una etapa de build ni ensucia el marcado con código excesivo
    También se puede escribir directamente el atributo style en HTML, algo que antes se evitaba por la separación de responsabilidades. Por eso desconcierta que se quiera reintroducir algo parecido. Dan ganas de pensar que es solo para ahorrar unos cuantos caracteres
    El atributo style incluso parece más intuitivo porque no hace falta transformar mentalmente el código. No le veo mucho atractivo

    • Hay bastantes cosas que no se pueden hacer con el atributo style. Por ejemplo, las pseudoclases :hover, :focus, los pseudoelementos ::before, ::after, media queries, keyframes y animaciones
      Tampoco ofrece una buena experiencia de desarrollo en proyectos grandes
      En cambio, @scope, que pronto será estándar, es una muy buena incorporación para mantener los estilos cerca de donde se usan: https://developer.mozilla.org/en-US/docs/Web/CSS/@scope
    • Hoy en día Tailwind suele usarse junto con un sistema de abstracción de componentes que actúa como una capa de abstracción en lugar de clases CSS
      La abstracción por componentes separa aún más el significado y el estilo. En ambos casos hay que buscar la abstracción “hero”, pero en el mundo de componentes se abstrae no solo el estilo sino también los nombres de las etiquetas HTML
      En cualquier caso, los “detalles de estilo” quedan separados del “contenido” en los archivos fuente de la página. Puede valer la pena aceptar una etapa de build por una mejor separación de responsabilidades, es decir, una mejor separación entre contenido y presentación
    • El atractivo está en que no hace falta poner nombres a clases CSS, está junto al HTML y por eso es fácil de leer, y la forma de nombrar está estandarizada, así que se usan las mismas reglas en todas partes
      También reduce la necesidad de mantener archivos separados y de eliminar componentes que no se usan
      Permite usar media queries, algo que no podías hacer con una etiqueta style, y no corres el riesgo de cambiar clases que se usan en otros lugares. El scope global de CSS tiene ventajas, pero también es riesgoso
    • Es el resultado de haber normalizado demasiado su fuerte acoplamiento con React
      Se asume que los estilos pertenecen a los componentes y no al sistema de diseño. Al ecosistema de ingeniería centrado en JavaScript le hacen falta más empresas guiadas por diseño que conozcan el poder del CSS moderno y del diseño sistemático
    • Cuando ves la cantidad de archivos que hay que manejar en proyectos grandes, Tailwind se vuelve bastante atractivo
      El enfoque normal con .css genera nombres extraños, duplicación y posibles conflictos. css modules también es una opción, pero en la práctica casi duplica la cantidad de archivos por componente/página
      sass o less se sienten como una mezcla de los problemas de css modules y del .css normal
      No es que me guste o me disguste Tailwind en esencia; al principio lo odiaba muchísimo, pero en proyectos de más de 200 archivos compuestos por componentes y páginas sí se le ve valor

  • Mi primera reacción a Tailwind fue: “qué fastidio”. Ya sabía CSS, y sentía que ahora tenía que volver a aprender CSS
    Se parece a cuando un padre intenta ayudar a su hijo con la tarea de matemáticas y resulta que la forma en que enseñan en la escuela ahora es completamente distinta; tu método sigue siendo correcto, pero no lo aceptan, y el niño se frustra tratando de reconciliar ambos sistemas
    Entiendo la idea de que, si funciona bien en equipo y escala bien, simplemente hay que usarlo, y también lo he vivido
    Aun así, sigo prefiriendo las hojas de estilo normales orientadas a clases o etiquetas. Más aún ahora que CSS ya soporta selectores anidados
    Sí hay un problema de gestión de hojas de estilo, y me gusta el enfoque de definir y aplicar archivos CSS a nivel de ruta, como en Remix/React Router. Si eso no alcanza, o si los estilos dinámicos se vuelven demasiado complejos para un archivo .css, siempre está la opción de style={{...}}
    CSS es potente, flexible y escalable, así que Tailwind no me parece una mejora, sino una restricción. No entiendo bien por qué sigue siendo tan popular, pero creo que en 3 o 4 años todos se habrán pasado a otra cosa

    • Al principio también me frustraba sentir que estaba reaprendiendo CSS, y antes sostenía exactamente lo mismo
      Pero me fui acostumbrando al contribuir a proyectos open source que usan Tailwind, y ahora lo veo distinto
      Tailwind es, en esencia, una especie de taquigrafía para style={{…}}. Algo que en un archivo .css o en un objeto de estilos requeriría varias líneas, con una utility te queda resuelto en unos 15 caracteres
      He reducido muchísimo el tiempo que antes pasaba buscando cosas como “visual text replacement css”, revisando chuletas de CSS o escarbando en algún artículo de CSS-Tricks de hace 8 años. En cambio, ahora casi siempre voy a la documentación de Tailwind y encuentro rápido la clase utility para hacer lo que quiero
      Sorprendentemente, muchas cosas se me quedan en la memoria, y se siente mucho mejor que intentar memorizar todo el CSS necesario para trabajar layouts
    • Creo que es porque ahora el componente completo queda dentro de un solo archivo
      No hace falta tocar CSS por separado, y los estilos están justo encima del elemento al que se aplican, así que no necesitas ir comparando entre ambos
      Técnicamente también se puede lograr solo con la prop css, pero el problema es que a todo el mundo le enseñaron que eso está mal, y además una lista de strings con varias utilities puede ser más fácil de manejar que usar objetos CSS puros
    • Las restricciones reducen la complejidad posible, y por eso Tailwind gana
      Es un gran avance como wrapper modular, estandarizado y componible encima de un sistema enorme y complejo
    • Estoy enseñándole matemáticas a mi hijo, y no son distintas de como yo las aprendí; todavía puedo resolverlas rápido
      En cambio, en redes sociales sí ves publicaciones donde mezclan multiplicación y división y dicen que solo hay una respuesta correcta. Tailwind no llega a ser tan malo, pero desde la perspectiva de alguien ya mayor, me parece que va más en esa dirección

  • Me gusta Tailwind. Lo he usado en 3 proyectos durante los últimos 4 años, y me ha parecido intuitivo, bien documentado y simple
    No extraño la época de emotion y styled-components, cuando había que ponerle nombre a cada div con estilos del proyecto
    En Tailwind, un contenedor es simplemente un div con unas cuantas clases. Hay menos debates sobre nombres, y se gasta menos energía mental y menos tiempo de revisión en nombrar cosas

    • Veo muy seguido el argumento de que hay que pensar el nombre de cada div con estilos, y la verdad me resulta un poco extraño
      Casi nunca he pasado más de un segundo pensando cómo nombrar algo. ¿De verdad para algunas personas ese es el punto donde se traban? Me intriga si realmente puede llegar a paralizarlas
    • Si dices “unas cuantas clases”, suena a que trabajas con un product manager realmente bueno
      La gente con la que yo he trabajado solía especificar todos los detalles posibles hasta el infinito. Trataban un formulario web como si fuera su propia remodelación personal estilo HGTV
      La vez que probé Tailwind, terminé con una cantidad de clases de un dígito por encima del propio markup, y enseguida se volvió difícil de leer
    • Lo he usado en varios proyectos, pero no me gustó. En proyectos grandes se desordena rápido, y se siente como el nuevo Bootstrap
      Ahora estoy conforme con un workflow de CSS-in-JS. Es una forma vieja de escribir CSS, pero con ayuda de LLM. Le muestras una imagen al LLM, le pides un componente, y te lo devuelve ya con nombres apropiados
    • Si pudiera elegir, esta es una de las razones principales por las que evitaría React
      El estilado en React no me convence, y aunque uses Tailwind, solo es la opción menos mala
      Si vas a usar un framework de frontend y un paso de build, entonces Svelte y Astro me parecen buenas opciones según el caso. Puedes estilarlos con CSS normal, y si mantienes los componentes pequeños, casi no necesitas usar nombres de clases
      Basta con usar selectores de elementos y dejar que el framework haga el scope de estilos en build time

  • Probé Tailwind en mi sitio y me gustó bastante, aunque quizá por razones un poco distintas a las que suele mencionar la gente
    El verdadero valor de Tailwind está en que puedes leer en un solo lugar todos los estilos que afectan a un elemento
    Los nombres de clase pueden alargarse, sí, pero leer una sola línea larga sigue siendo mucho más rápido que abrir las herramientas de desarrollador del navegador cada vez o estar yendo y viniendo entre una o varias hojas de estilo
    Incluso cuando vuelves a ese código más adelante, puedes modificarlo con confianza sin preocuparte de cambiar accidentalmente otros elementos
    La naturaleza en cascada de CSS sigue siendo útil, pero por lo general quieres limitar los estilos a un solo elemento. Para lo demás vuelves a CSS, aunque en la práctica escribes muy poco CSS. Normalmente solo quieres ajustar los espacios

    • Justamente por eso creo que Tailwind es bueno y cómodo
      También me gusta que la pregunta “¿cómo hago X?” no se convierta en una investigación de 30 minutos, sino en una búsqueda rápida en la documentación
    • También hay herramientas en los IDE que te muestran todos los estilos aplicados a un elemento. Por ejemplo, “Show Applied Styles for Tag” en Intellij, o también Chrome DevTools, donde se ve de forma bastante legible
      Comparados con eso, los fragmentos de Tailwind que aparecen en este hilo de HN se ven bastante aterradores
    • Estoy de acuerdo hasta cierto punto, pero sigue quedando el mismo problema
      Si agregas text-xl a un div y dentro tiene otros div y span anidados, todos heredarán text-xl, así que para ver qué está provocando ese text-xl en un elemento anidado, al final igual tienes que remontarte por toda la jerarquía de elementos
      Aun así, en general sí es un poco más fácil

  • Frases como “tiempos de build más cortos”, “ya no hay directiva @tailwind”, “sin configuración de JavaScript” y “diseñado para la web moderna” suenan a esto
    CSS ahora ya puede hacer todo lo que antes hacíamos nosotros, pero igual sigamos fingiendo que todavía nos necesitan

    • Si lo vas a odiar, al menos deberías intentar entender qué es y por qué la gente lo usa
    • El punto de venta de Tailwind, desde el principio, fue “es casi CSS inline, pero menos engorroso que el atributo style y mucho más fácil de optimizar”
    • Me pregunto qué era eso para lo que antes se necesitaba Tailwind y no se podía hacer con CSS normal
      ¿Tailwind no corresponde casi 1:1 con CSS?
    • De verdad me sorprende que lo hayas entendido así
      Entiendo que no te guste Tailwind, pero me parece mejor decir qué es exactamente lo que no te gusta en vez de atacar un hombre de paja
      Tampoco está bien menospreciar el proyecto open source de otra gente ni a quienes lo usan de forma útil

  • Quiero preguntarle a gente que sí sepa bien de CSS. Yo no sé mucho
    Estoy actualizando un proyecto personal de Phoenix a 1.7, y como Phoenix ahora usa Tailwind por defecto, quise probarlo en lugar de Bootstrap
    Hasta ahora, la versión con Bootstrap se veía “más o menos bien”, pero la versión con Tailwind se ve desastrosa
    ¿Cuál es la forma más fácil de obtener estilos por defecto que se vean bien sin tener que convertirme en diseñador? ¿O simplemente debería volver a instalar Bootstrap y listo?

    • En ese caso, yo volvería a instalar Bootstrap
      Tailwind te da herramientas cuando quieres controlar el diseño, pero al final tienes que controlar tú mismo el diseño
      Si lo único que quieres es que se vea bien y además tenga ese estilo tipo Bootstrap, entonces Bootstrap es la opción correcta
      En teoría hay proyectos que reimplementan Bootstrap sobre Tailwind, así que podrían darte un punto de partida tipo Bootstrap junto con la potencia de Tailwind, pero en la práctica no he visto que funcionen mejor que simplemente usar Bootstrap
    • Para ese propósito uso DaisyUI. Aquí está el sitio demo de ejemplo: https://nwk-landing-kit.netlify.app
      La documentación de DaisyUI está aquí: https://daisyui.com
    • Si buscas componentes tipo Bootstrap, vale la pena probar gratis https://flowbite.com/
      También hay componentes de pago para Tailwind, y solo hay que copiarlos y pegarlos. Lo bueno es que, una vez que te acostumbras, puedes ir modificando poco a poco los componentes de Flowbite
    • Depende de quién esté pagando
      Si tienes estabilidad laboral y quieres experimentar con cosas, puedes jugar con Tailwind. La gente más ruidosa y pendiente de las modas parece preferir Tailwind
      Pero si es tu propio proyecto, lo financias tú o tienes una fecha límite, conviene más usar Bootstrap, que ya conoces, y concentrarte en terminar el trabajo en vez de desgastarte peleando con la UI
    • Tailwind y Bootstrap se parecen más a comparar manzanas con pay de manzana
      Tailwind te da las clases que tienes que ir apilando para crear componentes
      Seguro sería más fácil si lo usas junto con código fuente de componentes UI. Hace tiempo usé TailwindUI, pero era de pago; imagino que también habrá buenas alternativas gratuitas

  • Hay un patrón muy claro en las conversaciones de “Tailwind sí o no”. Se repite cada vez que se menciona Tailwind
    Están los que nunca lo han usado bien por más de 30 minutos, apenas lo probaron un poco o solo revisaron la documentación. Esos odian Tailwind y prefieren cosas como “CSS puro”
    Y están los que sí lo han usado en proyectos reales, dentro de equipos de más de una persona. Esos entienden su valor, aceptan los trade-offs y les gusta
    He visto a mucha gente pasar del primer grupo al segundo, pero casi nunca del segundo al primero
    Por eso Tailwind ha tenido éxito. Puede que no sea bonito para los puristas, pero para la gente que construye cosas y para los pragmáticos es realmente excelente

    • Yo diría que no encajo bien en ninguno de esos dos grupos
      No estoy en contra de Tailwind, pero todavía no lo he usado porque no me queda claro por qué sería un enfoque mejor que otras opciones como Web Components o React Styled Components
      Mi mayor problema es que Tailwind llena el HTML de montones de clases utilitarias, lo que hace más difícil leerlo y mantenerlo
      Entiendo que es mejor que tener un archivo CSS global enorme y CSS clásico basado en nombres de etiquetas, pero ya existen formas de usar CSS con alcance al componente sin contaminar el espacio de nombres global. Web Components y Styled Components son ejemplos de eso
      Ambos vinculan los estilos directamente al componente o, más en general, a un conjunto específico de etiquetas HTML, así que es fácil ver qué estilos se aplican y dónde
      Tampoco hacen falta nombres de clase globales, y hay menos preocupación por efectos secundarios no deseados o conflictos. Si eliminas el componente, también eliminas los estilos asociados, así que no queda CSS sin usar. Gracias al shadow DOM, también se reduce el riesgo de que los estilos de un componente afecten accidentalmente a otro
      Para mí es importante no mezclar estilos de presentación directamente en el marcado, para que el HTML siga siendo corto y fácil de leer. Cuando, como en Tailwind, todos los estilos van en el atributo class, terminas con listas larguísimas de clases por línea, y si además tienes que escribir también nombres de clase reales, el HTML se vuelve desordenado
      Cuesta ver de un vistazo qué estilos se están aplicando, y hasta es difícil indentarlo bien. Me recuerda varias de las razones por las que antes nos alejamos del atributo inline style en HTML
      No odio Tailwind, pero no veo ventajas claras frente a Web Components o Styled Components en términos de legibilidad, mantenibilidad y separación de responsabilidades, y sigo teniendo preocupaciones que nadie me ha respondido
      He leído la documentación, pero no lo he usado, y me cuesta entender por qué elegir Tailwind en lugar de otras opciones. El hecho de que la cantidad de clases explote en medio de HTML común hace que, para mí, ambas cosas sean difíciles de leer

  • Reconozco que hay gente que usa Tailwind de forma útil y productiva, pero ahora que Tailwind está en todas partes, se ve por todos lados una apariencia limpia pero común

    • Esto confunde Tailwind con TailwindUI/shadcn.
      En general, Tailwind no influye mucho más en el estilo que el CSS normal. Hay algunas excepciones. Cosas como las sombras están un poco más estandarizadas, y la paleta de colores indigo ha influido algo incluso fuera de ese ecosistema últimamente
    • Tailwind da valores predeterminados razonables, pero no influye mucho en el diseño.
      Simplemente la gente tiende a diseñar sitios de cierta manera, especialmente cuando lo usa junto con shadcn
    • Más bien, se siente como algo bueno. Las opciones de Tailwind están bien diseñadas y funcionan bien.
      Lo veo parecido a cómo Inter se usa como fuente para sitios web, como si fuera la nueva Helvetica. Si mucha gente la usa y se ve bien, no veo por qué habría que evitarla
    • Antes también escuché lo mismo sobre Bootstrap, pero los sitios que hice con Bootstrap no se parecían entre sí.
      Bootstrap ofrecía muchas clases utilitarias desde mucho antes que Tailwind, lo que ahorraba mucho tiempo y no imponía una apariencia específica.
      Bastaba con importar solo las clases que querías. Claro, si no descargabas los archivos fuente de Sass, la historia era otra, pero eso habría sido una decisión tonta
    • Mi opinión sobre este problema es que todavía hay pocos buenos frameworks de UI, es decir, combinaciones de Tailwind y componentes.
      Por eso, la mayoría de los proyectos usan un número muy pequeño de frameworks. Si aparecieran 4 o 5 proyectos de UI más de buena calidad, y sobre todo con direcciones de estilo más distintas, aumentaría la diversidad.
      Parece que el diseño, como muchos trabajos creativos, tiene un número sorprendentemente pequeño de personas marcando la tendencia.
      Ojalá más gente supiera esto. Creo que hay personas con talento que no crean nada porque piensan: “aunque yo lo haga, nadie me va a escuchar”.
      Pero si algunas de esas personas lo intentaran, podrían abrir una nueva UI para una gran parte de la web

  • Tailwind es una prueba de las ventajas de los estilos inline, es decir, esa forma de estilizar algo sin ponerle nombre, de la universalidad de las cadenas de texto y también de sus límites.
    Tengo curiosidad por ver qué viene después y, hasta entonces, usaré Tailwind a regañadientes