Dos pasos adelante, un paso atrás

Brent Jackson dice que las bibliotecas de utilidades CSS fallaron un poco:

Con el tiempo, necesitarás agregar estilos únicos que simplemente no están cubiertos por la biblioteca que estás usando, y no siempre hay una manera clara de ampliar lo que estás trabajando. Sin una forma clara de manejar cosas como esta, los desarrolladores tienden a agregar trucos inconsistentes y estilos de solo agregar.

Tengo la sensación de que la gente de Tailwind no estaría de acuerdo. No tengo una opinión particular aquí, sólo estoy señalando que Tailwind parece tener una base de fans más ferviente que aquellos primeros días de Basscss / Tachyons .

Brent continúa diciendo que CSS-in-JS resuelve el mismo problema, pero de mejor manera:

Las bibliotecas CSS-in-JS ayudan a resolver muchos de los mismos problemas en los que se centraban las metodologías CSS basadas en utilidades (y más) de una manera mucho mejor. Conectan estilos directamente a elementos sin necesidad de nombrar cosas o crear abstracciones en selectores de clases. Evitan hojas de estilo de solo agregar con encapsulación y nombres de clases con hash. Estas bibliotecas funcionan con herramientas de compilación existentes, lo que permite la división de código, la carga diferida y la eliminación de código muerto prácticamente sin esfuerzo y no requieren herramientas adicionales como Sass o PostCSS. Muchas bibliotecas también incluyen optimizaciones de rendimiento de CSS, como CSS crítico , habilitado de forma predeterminada para que los desarrolladores no necesiten herramientas adicionales ni siquiera pensar en ellas.

No es de extrañar que la gente haya estado entusiasmada con esto.

El paso atrás se refiere al hecho de que CSS-in-JS es más abierto y no fomenta tanto la coherencia. No estoy seguro de eso. Parece que si ya estás construyendo de forma basada en componentes, la coherencia viene incluida, incluso antes de usar tokens de diseño y similares, lo que también fomenta un enfoque CSS-in-JS.

Enlace directo →