Objeciones al CSS-in-JS

Mantengámonos fieles al estándar CSS

Publicado por Aunitz Giménez el 11 noviembre 2019

Ya he escrito en otras ocasiones sobre Brad Frost. El padre del Atomic Design. Una metodología de referencia para la creación de sistemas de diseño.

En esta ocasión me hago eco de su escepticismo sobre una tecnología muy en boga en el desarrollo front-end: el CSS-in-JS. Un modelo en el que el CSS se compone usando JavaScript en lugar de estar definido en archivos externos.

Objeciones al CSS-in-JS

Coincido con Brad en los tres inconvenientes que observa en las implementaciones de CSS-in-JS. Los he encontrado en proyectos en los que he participado como mánager o consultor; además de alguno más.

  • Falta de portabilidad. Un sistema de diseño potente y complejo debería ser portable a cualquier tecnología de front-end. Los CSS-in-JS sólo funcionan con tecnologías muy concretas basadas en JavaScript y no pueden ser exportados a proyectos basados en otras tecnologías como pueden ser CMS como WordPress o Liferay.
  • Mezcla de contextos. No me parece adecuado mezclar en un mismo fichero la funcionalidad y su presentación. Resulta un archivo abarrotado y que mezcla especialidades que suelen dominar diferentes perfiles de desarrollador. Un especialista en CSS es raro que domine JavaScript y viceversa. Incluso en el caso de que se trate de un profesional que se desenvuelve en ambos campos con soltura, estará acoplando en un mismo lugar competencias diferentes.
    En este punto cabe decir que hay frameworks como Vue.js que resuelven esta mezcla con más elegancia que otros. Creando espacios reservados para el marcado, el estilo y la funcionalidad.
  • Tendencia a las malas prácticas CSS. Quizá sea por esa mezcla de contextos que comentaba en el punto anterior, quizá por falta de especialización y conocimiento profundo de la tecnología CSS, pero lo cierto es que es habitual encontrarse con abundancia de malas prácticas CSS en los proyectos que utilizan CSS-in-JS.
  • Falta de fidelidad al estándar. El estándar de CSS que define la W3C recomienda la separación del HTML, el CSS y el JS. Y el uso de hojas de estilo externas para los CSS. Las ventajas son múltiples: eficiencia del código, facilidad de mantenimiento, accesibilidad, compatibilidad con los diferentes dispositivos, compatibilidad con los buscadores.

Entrando en un plano más de detalle técnico, resulta muy interesante el podcast de Chris Ferdinandi en el que cuestiona las objeciones que Christopher Chedeu le hace al uso de CSS estándar en proyectos de gran escala. En este sentido, Chris Ferdinandi opina que muchos desarrolladores JavaScript juzgan el CSS por las mismas reglas que el JavaScript. Algo que, sencillamente, no es correcto. Ya que se trata de lenguajes completamente diferentes y que sirven a propósitos muy distintos.

Un caso típico es la crítica que algunos desarrolladores JavaScript hacen al alcance global por defecto de las reglas de CSS. Comparándolo directamente con la clásica buena práctica de JavaScript de no utilizar variables globales. Sin embargo, el CSS no es un lenguaje de programación y no puede evaluarse de la misma manera que se hace con el JavaScript. El alcance global de las reglas y la cascada no son errores del CSS, son características intrínsecas de este lenguaje. Características que permiten escribir menos código y crear archivos que son mucho más pequeños y de mayor rendimiento, si se sabe cómo aprovecharlas.