Poder Atómico: la Historia de StyleX

Hola, soy Naman. Mantengo StylX en Mera, y hoy voy a hablar sobre el poder atómico. Y no del tipo nuclear, sino que voy a hablar sobre lo atómico, y voy a hablar sobre poder. Y luego, usando esa lente, voy a contarles la historia de StylX.

Así que comencemos desde el principio. Al principio, existía HTML y fue el nacimiento de la World Wide Web. Y no había CSS. HTML es todo lo que teníamos. Y con ese HTML, usábamos etiquetas blink y etiquetas marquee para divertirnos, etiquetas de fuente para algo de estilo, y también lidiábamos con diseños de tablas. Eso no era divertido. Esto no era genial, pero era muy limitado. Todo tipo de diseños que hacemos hoy eran simplemente imposibles. Y era muy tedioso. No había forma de reutilizar nuestros estilos en los componentes. Los componentes ni siquiera existían aún.

Y así, en unos pocos años, personas inteligentes se reunieron e inventaron CSS. CSS resolvió algunos de nuestros mayores problemas con el estilo en HTML. Era mucho más poderoso, había diseños reales que podías hacer, y no solo con tablas. Y era mucho más reutilizable. Podías definir un selector CSS una vez y usarlo en todo tu HTML. Pero a medida que resolvíamos algunos problemas, descubríamos nuevos. Y nos dimos cuenta de que, dado que CSS no tenía espacios de nombres, era realmente difícil de mantener. Y dado que este es el CSS temprano, ni siquiera tenía variables. Así que no tenemos que repetirnos en nuestro HTML, pero ahora tenemos que repetirnos en nuestro CSS.

Así que algunas personas más inteligentes se reunieron, y llegamos a un nuevo conjunto de herramientas. Esta vez, eran preprocesadores de CSS. Cosas que procesarían algo que escribiste y generarían tu CSS. Puede que hayas oído hablar de Sass y Less. Solía usar Stylus, y CSS era CSS en JS antes de CSS en JS. Los preprocesadores de CSS resolvieron algunos de nuestros mayores problemas con CSS, como variables y anidamiento.

También añadieron un montón de otras características poderosas como bucles e inclusiones. Pero aún no tenían espacios de nombres, y seguía siendo difícil de mantener a gran escala. Y así, los ingenieros siguieron trabajando. Y en la siguiente era, hubo una bifurcación en el camino. Y parte de la comunidad se movió hacia los módulos de CSS, y otra parte de la comunidad se movió hacia CSS en JS. La razón por la que esto sucedió fue porque esta es la era en la que las aplicaciones de una sola página se estaban volviendo populares, y los frameworks como React habían comenzado a aparecer. Y solo para ser claros, hubo muchas personas que no se movieron a ninguna de estas nuevas herramientas y continuaron usando el buen CSS antiguo o preprocesadores de CSS. Pero me voy a centrar en cada paso adelante que damos y no continuar mencionando que, sí, las herramientas antiguas nunca desaparecieron.

Así que, en el lado de los módulos de CSS, finalmente resolvieron el problema de los espacios de nombres. Esto fue enorme. Esta es la razón por la que los módulos de CSS son tan exitosos. Pero aún era difícil de escalar de algunas maneras. En general, la mantenibilidad del código se había resuelto en su mayor parte, pero aún podías encontrarte con cierta cantidad de conflictos de CSS, y tu CSS seguiría creciendo a medida que tu aplicación se hace más grande. Por otro lado, CSS en JS también nos dio espacios de nombres, y nos dio un montón de otros poderes. Nos dio una experiencia de desarrollador mucho mejor que cualquier cosa que habíamos probado antes. Ahora podías escribir tu estilo en el mismo archivo que tu marcado, en el mismo archivo que tu componente. Pero la mayoría de estas primeras bibliotecas de CSS en JS tenían un rendimiento realmente malo porque dependían de la inyección de estilo en tiempo de ejecución. Y así, los desarrolladores de JavaScript, siendo desarrolladores de JavaScript, seguimos intentándolo.

Y un montón de bibliotecas realmente impresionantes surgieron y se volvieron exitosas. Y eventualmente alcanzamos el siguiente hito, que fue el CSS en JS en tiempo de compilación. Esta fue una evolución de la idea de CSS en JS, donde no tienes la sobrecarga de rendimiento porque compilas todo tu CSS en tiempo de construcción, y ya no tienes ninguna inyección de estilo en tiempo de ejecución, pero aún tienes la misma gran experiencia de desarrollador, que es por lo que CSS en JS fue tan exitoso en primer lugar. Y aunque resolvió muchos problemas, no resolvió completamente todos los problemas de escalabilidad que hemos tenido con básicamente cada solución de CSS que hemos probado. A medida que tu aplicación se hace más grande, tu CSS se hace más grande. Entonces te ves obligado a cargar tu CSS de manera diferida, lo que significa que las actualizaciones de tu página se vuelven más lentas porque estás esperando que se cargue, procese y compute CSS adicional. Y así continuamos. Un montón de más grandes bibliotecas de CSS en JS en tiempo de compilación surgieron, como Linarea y Vanilla Extract, y alcanzamos algún tipo de convergencia, donde las dos corrientes más o menos acordaron en la idea de CSS atómico. Por supuesto, no todos estuvieron de acuerdo. Muchas personas se aferraron a los módulos de CSS, módulos de CSS Vanilla, y muchos otros continuaron usando el CSS en JS en tiempo de compilación, o incluso CSS en JS en tiempo de ejecución. Pero es importante notar que muchas personas de ambas corrientes sí estuvieron de acuerdo en que el CSS atómico era una buena idea. Pero, ¿qué es el CSS atómico? Tan pronto como se menciona el término, este pensamiento aparece en la cabeza de todos, este elefante en la habitación.

Hablaremos de eso, pero antes de eso, hablemos de lo que significa realmente atómico. Atómico es descomponer algo en piezas pequeñas y reutilizables para que puedas juntarlas y maximizar la reutilización. Es un poco como los componentes. Y cuando encontramos la manera correcta de descomponer nuestros problemas, de encontrar el átomo correcto para cada problema, generalmente es un desarrollo exitoso. El diseño atómico era pensamiento atómico para el diseño. La arquitectura de componentes era pensamiento atómico para el desarrollo de interfaces de usuario. La filosofía Unix hace décadas era pensamiento atómico sobre la arquitectura de un sistema operativo. Y la programación funcional a menudo sugiere diseñar toda tu base de código en pequeños átomos de funciones puras. Todas estas son estrategias exitosas y han resistido la prueba del tiempo.

Pero para llegar a este punto, para llegar a la idea de CSS atómico, tuvimos que pasar por muchos hitos. Tuvimos que hacer mucho progreso. Entonces, ¿cuál fue este poder que nos llevó a estos hitos, que nos hizo avanzar, que estaba siempre detrás de escena ayudándonos a avanzar? No nos gusta pensarlo, pero son solo compiladores o transpilers o transformación de código de cualquier tipo. Todo tipo de herramientas desde preprocesadores de CSS y módulos de CSS y postprocesadores son todos compiladores. JSX y otras extensiones de sintaxis son compiladores. Lenguajes enteros como TypeScript son compiladores. E incluso características de React como componentes de servidor y el compilador de React es un compilador. Y los hemos estado usando durante años. Incluso olvidamos nuestros empaquetadores y minificadores, que, sí, son compiladores. Y así, los compiladores nos han llevado al punto donde podemos empezar a hablar de CSS atómico Hacerlo realmente agradable de usar y no solo rápido de usar.

Pero bien, ya que he mencionado CSS atómico, abordemos ese elefante en la habitación. Y sí, estoy hablando de Tailwind. Y Tailwind es un poco difícil de ignorar estos días. Mantengo Stylix, pero paso más tiempo hablando de Tailwind. Y para ser honesto, no tengo nada malo que decir. Tailwind utiliza estilos atómicos, que escalan extremadamente bien. Tu aplicación puede seguir creciendo y tu CSS deja de crecer después de un punto. Y esto te permite generar un único archivo CSS pequeño para toda tu aplicación. Así que no necesitas cargar CSS de manera diferida en actualizaciones de rutas y ralentizar algo que ya es mucho trabajo para que tu navegador y tu red manejen. Y sí, como mantenedor de Stylix, estamos de acuerdo. Si pasamos a Stylix, verás que sí, también generamos CSS atómico, que escala bien.

Y también enviamos un solo archivo CSS para toda la aplicación. Llegamos allí desde un camino diferente, llegamos allí desde módulos de CSS. Y Stylix resulta verse un poco diferente. Estos son los mismos estilos exactos que te mostré en Tailwind antes. Pero estamos de acuerdo en las ideas generales. Excepto que también hay algunas diferencias.

Así que hablemos de eso. Tailwind, debido a cómo está diseñado, funciona con casi cualquier lenguaje. Stylix es un compilador de JavaScript. Así que realmente solo funciona con variantes de JavaScript, como TypeScript o Flow. Tailwind de alguna manera requiere y fomenta mucha repetición. Así que no es raro repetir el mismo nombre de clase en muchos elementos en tu marcado. Este ejemplo es en realidad del propio sitio web de Tailwind. Y esto puede ser bueno o malo, pero el inconveniente es que puedes olvidar accidentalmente actualizar una de las cinco imágenes cuando estás actualizando los estilos. Es un poco difícil crear restricciones donde todas las imágenes sean iguales.

Hay maneras, por supuesto, pero es un poco tedioso. Por otro lado, Stylix es un compilador, por lo que puedes definir fácilmente estilos una vez y reutilizarlos en varios lugares. Y si necesitas hacer un cambio, sabes dónde hacer el cambio. Y sí. Tailwind te permite definir tus estilos en línea, lo cual es conveniente para mucho prototipado y llegar allí rápidamente. Los estilos de Stylix no son en línea, lo que podría parecer un poco más ceremonial. Los estilos de Tailwind son solo cadenas sin tipo. Hay algunas herramientas que te muestran lo que significan esas cadenas, pero no obtendrás ninguna garantía de seguridad de ellas. Los estilos de Stylix son objetos completamente fuertemente tipados, y puedes usarlos como restricciones para tus prototipos. Tailwind realmente no admite la fusión de forma predeterminada, pero puedes usar una herramienta como Tailwind Merge para fusionar estilos en tiempo de ejecución. Y agrega bastante sobrecarga. Stylix está diseñado para una rápida fusión de estilos. Así que, como, sí, Tailwind es durs, pero, sí, probablemente podría ser más difícil de leer. Y Stylix es más detallado, pero tal vez sea un poco más legible.

¿No es esto solo sintaxis? Como, ¿estamos discutiendo sobre sintaxis aquí? ¿Es eso lo que estamos haciendo? Y sí, lo estamos. La sintaxis es importante para las personas, así que es hora de una demostración.

Aquí tengo un sitio web. Es un sitio web de XJS, y tiene una página para charlas. Estas son todas las charlas que he dado hasta ahora, y espero que esta charla llegue a esta lista. Y quiero agregar una tarjeta adecuada aquí, y aún no tengo un diseño. Así que en lugar de crear un diseño desde cero, me gusta este diseño que está en el sitio web de ReactConf ya. Así que voy a tomar una de estas tarjetas que ya tienen y copiar el HTML, y simplemente lo voy a pegar aquí. Y de hecho, solo para que sea un poco más fácil, lo voy a pegar en un archivo HTML, formatearlo y luego copiarlo, y luego pegarlo aquí. Y por supuesto voy a obtener un montón de errores, porque HTML no es solo JSX de la caja. Así que voy a cambiar mi clase a nombre de clase. Voy a detectar estas pequeñas etiquetas de estilo en línea y simplemente convertirlas en clases de Tailwind también. Luego puedo deshacerme de esto. De hecho, puedo deshacerme de todo esto. Y sí, usemos los props para la imagen. Y limpiemos un poco más mientras estamos en ello. Y sí, esto es display none, así que simplemente eliminémoslo por completo. Y guardémoslo, formateémoslo, y veamos cómo se ve la página. Ahí está. No tuve que hacer nada. Así que Tailwind simplemente está funcionando, así que debo tener Tailwind configurado, ¿verdad? En realidad, no. Este es un proyecto que usa StyleX en todas partes. Y este Tailwind simplemente se está compilando a StyleX. Y si quieres ver cómo se ve, esta es mi carpeta de entrada, y estoy usando el CLI de StyleX para compilar toda la carpeta. Y si te muestro a qué se ha compilado, eso es StyleX. Y el StyleX desarrolló nombres de clase de depuración y todo. Pero, está bien, eso es un poco impresionante, pero ¿cuál es el beneficio de esto? Como, ¿no podrías simplemente usar Tailwind ya? Bueno, en cierto modo, pero en realidad puedes hacer un poco más.

Así que acabo de notar que estas tarjetas son un poco pequeñas. Si miro las imágenes, verás que estas tarjetas están en una cuadrícula, pero las tarjetas no están llenando la cuadrícula. Y eso es porque el estilo de estas tarjetas está codificado, y no quiero que sea así. Pero también me siento más cómodo escribiendo StyleX que con Tailwind.

Así que escribamos algunos estilos de StyleX. Así que voy a escribir algunos estilos para el contenedor de imágenes, donde voy a hacer mi ancho 100%, y voy a hacer mi relación de aspecto 16 por 9, y voy a hacer mi altura automática. Bien, así que he definido eso. ¿Cómo aplico eso? Así que este es mi contenedor de imágenes. Esto en realidad no hace nada, así que puedo deshacerme de él. Lo que puedo hacer es tomar este nombre de clase, reemplazar esto, usar mi StyleX.props, aplicar eso, pero quiero sobrescribir lo que ya estaba allí. Así que hay una función llamada tw que también se exporta del paquete de Tailwind a StyleX. Y puedo simplemente definir eso allí, y así. Sí, como puedes ver, mis tarjetas son un poco más grandes, pero las imágenes aún no lo son. Así que vamos a las imágenes a continuación.

Sí, así que quiero lo mismo para las imágenes, así que voy a reemplazar esto con lo mismo, y asegurémonos de que sean los mismos estilos. Y esta vez, en lugar de aplicar los estilos del contenedor de imágenes, déjame definir un estilo de imagen donde tengo el ancho y la altura establecidos al 100%. Y paso eso fuera de la función tw, y ahí vamos. Así que si ves, las imágenes ahora están llenando la cuadrícula como se esperaba, y se ve bien, y acabo de mezclar y combinar StyleX y Tailwind en el mismo archivo. Incluso puedo añadir algo más de estilo aquí. Así que reemplacemos estos datos codificados con las cosas correctas. Así que ya tengo la imagen correcta. Cambiemos el enlace al enlace superior y ábrelo en una nueva página. Y eso es todo. Y en lugar de esto, voy a hacer un doc.conference, y voy a envolver esto en un enlace. Y eso se ve mucho mejor, pero no me gusta cómo se ven los enlaces. Así que sí, continuemos con algo de estilo y digamos que el color es colors.accent, que viene de mi equipo de StyleX justo aquí, justo allí. Es uno de dos colores. Y déjame aplicar eso. Así que ya se ve un poco mejor. Cambiemos el subrayado.

Así que la decoración de texto debería ser por defecto ninguna, pero debería mostrarse al pasar el ratón y debería mostrarse al enfocar visible. En realidad, solo enfocar. Y el desplazamiento del subrayado del texto, vamos a establecerlo en cuatro. Y sí, eso se ve mucho mejor.

Así que hay una característica adicional que no he mostrado hasta ahora. Y para mostrarla, déjame sacar una de estas cosas. Así que ahora que puedes definir tus clases de tailwind en esta función TW, puedes simplemente definir constantes en tus componentes y definirlas y luego usarlas. ¿No sería genial poder hacer esto en Tailwind 2? Bueno, ahora puedes.

Y aquí está la cosa loca. Si miras el tipo de este objeto, está fuertemente tipado. Esta función TW es capaz de leer toda la cadena y convertirla en el exacto objeto StyleX que generaría, casi, más o menos. Y sí, este es un analizador completo escrito en Tailwind, pero funciona.

Si elimino algunos de estos y, por ejemplo, esto es un poco redundante porque ya es 320. Y si solo elimino estos por un segundo, verás, sí, tanto las claves como los valores están ahí. Y si te muestro uno diferente, sí, está todo ahí. Así que puedes hacer eso. Y ahora puedes deshacerte de estos nombres de clase redundantes, que no necesitamos. No necesitamos un ancho. Y tampoco necesitamos un ancho aquí. Y en realidad ni siquiera necesitamos esto. Así que probablemente podríamos deshacernos de esto por completo. Y sí, eso se ve bastante bien.

Bien, esa fue la demostración. Y vamos a concluir. Los analizadores han impulsado el progreso del desarrollo web. Nos llevaron a donde estamos hoy. Y así decidimos usar un compilador al construir StyleX y habilitar Atomic CSS. El estilo en la web ha tomado muchos caminos paralelos. En Meta, pasamos por una arquitectura de módulos CSS. El ecosistema más grande hizo muchas cosas diferentes.

Y muchas personas diferentes han llegado de manera independiente a la misma conclusión de Atomic CSS. No todos están de acuerdo, por supuesto, pero una gran parte de la comunidad sí lo está. Y Tailwind y StyleX son más similares de lo que podrían parecer como resultado. Ambos quieren generar el mismo tipo de resultado. Y con herramientas como Tailwind to StyleX y la demostración que acabo de mostrarte, tal vez la mejor manera de usar Tailwind sería StyleX.

Y antes de irme, quiero hablar de una cosa más. Y esa cosa más es React Strict DOM. Y React Strict DOM es un proyecto que se construye sobre StyleX para crear una base común para poder escribir UIs tanto para web como para React Native. Es una UI que se ve muy similar a la web, y te ofrece APIs que son HTML y CSS. Es como, oye, ¿y si las APIs web no fueran globales?

Y si quieres aprender más sobre ello y probarlo y construir algunas aplicaciones a través de web y móvil, di una charla sobre esto en React Conf a principios de este año. Se llama Cross-platform React. Así que revisa esa charla. Y gracias. Gracias a todos. Voy a terminar la charla. Así que muchas gracias por ver. Espero que lo hayan disfrutado. Y nos vemos en la próxima. Adiós. Adiós.