TailwindCSS vs UnoCSS

TailwindCSS y UnoCSS son dos herramientas para la creación de estilos en proyectos web. Ambas ofrecen una serie de utilidades predefinidas que permiten ahorrar tiempo y esfuerzo al momento de escribir código CSS.

TailwindCSS se enfoca en la creación de clases utilitarias que permiten aplicar estilos a elementos HTML de forma rápida y sencilla. Con TailwindCSS, se puede definir el tamaño, el color, la tipografía, los márgenes, el espaciado, entre otros aspectos, simplemente agregando una clase a un elemento HTML. TailwindCSS también permite la personalización de estilos y la creación de clases propias.

UnoCSS, por otro lado, se centra en la creación de componentes y estilos reutilizables. Con UnoCSS, se pueden definir estilos para componentes completos, como botones, formularios, tablas, entre otros. Estos estilos se pueden personalizar y reutilizar en diferentes partes del sitio web.

 

Características

Tailwind tiene nombres de clase para casi todas las características de CSS que se te ocurran, incluidas algunas útiles que quizás no conozcas, como isolation. Incluso para lo que falta, con valores, variantes y propiedades arbitrarias, la mayoría de las aplicaciones se pueden diseñar de pies a cabeza sin un archivo CSS personalizado o complementos.

Uno es compatible con todo Tailwind, además de algunos extras de la caja que realmente aprecio, como grupos de variantes, columnas fluidas con cuadrícula CSS y muchas más animaciones.

Uno también tiene una transformación "attributify" opcional, pero personalmente prefiero que los nombres de mis clases permanezcan en un solo atributo separado de los accesorios. Aunque es una buena idea.

 

El idioma

Tailwind tiene un lenguaje razonablemente bien definido para los nombres de las clases:

• Cada estilo es un nombre en caja de kebab, por ejemplo bg-blue-500, p-4
• Las clases pueden tener el prefijo de una variante, como md:, hover:
• Hay cosas arbitrarias [brackets], con diferencias bien documentadas según el contexto.

No hay especificaciones per se, pero descubrí que es un sistema muy "adivinable". En función de cómo funcionan otros nombres de clase, prueba cosas como grid-cols-[4rem, 1fr, auto]

Por el contrario, el ajuste preestablecido predeterminado de Uno es regex hasta el final. No hay un "lenguaje" real per se, y no hay estandarización, por ejemplo, m4 y m-4 ambos hacen lo mismo.

Esto es intencional por parte de Uno; Uno tiene que ver con la flexibilidad. Pero sigo prefiriendo las barandillas y la metodología obstinada de Tailwind.

Este punto es un tanto discutible, ya que uno realmente usaría el lenguaje de Tailwind con Uno. Eso, y Uno probablemente funcione mejor como un marco para implementar su propio lenguaje encima. De todos modos, esta es mi evaluación si lo estoy viendo y su valor predeterminado como una herramienta de usuario para diseñar aplicaciones.

 

Documentación

Ambos sitios de documentos son hermosos, están bien escritos y son muy útiles. Pero quiero dar un saludo especial a los documentos interactivos de Uno, y el cambio de color de acento es brillante.

 

Estilos personalizados

Aquí hay un ejemplo de un complemento personalizado en Tailwind:

// adds s-* utilities to apply both width and height
plugin(function size(api) {
  api.matchUtilities(
    { s: (value) => ({ width: value, height: value }) },
    { values: api.theme("width") },
  )
}),

Aquí está (casi) lo mismo en Uno:
 

// `s-*` classes to set width and height
[
  /^s-(\d+)$/,
  ([, size]) => ({
    width: `${Number(size) / 4}rem`,
    height: `${Number(size) / 4}rem`,
  }),
  { autocomplete: "s-<num>" },
],

Para ambos, la clase s-4 dará los estilos width: 1rem; height: 1rem.

La API del complemento de Tailwind se ha vuelto mucho mejor a lo largo de los años. Las utilidades simples son fáciles de agregar, e incluso las más complejas, como en este ejemplo, tampoco son tan malas.

Uno hace un uso intensivo de expresiones regulares para utilidades dinámicas, lo que se siente propenso a errores. Uno fomenta la definición de utilidades que pueden tomar cualquier valor que le dé, lo que reduce la necesidad de la [] sintaxis de valor arbitrario. Pero sigo prefiriendo cómo Tailwind te limita a un conjunto específico de valores.

Aparte: la sintaxis de valor arbitrario de Tailwind también le permite usar cualquier valor. Pero los documentos, además de la sintaxis requerida para usarlos, los disuade de usar. Me gusta el centinela claro y forzado de “esto no existe en el sistema de diseño”. Por el contrario, Uno anima
más o menos a los usuarios a usar el valor que quieran. Aunque técnicamente podría construir un sistema de diseño más restringido dentro de Uno, eso es más saltos que los que obtiene con Tailwind.

 

Soporte para editores

El soporte del editor de Tailwind funciona bastante bien, pero tiene algunas lagunas:

• Sin conocimiento de las clases personalizadas en los archivos CSS
• Autocompletará clases en CSS con @apply, pero no autocompletará clases personalizadas de CSS en HTML
• No autocompleta los nombres de clase cuando se usa @apply en complementos
• Debe configurar una opción "experimental" con expresiones regulares personalizadas para obtener contextos de finalización en otro lugar, y debe profundizar en los problemas y discusiones para encontrar la receta que desea. Lo cual aún puede no funcionar en todos los casos, porque... ya sabes, Regex.

Estos problemas hacen que sea tedioso reutilizar estilos, a través @apply o con cadenas de nombres de clase en JS.

Los autores de Tailwind recomiendan no usarlo @applypor completo, pero aún lo encuentro útil para elementos atómicos pequeños, como botones, entradas y enlaces.

Uno resalta los nombres de las clases y brinda sugerencias de color en todas partes, lo cual es bueno si comparte los nombres de las clases en cadenas independientes, pero es divertido ver que resalta la "transición" en const transition = useTransition().

Por extensión, la compatibilidad con el editor de Uno también funciona en uno.config.ts, lo cual es muy bueno para agregar nombres de clase reutilizados personalizados.

Advertencia: debe agregar // @unocss-include en la parte superior del archivo de configuración para que complete los nombres de clase en él. Esto funciona bien con Remix y PostCSS, pero puede fallar en otras configuraciones. TBH, el complemento debería ser compatible con este OOTB

Sin embargo, el autocompletado de Uno es quisquilloso en algunos aspectos:

• A menudo, no obtiene opciones para autocompletar hasta que escribe una utilidad completa y -
• Los accesos directos no siempre se autocompletan, y no está muy claro por qué
• Autocompletar dentro de un grupo de variantes, por ejemplo, hover:(|) no funciona a menos que coloque un espacio en él, como hover:(| )

Aparte de eso, he encontrado que la experiencia general del editor de Uno es más fluida que con el viento de cola.

Tailwind y Uno tienen sus puntos fuertes y débiles. Aprecio mucho las limitaciones de Tailwind y el lenguaje de creación más claro, pero si valoras la flexibilidad y las características adicionales, probablemente te guste Uno. Uno también tiene una experiencia de editor más agradable en general al momento de escribir, ¡pero tal vez eso cambie!