Algunas personas odian la idea de CSS-in-JS. Solo ese nombre es ofensivo. Difícil no. El estilo no pertenece a JavaScript, pertenece a CSS, algo que ya existe y que los navegadores están optimizados para usar. Separación de intereses. Cualquier otra cosa es un paso en falso ridículo, una señal de no aprender de los errores del pasado (como el <font> etiqueta y tal.)
A algunas personas les encanta la idea de CSS-in-JS. La ubicación conjunta de las plantillas y la funcionalidad, como la mayoría de los marcos de JavaScript, les ha demostrado ser exitosas, por lo que incluir estilos parece un ajuste natural. Los componentes de un solo archivo de Vue son un arquetipo aquí.
(Aquí hay un video sobre CSS-in-JS que hice con Dustin Schau si necesita una cartilla).
Brent Jackson cree que definitivamente deberías aprenderlo, pero también ofrece algunos puntos pragmáticos sobre lo que hace y lo que no hace:
¿Qué hace CSS-in-JS?
- Le permite crear CSS en sintaxis de JavaScript
- Colocar estilos con componentes
- Aproveche las características de sintaxis nativas de JS
- Aproveche cualquier cosa del ecosistema JS
¿Qué CSS-in-JS no te libra de la necesidad de entender?
- Cómo se aplican los estilos al DOM
- Cómo funciona la herencia
- Cómo funcionan las propiedades CSS
- Cómo funciona el diseño CSS
CSS-in-JS no lo absuelve de aprender CSS. Sobre todo, de todos modos.
Escuché muchos rechazos en CSS-in-JS en la línea de “ustedes están buscando CSS-in-JS porque no entienden CSS” o “Lo hacen porque tienen miedo de cascada. Ya sé cómo definir el alcance de CSS “. Encuentro que esas cosas están más hurgando en las islas que no son particularmente útiles.
Laura buns tiene un maravilloso artículo de dos caras titulado “La web sin la web”, parte del cual trata sobre React y CSS-in-JS:
Odio React porque los enfoques de CSS-in-JS de forma predeterminada lo alientan a escribir componentes únicos completamente autónomos en lugar de intentar construir la interfaz de usuario de un sitio web como un todo.
No necesita usar CSS-in-JS solo porque usa React, pero es popular, y esa es una crítica muy interesante y justa. Si analiza todo, ¿no corre un mayor riesgo de inconsistencia?
Hasta ahora, he sido un fanático de los módulos CSS en el sentido de que es lo más liviano que se obtiene cuando se trata de CSS-in-JS, solo maneja el alcance y la ubicación conjunta, y eso es todo. Lo uso con Sass para que tengamos acceso a combinaciones y variables que ayuden a la coherencia, pero pude ver cómo podría permitir un deslizamiento hacia un territorio peligroso de demasiados casos únicos.
Y, sin embargo, serían desechables únicos. Únicos códigos divisibles. Todo existe en equilibrio.
Laura continúa diciendo que le gustan los enfoques CSS-in-JS por parte del poder y la flexibilidad que ofrece:
Me gusta la forma en que CSS-in-JS te brinda suficiente abstracción para seguir usando trucos como los selectores de búhos ciegos y al mismo tiempo te brinda todo el poder de usar JS para hacer cosas como consultas de contenedores.
Martin Hofmann creó un sitio que compara BEM con Emotion que analiza un pequeño componente de “alerta”. Me gusta cómo es una comparación sin emociones (literalmente, sin hacer referencia a la biblioteca) que mira la sintaxis. BEM tiene algunas ventajas, en particular, no requiere herramientas y se puede compartir fácilmente con cualquier proyecto web. Pero el enfoque Emotion es más limpio en muchos sentidos y parece más fácil de manejar.
Me gustaría ver comparaciones más sin emociones de las tecnologías. La opción A hace estas tres cosas bien, pero es dolorosa aquí y aquí, mientras que la opción B hace estas otras cosas bien y resuelve algunos otros puntos débiles.
Recientemente vinculamos la publicación de Scott Jehl que busca cargar CSS de forma asincrónica. Línea de apertura de Scott:
Una de las cosas más impactantes que podemos hacer para mejorar el rendimiento y la resistencia de la página es cargar CSS de una manera que no retrase el procesamiento de la página.
Es notable que un enfoque completo de CSS-in-JS obtiene esta capacidad de forma natural, ya que el estilo está incluido en JavaScript. Está incluido a un costo. Un costo para el desempeño. Pero recuperamos parte de ese costo si eliminamos otras cosas que bloquean el renderizado. Eso es algo interesante digno de más datos, al menos.
Puede que me pateen el trasero por esto, pero estoy un poco menos interesado en las conversaciones que intentan culpar a CSS-in-JS por levantar la barrera de entrada en la industria. Eso es algo enorme a considerar, pero no estamos hablando de cerrar CSS aquí y obligar a todos a usar otro idioma. Estamos hablando de bibliotecas de nicho para ciertos tipos de proyectos a ciertas escalas.
Creo que vale la pena echar un vistazo a las ideas de CSS-in-JS si …
- De todos modos, estás trabajando en un proyecto de JavaScript con muchos componentes.
- Ya está coubicando plantillas, funciones y consultas de datos.
- Cree que puede aprovecharlo sin dañar la experiencia del usuario, como recuperar velocidad en otros lugares.
- Su equipo se siente cómodo con la tecnología requerida, ya que no está rechazando el talento.
Max Stoiber es un fan descarado. Su publicación sobre el tema habla sobre la confianza que le brinda este estilo y el tiempo que ahorra para encontrar lo que necesita, ambas cosas que he descubierto que son ciertas. Pero también cree que el enfoque es específicamente para aplicaciones de marco de JavaScript.
Si está utilizando un marco de JavaScript para crear una aplicación web con componentes, CSS-in-JS probablemente sea una buena opción. Especialmente si eres parte de un equipo en el que todos comprenden JavaScript básico.
Me encantaría escuchar sus pensamientos sobre esto en los comentarios. ¿Ha resuelto sus sentimientos sobre todo esto? ¿Locamente enamorado? ¿Hirviendo de disgusto? Me interesaría más escuchar historias de éxito o fracasos en proyectos reales.