Pasando de Css-In-Js en tiempo de ejecución a gran escala

Rate this content
Bookmark

En esta charla, Siddharth comparte los desafíos que su equipo enfrentó al optimizar el css en js en tiempo de ejecución (styled-components) para mejorar el rendimiento. En GitHub, hay alrededor de 4000 componentes de React que contienen estilos, Siddharth profundiza en las razones para repensar la arquitectura de estilos, los desafíos enfrentados y las lecciones aprendidas al migrar una gran aplicación.

29 min
02 Jun, 2023

Video Summary and Transcription

Esta charla explora la evolución de la arquitectura de estilos, el tema dinámico con componentes de estilo y la optimización de las actualizaciones de estilo. Se discuten los desafíos de la migración de CSS y la elección entre herramientas nativas de JavaScript y CSS. La charla también aborda herramientas y bibliotecas de CSS, incluyendo Tailwind CSS y las principales bibliotecas de CSS en JS como MUI. Se destaca la importancia de elegir una pila basada en las fortalezas de los miembros del equipo y el uso de espacios de nombres CSS para evitar conflictos en los árboles de dependencias.

Available in English

1. Introducción a la Arquitectura de Estilos

Short description:

A principios de este año, me encontré pensando en componentes, estilos y la cantidad de JavaScript necesaria para renderizar. Se me asignó la tarea de encontrar la arquitectura de estilos para Primer React, que impulsa GitHub. El desafío era que cualquier cambio tendría efectos en cascada en todo GitHub. Vamos a explorar cómo llegamos hasta aquí y el estado de la infraestructura de estilos.

Tengo muchas diapositivas, así que seré muy rápido al respecto. A principios de este año, me encontré pensando en componentes, pensando en estilos, pero también pensando mucho en la cantidad de JavaScript que necesitábamos para renderizar nuestros estilos. Estaba en este espectro de JavaScript, deberíamos tener muy poco JavaScript para hacer nuestros estilos, ¿realmente necesitamos mucho más JavaScript para hacerlo? Pasé mucho tiempo inclinándome en esta línea.

Cómo llegué hasta aquí fue básicamente asignado a esta tarea. Que es, encontrar la arquitectura de estilos para Primer React. ¿Qué es Primer React? Primer React es el sistema de diseño que impulsa GitHub. Soy Siddharth. Trabajo en el equipo de ingeniería de diseño en GitHub. Esta fue una tarea épica. Y antes de GitHub, solía trabajar en todas estas empresas y durante los últimos seis años he estado trabajando básicamente en sistemas de diseño y bibliotecas de componentes. Dato curioso, al igual que React, también comencé mi carrera exactamente hace 10 años hoy, así que gracias por eso. Aprecio el globo. Gracias.

Bien, volvamos a la diapositiva en movimiento. ¿Y por qué esta tarea fue tan confusa? Porque cuando intentaba encontrar la arquitectura de estilos para Primer, terminó siendo la arquitectura de estilos para gran parte de React en GitHub. Cualquier cambio pequeño que haga tendría efectos en cascada, ¿lo entiendes? Cascada? Efectos en todo GitHub. Y eso es algo aterrador de hacer. Así que primero hablemos de cómo llegamos al espacio en el que estamos.

Esto no es solo GitHub. Esto es principalmente toda la infraestructura de estilos. Piénsalo. Es 2015, y este meme acaba de salir. Es tan antiguo. La mejor película de todos los tiempos, Mad Max, también se estrenó en 2015, y Drake nos dio esta canción extremadamente genial. Internet Explorer 11 todavía estaba presente. Edge no se lanzaría hasta más tarde ese año. Lo que también significa que cosas como variables CSS que ahora damos por sentado en realidad no eran compatibles en mucho, excepto tal vez en Chrome o el nuevo Firefox. Creo que Firefox fue el primero en implementarlo en 2014. Tiempos diferentes. Requiere muy poco JavaScript para obtener tus estilos.

2. Evolución de la Arquitectura de Estilos

Short description:

Escribes tu estilo de esta manera. Este es un componente de botón. Colocas tus colores, colocas tu relleno. Con una pequeña cantidad de JavaScript, podrías anidar tus estilos y compilarlos en CSS. React introdujo el concepto de definir componentes en diferentes archivos y crear un árbol de dependencias entre ellos, lo que permite paquetes más inteligentes y eliminación de código inactivo. Los módulos de CSS mejoraron aún más esto al crear una relación uno a uno entre el componente JavaScript y CSS, lo que permite un empaquetado eficiente y eliminación de código inactivo.

Escribes tu estilo de esta manera. Este es un componente de botón. Colocas tus colores, colocas tu relleno. Ves muchos códigos hexadecimales, valores de píxeles codificados aquí. No es tan agradable como te gustaría, pero había algunas tooling que existían.

Lo puse un poco más de JavaScript porque tienes que usar Node.js y el compilador JavaScript está escrito en JavaScript. Con una pequeña cantidad de JavaScript, estas son las cosas que podrías hacer. Podrías anidar tus estilos y tener una mejor experiencia de desarrollo y luego podrías compilarlo en CSS.

Lo otro que obtuviste fueron variables. Podías definir estas variables en un solo lugar, lo cual es enorme para nuestros sistemas de diseño. Y luego en nuestros componentes solo tenías que usar esas variables. Así que cuando React apareció en 2013, y luego cuando comenzamos a usar React, lo usarías algo así. Tienes un componente de botón y usa el nombre de la clase. Y luego podrías usar este componente de botón en otro tipo de página.

Lo bueno que acabamos de hacer, al definir un componente en un archivo diferente y luego usarlo en un nuevo archivo, es que hemos creado esta relación. Hemos creado un árbol de dependencias entre componentes. Eso nos ayuda a crear paquetes más inteligentes, eliminar código inactivo. Obtienes muchas tooling de eso. Pero el mismo tipo de tooling realmente no existía para... O no existía realmente para CSS.

Esta clase que proviene de botón, no había una buena manera de saber de qué archivo proviene. Solo tenías que adivinar y empaquetar mucho más CSS. Eso, por supuesto, cambió muy rápidamente con un poco más de JavaScript con CSS modules. Entonces podías configurar CSS modules, básicamente podías simular una importación, eso es lo que llamaría. Porque no hay una importación real de CSS que esté sucediendo de esta manera. Pero estamos creando un árbol de dependencias. Ahora que tu árbol de dependencias de CSS coincide con tu árbol de dependencias de JavaScript, obtienes esta relación realmente agradable uno a uno entre el componente JavaScript y CSS. Y luego puedes empaquetarlos juntos. Puedes eliminar código inactivo muy rápidamente.

Lo siguiente interesante que se obtiene, aunque tengas variables en Sass, wow, veo tus ojos, lo siento por eso.

3. Dynamic Theming with Style Components

Short description:

El theming no se trata solo de modo claro u oscuro, incluye diferentes tipos de daltonismo y otros temas. Con Sass, tendrías que generar múltiples archivos de tema. Sin embargo, con JavaScript y style components, puedes definir clases con variables de JavaScript en medio de CSS, lo que permite theming dinámico.

Entonces, cuando tienes que hacer múltiples theming, y theming no se trata solo de modo claro u oscuro, theming hay modo claro, modo oscuro, hay diferentes tipos de daltonismo, lo mismo ocurre con el modo oscuro, hay oscuro atenuado, por lo que tienes muchos más temas. Y con algo como Sass, porque estas variables se compilan en tiempo de compilación, no en tiempo de ejecución, básicamente tienes que generar muchos archivos de tema para cada uno de ellos. Así que tendrías tu biblioteca de componentes en claro, tendrías tu biblioteca de componentes en oscuro, tendrías tu biblioteca de componentes en Teletopia, por lo que terminas creando todas estas combinaciones. Pero con un poco más de JavaScript, en realidad podríamos hacer esto en tiempo de ejecución con algo como style components. Porque JavaScript ya tenía variables en ese momento, CSS no. Así que terminas en algo como esto. Donde en lugar de escribir el nombre de la clase, defines todas tus clases con style components, y se parece un poco a CSS, pero no es CSS, y obtienes variables de JavaScript en medio de CSS. Obtienes muchas cosas buenas. Puedes hacer referencia a tu tema y este tema puede cambiar en tiempo de ejecución y propagarse por todas partes.

4. Theme Provider and Style Overrides

Short description:

Algunos de ustedes pueden estar utilizando este estilo. Pueden envolverlo con un proveedor de temas. Agregar colores adicionales puede ser desafiante sin una forma de verificar si están definidos y aplicados. TypeScript ayuda a detectar errores y proporciona autocompletado. Personalizar componentes con style components puede ser mucho trabajo y divergir de la fuente original. La propiedad SX o la propiedad CSS permiten anulaciones en línea, fusionando estilos predeterminados con anulaciones. Proporciona autocompletado de tipos y ofrece características como anidamiento y linting. El éxito de este enfoque ha llevado a miles de componentes de presentación en GitHub que utilizan la propiedad SX, lo que ha causado algunos desafíos.

Algunos de ustedes pueden estar utilizando este estilo. Y pueden envolverlo con un proveedor de temas que se encargue del resto. Entonces, algo interesante es que si agrego este color adicional, no tengo realmente una forma de saber si este es el color correcto, si este color está definido. Segundo, ¿se aplicará este color? Tengo que escribir esto, renderizarlo en el navegador, ver si funciona. Probablemente sea simplemente negro, así que hago clic derecho, inspecciono el elemento, y ahí es cuando puedo saber si es el color correcto.

Entonces agregamos un poco más de JavaScript y TypeScript. Y con TypeScript, ahora obtienes la línea ondulada roja, que te indica que esta propiedad, FGHover, en realidad ni siquiera está definida en el tema, por lo que no es lo correcto para usar. Y luego puedes corregirlo. Lo otro, si no lo has notado, es que cometí un error en alguna parte de las diapositivas donde el color de fondo solo apunta al fondo del botón y no al fondo del hover, y con el tema, porque ahora controlas tu tema, controlas tus estilos, puedes escribirlos de manera más inteligente y puede darte errores más inteligentes. Por ejemplo, el color del borde, estoy usando button.bg, que en realidad no es un estilo válido, que no es una variable de color válida en nuestro sistema de componentes, por lo que podemos darte estos errores, como que no es el correcto, tal vez quisiste decir button.borderColor. Lo mismo ocurre con el estilo de hover, dice, HellasPentaCast, un tipo, themeColorBackground no es asignable. Debes usar hover background. Y debido a que tienes TypeScript, tienes un compilador detrás de esto, también obtienes características como autocompletado, que te ayudan a elegir los fondos de hover correctos.

Entonces, las personalizaciones siguen siendo interesantes. Esta es la forma predeterminada o recomendada de personalizar componentes con style components, donde envuelves el componente de botón en un estilo y luego puedes agregar tus estilos adicionales allí. Algo así es agradable, pero también es un poco de plantilla, es mucho más trabajo. No soy un gran fanático de este estilo porque se aleja un poco del botón. Tendrías un botón de página y luego otra cosa usaría el botón de página y te alejarías cada vez más de la fuente original. Entonces, con solo un poco más de JavaScript, este es el logotipo de team UI, pero team UI, system UI, esta clase de bibliotecas hizo popular esta sintaxis que es la propiedad SX o la propiedad CSS. Y con esta propiedad, en lugar de definir un nuevo componente, defines tus anulaciones en este nivel de uso del componente. Es como una etiqueta en línea, pero no lo es, se compila. Entonces, lo que obtienes es algo como esto, donde tus estilos de botón son los estilos predeterminados y luego los fusionas con los estilos de anulaciones SX que se proporcionan. Y, por supuesto, escribes el SX para obtener el mismo autocompletado de tipos incluso en la aplicación con las anulaciones. Una API bastante agradable, bastante genial. Hemos pasado de menos, como muy poco JavaScript, a mucho JavaScript. Pero hemos obtenido muchas características en el camino, como anidamiento, variables de tema, pero también linting, dependencias de importación. Tenemos un autocompletado muy opinado que podemos configurar, lo cual sería más difícil de hacer sin JavaScript. ¿Es ese el éxito? ¿Es eso lo que queríamos? Supongo que sí. Pero, por supuesto, las cosas vienen con compensaciones. Ha sido un gran éxito, tanto que hay alrededor de 4,000 componentes de presentación en GitHub que tienen la propiedad SX solo para anulaciones de estilo. Y eso ha causado problemas de éxito, como problemas de champú.

5. Optimización de las Actualizaciones de Estilo

Short description:

Las grandes actualizaciones de estilo son lentas. Por lo tanto, cuando tienes muchos estilos que necesitan actualizarse según el comportamiento del usuario, las actualizaciones tardan un tiempo. La recolección de estilos para SSR también lleva mucho tiempo. Y por significativo, me refiero a alrededor del 10 al 15 por ciento del tiempo de renderizado del servidor. Y luego, el streaming y el suspense lo hacen más interesante, porque ahora tienes que sincronizar tus actualizaciones de estilo de manera muy inteligente. Al observar todas estas actualizaciones, comencé a pensar en cuándo se inyectan los estilos. Y tal vez no necesito hacerlo en tiempo de ejecución. Tal vez podamos compilar estos estilos. Así que agregué otra función justo al final y quería resolverlo con un poco más de JavaScript. Podría ser un complemento de Babel que lea el AST, examine los estilos y luego los compile en archivos CSS.

Las grandes actualizaciones de estilo son lentas. Por lo tanto, cuando tienes muchos estilos que necesitan actualizarse según el comportamiento del usuario, las actualizaciones tardan un tiempo. La recolección de estilos para SSR también lleva mucho tiempo. Y por significativo, me refiero a alrededor del 10 al 15 por ciento del tiempo de renderizado del servidor. Y luego, el streaming y el suspense lo hacen más interesante, porque ahora tienes que sincronizar tus actualizaciones de estilo de manera muy inteligente. Al observar todas estas actualizaciones, comencé a pensar en cuándo se inyectan los estilos. Y tal vez no necesito hacerlo en tiempo de ejecución. Tal vez podamos compilar estos estilos. Así que agregué otra función justo al final y quería resolverlo con un poco más de JavaScript. Podría ser un complemento de Babel que lea el AST, examine los estilos y luego los compile en archivos CSS.

6. Explorando Otras Soluciones y Funciones Nativas de CSS

Short description:

Así que primero exploré otras soluciones. Vanilla extract y Atlassian compile son dos ejemplos. Vanilla extract te permite escribir estilos en una extensión CSS.TS, mientras que Atlassian compile coincide con la API de style components y compila los estilos en archivos .CSS. Sin embargo, hay matices al compilar los estilos y el uso de estas soluciones puede restringir tu conjunto de JavaScript. GitHub.com utiliza SWC en lugar de Babel, lo que me llevó a considerar escribir un complemento en Rust. Es importante considerar la familiaridad de los equipos con las herramientas de JavaScript, TypeScript y Rust. Muchas características de CSS ya son ampliamente compatibles, como las variables de CSS, el theming, el nesting y las consultas de contenedor. También existen soluciones nativas de CSS para el linting y las importaciones, como Tileint y PostCSS.

Así que primero exploré otras soluciones. Vanilla extract es un buen ejemplo de esto, donde te piden que escribas tus estilos en una extensión CSS.TS. Entonces estás escribiendo los mismos estilos de objeto, pero estos pueden ser compilados y obtienes la seguridad de tipos y todas las cosas agradables. Estoy un poco corto de tiempo, así que voy a omitir las partes aburridas. Esto es aburrido.

Otra solución interesante es Atlassian compile, que coincide más con la API de style components y compila tus estilos en archivos .CSS, para que los usuarios solo obtengan archivos .CSS. Así que un buen ejemplo de esto sería tomar todo este código, ponerlo en un archivo .CSS y luego volver a poner el nombre de la clase. Eso es lo que obtienen los usuarios, eso es lo que los desarrolladores crean, eso es lo que ven los usuarios. Bastante bueno. Por supuesto, no es perfecto, hay algunos matices al compilar los estilos. Uno, tu experiencia de creación es un poco peor porque JavaScript es muy componible, puedes hacer muchas cosas, pero si quieres que se compilen, tu conjunto de JavaScript se restringe a cosas que se pueden compilar. Y eso puede causar confusión, puede causar APIs extrañas para que eso suceda. Tengo un pequeño concepto de prueba de esto, se llama CSS-out.js, es un complemento de Babel, si quieres verlo, son como 50 líneas de código solo para ver cómo funciona. Está en Github, esto podría ser una buena introducción a ello.

Entonces, ¿éxito, verdad? Ahora esto definitivamente debería funcionar. Tenemos nuestros estilos, podemos compilarlos y el pequeño problema con el que nos encontramos es que GitHub.com, el que la mayoría de ustedes usa, en realidad no utiliza Babel, utiliza SWC. Y ahí es cuando descubrí que si avanzas lo suficiente en el espectro de JavaScript, terminas en Rust, donde un montón de empaquetadores como SWC, Parcel, todos están escritos en Rust, y luego hay cosas como efbuild que en realidad están escritas en Go. Así que me encontré, si tengo que escribir un complemento, tal vez debería aprender algo de Rust y escribir un complemento en Rust para que podamos usarlo con SWC. Eso realmente me asustó. Así que hay 4000 componentes de presentación, pero están en 20 subpaquetes, y 20 subpaquetes en muchos equipos, y toda esta complejidad que les estamos pidiendo que asuman, 20 subpaquetes diferentes en múltiples equipos, tienen un nivel muy diferente de familiaridad con toda esta herramienta de JavaScript, TypeScript, Rust. A menudo hablamos de la herramienta adecuada para el trabajo adecuado, pero creo que hay un asterisco ahí. Tiene que ser la herramienta adecuada para el trabajo adecuado, para las personas que necesitan hacer ese trabajo. También me di cuenta de que ya no estamos en 2015. Y muchas de estas cosas que obtuvimos al avanzar en el espectro, muchas de ellas ya están ahí. Por ejemplo, las variables de CSS ya forman parte de la especificación de CSS y son ampliamente compatibles. El theming ya está ahí. Hay una propuesta para el nesting que es compatible y algunos navegadores están llegando a más. Hay consultas de contenedor que se están convirtiendo en una especificación muy amplia. Del mismo modo, existen soluciones para el linting y las importaciones que son más nativas del mundo CSS. Por ejemplo, Tileint para el linting, y PostCSS puede brindarte características similares a los módulos de CSS fácilmente.

7. Migración de CSS y Herramientas Inteligentes para Desarrolladores

Short description:

Ahora que CSS se ha vuelto más similar a JavaScript, podemos usar menos JavaScript. Hay una mayor diversidad en los empaquetadores de JavaScript, pero los editores de código se inclinan hacia VS Code. Tailwind y Polaris de Shopify tienen extensiones inteligentes que sugieren clases y variables CSS basadas en tu tema. Implementar esta inteligencia en las herramientas de desarrollo es desafiante pero valioso. Aún no existe una buena biblioteca de código abierto para esto. Necesitamos migrar nuestros componentes de presentación de SX a CSS. Podemos refactorizarlos uno por uno o usar herramientas para facilitar la migración.

Así que parecía que probablemente podríamos usar mucho menos JavaScript ahora que CSS se ha vuelto más similar a JavaScript, más variable. Lo único que no tenemos aquí es un autocompletado con opinión y hay algunos buenos ejemplos de esto.

Oh mierda, me olvidé de algo. De acuerdo. Hay una mayor diversidad en los empaquetadores de JavaScript. Hay parser, ESBit, SWC, etc. Pero la diversidad en los editores de código en realidad va en la dirección opuesta, donde VS Code parece ser la opción predeterminada. Incluso los navegadores en línea como Code Sandbox o StackBlitz también utilizan VS Code en el fondo para hacerlo posible. Si puedes admitir VS Code, puedes hacer feliz a una gran parte de la población de desarrolladores. Esa es la dirección en la que comencé a buscar.

Tailwind hace un trabajo realmente bueno en esto. Usa la extensión, utilizan un servidor de lenguaje para comprender lo que estás tratando de hacer, mirar tu tema y luego sugerir clases que realmente coincidan con tu propio tema. Eso es muy inteligente. De manera similar, esto es de Polaris de Shopify. Polaris es el sistema de diseño de Shopify, y tienen una extensión que utiliza algo similar para sugerir variables CSS en CSS que realmente forman parte de su sistema. Entonces, nuevamente, puedes tener cosas muy opinadas, puedes ver que no solo sugiere todo, sugiere shadow porque entiende que estás tratando de usarlo en box shadow. Creo que eso es muy genial. Así que también intenté jugar con esto. Fue sorprendentemente difícil de la manera equivocada y fácil en las cosas que pensé que eran difíciles. Y puedes obtener cosas muy opinadas, también puedes obtener errores de lint, donde puede evitar que no uses las variables que el equipo del sistema de diseño no quiere, pero usa las que queremos que uses, incluso si los valores son los mismos. Entonces hay mucha inteligencia que puedes incorporar a tu herramienta de desarrollo. Aún no existe una buena API de código abierto, una biblioteca de código abierto para hacer esto. Así que si alguno de ustedes quiere ser popular, tener esa fama de estrella de GitHub, esta es una idea gratuita para ustedes. Finalmente, eso debería ser todo. Ahora estamos usando CSS, tenemos las herramientas para ello, esto definitivamente debería ser suficiente. Casi. Recuerda que dije que tenemos 4,000 componentes de presentación que usan SX. Así que tenemos que moverlos todos a CSS para poder usar estas nuevas herramientas. Y una forma de hacerlo sería hacerlo uno por uno, refactorizarlo, pedir a los equipos que lo hagan, posponer a los usuarios, posponer los errores y priorizar la migración a CSS. O podríamos usar algunas herramientas. Así que recuerda esta cosa mágica que mostré antes que puedes hacer con un complemento simple y decidí que sería difícil hacerlo para tantos empaquetadores diferentes al mismo tiempo.

8. Desafíos en el Paso del Desarrollador y en la Nomenclatura

Short description:

Podríamos hacerlo en el paso del desarrollador en lugar del paso de construcción. TS Morph es una biblioteca que te permite escribir transformadores que pueden cambiar tu código basado en el AST de TypeScript. No es una migración automatizada, sino una migración asistida por automatización. ¿Deberías dejar de usar CSS en JS? Depende de tus circunstancias y necesidades específicas.

Podríamos hacerlo en el paso del desarrollador en lugar del paso de construcción. Hay una muy buena biblioteca llamada TS Morph. Básicamente, analiza el AST de TypeScript y te permite escribir transformadores que pueden cambiar tu código. Es bastante inteligente en los tipos que te proporciona. Dependiendo del tipo de la variable, puede ser un elemento de apertura JSX o un elemento de autocierre, puede diferenciar los dos, puedes ver los atributos JSX y luego puedes ser muy inteligente con ello.

Por ejemplo, el primero es bastante fácil. Si es margin 10, entonces sé que tengo que tomar esto, ponerlo en un archivo CSS y poner un nombre de clase aquí. Pero como estamos usando un compilador completo de TypeScript, también tenemos la opción de seguir las variables. Por ejemplo, si en SX estás pasando estilos base, en realidad puedes rastrear estas variables en varios archivos y compilar el valor desde allí. De manera similar, si estás llamando a una función, puedes encontrar la definición de la función y desde la definición de la función, devolver una clase en lugar de un estilo de objeto. Así que puedes ser realmente ingenioso, realmente audaz con algo así. Y así es como espero que migremos esos 4,000.

Ahora, lo que las computadoras no son tan buenas es nombrar cosas. Aunque tenemos mucho contexto en el archivo, puedes usar el nombre del archivo, puedes usar el nombre de un componente. Muchos de los nombres de clase terminaron viéndose así, donde hay un contenedor de envoltura de pila y luego un hash al final. Y eso es en lo que las computadoras no son buenas. Supongo que lo son, pero no sé lo suficiente de IA para ser bueno en ello. Entonces, el código que se genera no es muy mantenible a largo plazo. La forma en que lo veo es que no es una migración automatizada. Es una migración asistida por automatización. Y así es como se hace. Ejecutas tu comando, te da un poco de código, lo revisas como lo haría un desarrollador y luego, si te gusta, puedes sugerir algunos cambios de nombres de clase y luego lo implementas. Estaré recaudando una ronda de financiamiento porque dice migración asistida por automatización, y eso califica como IA. Puedes encontrarme en la sesión de preguntas y respuestas después con tus propuestas.

Entonces, en resumen, ¿deberías dejar de usar CSS en JS también? Depende. Si te encuentras en algún lugar de este espectro y piensas que estamos bien donde estamos, no tenemos los problemas de rendimiento de los que habló este tipo, todos nuestros desarrolladores son muy buenos en JavaScript, realmente no necesitamos preocuparnos, entonces quédate donde estás. Es un lugar feliz para estar. Pasé muchos años aquí, estaba bastante feliz.

9. Choosing Between JavaScript and CSS Native Tooling

Short description:

Si tienes un equipo que es muy bueno en JavaScript y herramientas, y quieres mejorar tu experiencia de desarrollo, ve con JavaScript. Pero si tienes un equipo mixto con diferentes conjuntos de habilidades, opta por las herramientas nativas de CSS. Puedes lograr mucho con un mínimo de JavaScript.

Si tienes un equipo que es muy bueno en JavaScript, muy bueno en herramientas, y te gustaría invertir más tiempo en mejorar tu experiencia de desarrollo mejorando el editor, mejorando tu sistema de complementos, entonces definitivamente ve más por JavaScript, ahí es donde está la mayoría de la diversión. Si eres como yo y te encuentras en un lugar donde tu equipo es muy mixto, con muchos diseñadores, desarrolladores, diferentes conjuntos de habilidades que contribuyen al mismo código, entonces te recomendaría ir completamente hacia la izquierda y usar las herramientas nativas de CSS, es realmente bueno ahora. Te sorprenderás de lo lejos que puedes llegar con muy poco JavaScript.

QnA

Q&A on CSS Tools and Libraries

Short description:

Esa es mi charla. Tenemos algunas preguntas en la diapositiva. La primera fue ¿qué opinas de panda CSS? Nunca había oído hablar de eso. No tengo opinión. Lo siento. ¿Qué piensas de tailwind CSS? Es una idea muy prometedora para nosotros. Hay ciertos aspectos en el ámbito de los componentes donde si tienes una biblioteca de componentes y quieres agregar anulaciones, es muy difícil hacerlo solo con nombres de clase. Porque el orden en el que das nombres de clase a un elemento HTML no importa realmente. Y ahí es donde empezamos a alejarnos de eso. Porque realmente estábamos en el camino de no querer una solución en tiempo de ejecución.

Eso es más o menos todo. Voy a hacerlo de nuevo porque pasé demasiado tiempo en esta diapositiva. Y eso es todo. Esa es mi charla.

Muy bien. Así que tenemos algunas preguntas en la diapositiva. La gente te ve como una opinión experta en CSS y las diferentes herramientas y bibliotecas de CSS. Así que tengo varias diferentes. Así que vamos a ir y me vas a dar tus opiniones sobre ellas.

La primera fue ¿qué opinas de panda CSS? Nunca había oído hablar de eso. No tengo opinión. Lo siento. Muy bien. Tal vez más tarde, en el turno de preguntas y respuestas, puedan venir y mostrártelo y podamos averiguarlo. Sí, me encantaría. Y luego tenemos otra. ¿Qué piensas de tailwind CSS? Esta te la esperabas. Sí. Sí. Definitivamente. Así que exploramos como parte de toda la exploración para este proyecto, también exploré tailwind. Y menos tailwind específicamente, pero más la idea de un CSS de estilo de utilidad que también tiene muy buenas herramientas. Y es una idea muy prometedora para nosotros. Hay ciertos aspectos en el ámbito de los componentes donde si tienes una biblioteca de componentes y quieres agregar anulaciones, es muy difícil hacerlo solo con nombres de clase. Porque el orden en el que das nombres de clase a un elemento HTML no importa realmente. Lo que importa es el orden en que aparecen en el CSS. Y si lo distribuyes por toda una gran aplicación, no puedes controlar realmente el orden. Así que necesitas un poco de CSS en tiempo de ejecución para asegurarte de que estás deduplicando estos nombres de clase para que eso suceda. Y ahí es donde empezamos a alejarnos de eso.

CSS Tools and Libraries

Short description:

Porque realmente estábamos en el camino de no querer una solución en tiempo de ejecución. Lo mostré a varios desarrolladores. Algunos desarrolladores dijeron que les encanta, y otros desarrolladores dijeron que lo odian. Esto ya no es una conversación técnica. Los camarógrafos tienen un pequeño problema de CSS. Otra pregunta que ha surgido es ¿qué piensas de las bibliotecas principales de CSS en JS como MUI, luchando con el renderizado del lado del servidor? ¿Deberíamos volver a los módulos de CSS? ¿O evolucionarán las bibliotecas? Esa es una muy buena pregunta. Hay un camino para que las bibliotecas evolucionen y funcionen muy bien con el renderizado del lado del servidor, suspense. Para bibliotecas como MUI, estoy realmente curioso por saber qué están pensando. Si pudiera reescribir prime desde cero, probablemente iría primero con CSS porque tenemos muchos desarrolladores de CSS muy buenos. Elegir una pila basada en los miembros del equipo y sus fortalezas es importante. El CSS crítico es un problema bastante resuelto con CSS en JS. La idea de que cada archivo de componente tenga un archivo CSS asociado es invaluable. El árbol de dependencias es algo que va a permanecer por un tiempo. A menudo me expongo a nuevas herramientas de desarrollo que realmente quiero.

Porque realmente estábamos en el camino de no querer una solución en tiempo de ejecución. Lo mostré a varios desarrolladores. Algunos desarrolladores dijeron que les encanta, y otros desarrolladores dijeron que lo odian. Esto ya no es una conversación técnica. Así que no seguimos por ese camino.

Genial. Creo que los camarógrafos tienen un pequeño problema de CSS. Están como, pon el punto ahí. Es como una cuadrícula. Centrar y un div. Pero llegamos al final.

Otra pregunta que ha surgido es ¿qué piensas de las bibliotecas principales de CSS en JS como MUI, luchando con el renderizado del lado del servidor? ¿Deberíamos volver a los módulos de CSS? ¿O evolucionarán las bibliotecas? Esa es una muy buena pregunta. Hay un camino para que las bibliotecas evolucionen y funcionen muy bien con el renderizado del lado del servidor, suspense. Hay una dirección allí. Siento que hay un murmullo que está sucediendo de que tal vez no vayamos por ese camino. Y tal vez retrocedamos un poco y volvamos a CSS. Así que para bibliotecas como MUI, estoy realmente curioso por saber qué están pensando en términos de estoy seguro de que se encuentran en el mismo espectro donde podrían ir un poco más con JavaScript y comenzar a construir complementos para todos estos diferentes bundlers, o ir en la dirección opuesta y eliminar o compilar por completo el CSS en tiempo de ejecución.

Ahora eso tiene sentido, eso tiene sentido. Ahora esta siguiente pregunta, en retrospectiva, es 2020 y si pudieras reescribir prime desde cero, ¿qué pila usarías? Si comenzara hoy, con el equipo que tengo hoy, probablemente iría primero con CSS porque tenemos muchos desarrolladores de CSS muy buenos que también son diseñadores muy inteligentes. Así que iría por ahí, y siento que estamos en un punto en el que no sería tanto una decisión técnica, porque comparé todas estas opciones, hice todas las tablas de pros y contras y al final se redujo a que esta se ve más bonita, así que diría que la habilidad es cómo decidí hoy.

También me encanta eso, elegir una pila basada en los miembros del equipo y sus fortalezas. Buena elección, buena elección. Tenemos otra pregunta, ¿qué piensas sobre el CSS crítico ya que es un problema bastante resuelto con CSS en JS? Sí, lo es. Creo que una cosa que definitivamente mantendríamos, lo único que estamos tomando del mundo de CSS en JS es algo como los módulos de CSS, y aunque podríamos hacerlo con CSS, la idea de que cada archivo de componente tenga un archivo CSS asociado. Y luego, a medida que compilas tu árbol de JavaScript, también puedes adjuntar tu árbol de CSS encima de él. Creo que esa es una idea invaluable y perdurará por mucho tiempo. Y eso también te ayuda a resolver cosas como el CSS crítico, el tree shaking, saber cuándo eliminar código. Creo que el árbol de dependencias es algo que va a permanecer por un tiempo.

Genial. Una cosa que también me encanta de ver a los desarrolladores dar presentaciones es que a menudo me expongo a nuevas herramientas de desarrollo que realmente me dan envidia y realmente quiero.

TypeScript Extension and Namespacing CSS

Short description:

Alguien preguntó sobre la extensión de TypeScript utilizada en las diapositivas, pero era solo Keynote. En cuanto al espaciado de nombres de CSS, depende del contexto. Los componentes de biblioteca como el botón Primer no tienen espaciado de nombres, mientras que los componentes de aplicación con nombres específicos como wrapper, stack y container tienen espaciado de nombres para evitar conflictos. Esto nos permite tener un árbol de dependencias sin conflictos utilizando módulos de CSS.

Y alguien preguntó, ¿cuál es la extensión de TypeScript que estás usando? ¿La extensión de TypeScript para? Creo que estaba en tus diapositivas, pero tus diapositivas en el editor de código en tus diapositivas estaban usando TypeScript. Oh, nada. Eso es solo Keynote. Buen diseño. Buen diseño. Es como, escribí y dibujé el rectángulo para obtener la cosa de TypeScript. Sí. Lo estilicé muy bien. Bien, haremos esto como el último.

¿Qué hay del espaciado de nombres de CSS, algo que los componentes estilizados ya están proporcionando? Sí, creo que es interesante porque depende. Si es un... Estamos dividiendo esta implementación de media hora donde los componentes de biblioteca, no les estamos dando espaciado de nombres. Por lo tanto, podrías tener algo como un botón Primer. Y eso se mantiene igual en todo el stack. Pero algo como un componente de aplicación donde cosas como wrapper, stack, container son nombres legítimos, esos tienen espaciado de nombres porque no queremos conflictos. Entonces, el mismo árbol de dependencias que obtenemos, también obtenemos la capacidad de hashear estos y tener sin conflictos con eso. Algo como CSS modules. Gracias, Sid. Todos aplaudan. Gracias.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Top Content
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
DevOps.js Conf 2024DevOps.js Conf 2024
163 min
AI on Demand: Serverless AI
Featured WorkshopFree
In this workshop, we discuss the merits of serverless architecture and how it can be applied to the AI space. We'll explore options around building serverless RAG applications for a more lambda-esque approach to AI. Next, we'll get hands on and build a sample CRUD app that allows you to store information and query it using an LLM with Workers AI, Vectorize, D1, and Cloudflare Workers.
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
React Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Building a Shopify App with React & Node
Top Content
WorkshopFree
Shopify merchants have a diverse set of needs, and developers have a unique opportunity to meet those needs building apps. Building an app can be tough work but Shopify has created a set of tools and resources to help you build out a seamless app experience as quickly as possible. Get hands on experience building an embedded Shopify app using the Shopify App CLI, Polaris and Shopify App Bridge.We’ll show you how to create an app that accesses information from a development store and can run in your local environment.
React Advanced Conference 2023React Advanced Conference 2023
148 min
React Performance Debugging
Workshop
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)