Esta publicación es una respuesta detallada a las preguntas de esta conversación en Twitter . El autor del original, Sunil Pye, es el autor de la biblioteca de glamour relativamente popular y trabaja como desarrollador en Facebook.
¿Cómo es Javascript más conveniente que CSS? ¿Cómo escribir CSS dentro de JS lo hace más compatible?
Estaré encantado de hablar sobre este tema. Debo decir de inmediato que las soluciones CSS-in-JS tienen gastos generales, pero generalmente este precio se justifica por las ventajas que aportan. A veces pueden ser útiles, pero esto no significa que CSS-in-JS deba usarse siempre y en todas partes.
Entonces, lo más importante en CSS-in-JS (cij) son los selectores CSS. La mayor ventaja de cij es que las computadoras pueden generar estos selectores automáticamente. Convenciones como OOCSS, etc. en principio, son buenos, pero se basan en selectores escritos a mano, que son difíciles de garantizar la unicidad en el espacio de nombres común, porque siempre existe la posibilidad de intersección. Si no sucede ahora, puede ocurrir después de tres años, cuando su equipo crezca y las circunstancias cambien. Esta situación se exacerba al usar bibliotecas de terceros. La limitación del alcance de los selectores CSS también se puede lograr utilizando módulos CSS , que son populares precisamente para esta oportunidad.
Sin embargo, con todos estos enfoques, los selectores son muy difíciles de analizar estáticamente y encontrar cuáles están rotos (o contienen errores tipográficos), lo que significa que deberán verificarse manualmente en el proceso de revisión del código, lo que reducirá la efectividad del comando. Debemos utilizar la ayuda de las computadoras y no confiar en la integridad e impecabilidad de las personas (porque esto no es así). CSS-in-JS hace posible automatizar la generación de selectores e identificadores únicos.
Además, el control mejorado sobre los selectores CSS abre nuevas posibilidades que antes no eran fácilmente accesibles. Por ejemplo, simplemente podemos implementar una extracción CSS crítica haciendo coincidir los bloques HTML con los estilos que necesitan, de modo que podamos cargar solo 1-2 Kb de CSS en la página, lo cual es necesario para la visualización inicial de la página. Sin ningún tiempo de ejecución! Los marcos como Gatsby y Next lo usan activamente para mejorar los indicadores de rendimiento en proyectos basados en ellos. Incrustan CSS crítico directamente en el HTML descargable simplemente porque pesa tan poco que sería mejor que una solicitud adicional que bloquea la carga de la página. Esto reduce en gran medida el tiempo inicial de representación de la página. ¡Además, también contribuye a resolver los problemas del tamaño de Javascript descargable! Los beneficios provienen de la aplicación de CSS crítico, así como del uso de import() dinámica import() , división de código y eliminación de código no utilizado. (En contraste con los archivos de estilo Legacy en constante crecimiento, en los que los desarrolladores solo agregan código nuevo, por temor a tocar el existente. Hay un poco de análisis sobre este tema ).
Una situación similar con la implementación de temas. ¿Sabía que las variables CSS , aun siendo algo muy interesante, no se aplicaron a los casos de uso para los que fueron pensadas originalmente, y todo porque los métodos alternativos para los navegadores antiguos eran muy complicados o inferiores? Esto significa que generalmente se usan como constantes globales, pero muy raramente como variables cuyo valor se determina dinámicamente en el navegador. Tener un tiempo de ejecución CSS CSS significa que puede pasar valores de JS a estilos, haciendo esto posible.
De hecho, le gustará: finalmente puede usar honestamente variables CSS en todos los navegadores, es decir, capacidades nativas sin tiempo de ejecución en los navegadores que los admiten, y un tiempo de ejecución especial para navegadores más antiguos. (Escribí más sobre esto aquí y, si entiendo correctamente, esta es la única biblioteca que lo ha logrado).
En una situación compleja de SPA con un montón de componentes y carga asíncrona de recursos, como scripts y estilos, no puede garantizar el orden exacto de los estilos de carga, por lo que debe crear algún tipo de soluciones de tiempo de ejecución para garantizar el orden de los estilos, o simplemente usarlo !important , incluso si te apegas a algún tipo de metodología CSS . Por ejemplo, tiene un elemento con class=“ab” , pero las clases b definidas en diferentes archivos de estilo, entonces no puede estar seguro de la forma final del bloque si no tiene un orden de secuencia claro de los archivos de estilo. La base de código de Facebook contiene miles de usos de !important , a pesar de que el código fue escrito por programadores calificados utilizando principios SÓLIDOS y una buena interacción con el equipo de diseño.
Esto a menudo se refiere al manejo de CSS como si fuera Javascript, dado que hace 10 años ya estábamos resolviendo problemas similares para JS, las bibliotecas y los módulos se registraron en el espacio de nombres global ( $ y similares) y tuvimos que tener mucho cuidado con el orden de conexión guiones en HTML. Pero no estábamos atrapados allí para siempre: ahora usamos módulos y los sistemas de ensamblaje los cosen juntos en un orden correcto garantizado. Esto es simple y transparente para nosotros.
Al observar proyectos reales, también noté que todavía puede usar enfoques arquitectónicos tradicionales (como OOCSS o SMACSS, etc.) en el mundo de CSS-in-JS: los elementos de esas arquitecturas están representados aquí por objetos JS, en lugar de los bloques de selector + estilos Tomo este enfoque y me funciona bien. Aquí puedes leer más al respecto.
También estoy al tanto de las desventajas de CSS-in-JS. De hecho, esta es precisamente la razón por la que no hay una biblioteca "canónica" que represente CSS-in-JS: es un espectro de soluciones diferentes, desde CSS estático de vainilla por un lado hasta bibliotecas completamente dinámicas como componentes con estilo por el otro. Los preprocesadores como SASS o LESS pueden parecer perpendiculares a este espectro, porque teóricamente pueden ser utilizados por cualquiera de estas bibliotecas a discreción de sus autores. Cada una de estas bibliotecas tiene sus inconvenientes: algunas se dedican a extraer estilos en la etapa de ensamblaje para que no haya gastos en tiempo de ejecución, algunas se centran en la corrección o conveniencia para los desarrolladores, otras se centran en la implementación efectiva de animaciones complejas, y así sucesivamente. Esta diversidad es una reacción natural a la necesidad de diferentes soluciones para diferentes tareas de trabajo, en una industria de rápido crecimiento. Y esto sucede no solo con las bibliotecas: los desarrolladores de estándares web (ShadowDOM y otros) también intentan resolver estos problemas valientemente, sino que su solución también tiene inconvenientes, el menor de los cuales es que todavía no están disponibles en todas partes, lo que hace que sea inaceptable su uso. en muchos equipos
Solía tener fuertes sentimientos sobre esto, pero he atenuado mis puntos de vista en los últimos meses. Resulta que la verdad en realidad se encuentra en algún punto intermedio: depende de los equipos, los requisitos, el tiempo, la documentación y muchos otros factores. Además, no creo que este texto represente la "forma final" de esta idea. Deberíamos alentar la experimentación en esta área para que podamos descubrir qué más podemos hacer mejor e incluso incrustar algunas de estas cosas en los navegadores.
PD: Demasiado tarde me di cuenta de que olvidé marcar la casilla "Traducción", por lo que se publicó así. Enlace al original .
Habr, arregla la interfaz, ¿por qué no puedes agregar la bandera de traducción después de la publicación?