Chunking

Mi nombre es Tobias Koppers, trabajo en Vercel como parte del equipo de herramientas de empaquetado, y hoy otro tema de Bundler, el chunking. Entonces, ¿qué es el chunking en realidad? Mi definición de chunking es que es un proceso en un Bundler que coloca módulos en archivos de salida. Y usualmente llamo a estos archivos de salida chunks porque, bueno, se me ocurrió este nombre. Así que básicamente es como tomamos el gráfico de módulos de tu aplicación, decidimos de alguna manera extraña cómo ponerlo en chunks, y ese es el proceso de chunking.

Si lo visualizas, podría haber un ejemplo realmente simple aquí. Así que tenemos un gráfico de módulos, uno realmente pequeño para este caso. Tenemos un montón de módulos, estos como puntos blancos. Estos módulos generalmente están conectados a través de dependencias, como import, o require, o un import asíncrono. Y estos son los bordes del gráfico. Y visualizo un borde realmente especial aquí porque es realmente especial para el chunking, hay uno rojo punteado, que es un import asíncrono, como un import dinámico o algo donde cargas algo bajo demanda.

Y también, generalmente tu gráfico de módulos tiene muchos puntos vacíos, tal vez tus páginas o esas cosas. Y aquí están las páginas más importantes de una aplicación, por supuesto, la página legal y la página de precios. Y básicamente puedes visualizar el chunking de una manera que simplemente dibujas ciclos alrededor de estos módulos. Y sí, hice esto con los ciclos de pantalla, y básicamente significa que todos estos módulos que están ciclando juntos se colocan en un archivo de salida. Y sí. Y un ejemplo como este import asíncrono aquí en el lado izquierdo, con la cosa punteada roja, se coloca en su propio chunk para que podamos cargarlo bajo demanda.

Y tenemos como todos los puntos de entrada siendo sus propios chunks porque entonces podemos cargarlos independientemente de las otras páginas. Y también podrías, como en este ejemplo, también puse como el área del medio de módulos que son compartidos por estos dos puntos de entrada en sus propios chunks, para que podamos compartir eso. Pero sí, es realmente complicado. Puedes idear muchas formas diferentes de ciclar estos módulos. Y sí, ese es el proceso de chunking, no de ciclado. Sí.

¿Y cómo hacer chunking de una buena manera? Así que sí. Una cosa es que puedes mirar las métricas. Así que la mayoría de las veces, nos preocupamos por las métricas de rendimiento. Así que estas métricas básicamente influyen en cómo dividimos las cosas en chunks. Y antes de que miremos las métricas, queremos ver otro término que es grupos de chunks. Y digo que los grupos de chunks son básicamente un conjunto de chunks que se cargan juntos que podrían ser en una carga inicial de página, cargas estos 10 chunks en etiquetas de script.

Y ese es un grupo de chunks de carga inicial. Pero también es como otros tipos de grupos de chunks, como en una importación dinámica, hay un grupo de chunks de carga asíncrona donde cargas estos chunks juntos como un grupo. O una navegación entre dos páginas es también como un grupo de chunks. Y realmente queremos mirar algunas métricas. Una métrica es el tamaño de descarga. Y con tamaño de descarga, no me refiero al tamaño del bundle porque la gente a menudo ve el tamaño del bundle como este es el tamaño de la carpeta que el bundler, la carpeta de salida que el bundler produce. Pero el tamaño total de esa carpeta, eso realmente importa.

Podría importar para el tiempo de compilación de tu aplicación, pero no importa para el rendimiento percibido por el usuario. Lo que realmente importa es el tamaño de descarga por grupo de chunks. Esta carga inicial de página tiene tantos bytes descargados o estas cargas bajo demanda de tantos bytes descargados o esta navegación tiene tantos bytes descargados. Así que realmente, realmente queremos mirar estas métricas en un sentido de por grupo de chunks. Y similar para la segunda métrica, que es el conteo de solicitudes. El conteo de solicitudes obviamente no es bueno si haces muchas solicitudes porque cada solicitud tiene un overhead.

Incluso con HTTP 2.0, todavía hay un overhead. Es menos que antes, pero aún no es bueno cargar millones de archivos en tu aplicación. Y ahora ya tenemos dos métricas. Si miras un ejemplo, este es realmente pequeño. Tengo dos páginas, A y B, y ambas comparten un módulo compartido. Y ahora puedes idear diferentes estrategias para hacer chunking aquí. Entonces, una estrategia podría ser poner módulos específicos de la página en los chunks de la página, como el azul y el verde, y luego hacer un chunk común donde pones los módulos compartidos. Eso se ve bien. Básicamente significa que cada página tiene que hacer dos solicitudes, pero solo descarga los módulos que realmente necesita. Y si haces una navegación de la página A a la página B, no tienes que descargar el chunk común de nuevo, y solo descargas una sola solicitud y no la página B. Suena bien. Pero también hay otra estrategia. Podrías duplicar estos módulos compartidos y solo hacer un solo chunk por página.

Así que, básicamente, ahora tienes solo una solicitud. Todavía descargas la misma cantidad. Incluso podrías descargar unos pocos bytes menos porque la compresión generalmente funciona mejor si tienes chunks más grandes. Si lo divides, es peor en términos de compresión. Pero ahora tienes el problema de que si navegas de la página A a la página B, descargas el módulo compartido de nuevo. Así que, básicamente, desperdicias un poco de tamaño de descarga en esa navegación. Es básicamente un compromiso. Y ese es básicamente el esquema principal aquí. Pero hay más métricas. Otra métrica es el caching a largo plazo, y lo menciono especialmente aquí porque a menudo los desarrolladores no lo consideran mucho. Y es una métrica realmente interesante. Básicamente significa que si haces una edición de código, tal vez cambies una línea de código.

Eso básicamente significa que un módulo está cambiando, un módulo es diferente. Eso significa que el chunk que contiene el módulo es diferente. Y para el visitante habitual de tu aplicación, entonces un usuario que estuvo allí antes de que el código cambiara y ahora después, regresa. Significa que tienen que descargar estos chunks cambiados de nuevo, y significa que tienen que re-descargar todos los módulos que están en estos chunks. ¿Y cómo puedo afectar eso? Si básicamente puedo hacer chunks más pequeños, como poner menos módulos por chunk, obviamente aumenta mi conteo de solicitudes.

Pero luego tengo un mejor caching porque se tienen que descargar menos módulos. También podrías ser un poco más inteligente agrupando estos módulos por su tasa de cambio. Así que intentas poner módulos que usualmente cambian juntos en un chunk. En el caso más simple, podría ser simplemente poner todo tu código de aplicación en App.js y poner todo tu código de vendor en Vendor.js. Ahora el código de App que cambia frecuentemente invalida App.js y solo eso está cambiando, y el archivo Vendor.js solo se invalida o tiene que ser redescargado por el usuario si estás haciendo una actualización de dependencia, lo cual esperas hacer mucho. Así que, como ves, hay muchos compromisos.

Podrías hacer más, chunks más pequeños. Eso significa mejor caching, pero más solicitudes. Podrías hacer menos, chunks más grandes, eso es menos solicitudes y peor caching. Puedes duplicar módulos, eso significa que tienes menos solicitudes pero tiempos de descarga más largos en algunos casos. Así que básicamente no hay un chunking perfecto que puedas hacer.

Básicamente hay muchos compromisos que tienes que considerar y a veces también es realmente costoso calcular todas estas heurísticas en una aplicación realmente grande. Porque hay tantas formas extrañas en las que puedes solicitar y buscar grupos de chunks y esas cosas. Pero veamos otra parte de todo el tema del chunking. Corrección del chunking. Así que debemos producir algo que sea correcto desde el punto de vista de la aplicación y eso depende mucho del método de entrega de nuestros chunks. Así que usualmente los chunks que conoces son como chunks de JavaScript, los entregas a través de etiquetas de script.

Eso significa que lo que hacemos o lo que hacen muchos bundlers es que ponen muchos módulos en un chunk pero no los ponen como módulos, básicamente los envuelven en closures para hacerlos como fábricas de módulos y eso básicamente significa que registramos todas las fábricas de módulos al cargar el chunk en un código de tiempo de ejecución en la página y luego el tiempo de ejecución puede decidir cuándo ejecutarlo. Eso es realmente importante aquí, el aspecto de carga está separado del aspecto de ejecución. Así que podemos cargarlo en un momento y luego ejecutarlo más tarde o no ejecutarlo en absoluto. Y eso nos da muchos beneficios.

Un ejemplo, el orden de los módulos en el chunk no importa, puedes simplemente ponerlo en cualquier orden. También podríamos duplicar fábricas de módulos para que podamos poner un módulo en un chunk y otro chunk. Se registrará dos veces en un momento pero no se ejecutará dos veces porque el tiempo de ejecución se encarga de ejecutarlo cuando realmente lo necesita y solo ejecutarlo una vez. También podemos sobreenviar módulos, básicamente sobreenviar significa que pones un módulo allí en un chunk que en realidad no se necesita pero solo sería la transferencia para hacer el chunking más eficiente. Y eso también posiblemente registre la fábrica de módulos en un momento pero nunca lo ejecutará. Eso está totalmente bien.

Se vuelve más complicado cuando miras otros métodos de entrega como CSS. CSS se entrega a través de etiquetas de enlace y las etiquetas de enlace no son una lista de, no es un contenedor, los archivos CSS no son un contenedor de fábricas de módulos, son básicamente una lista de reglas CSS que se cargan en orden y en orden cuando cargas tus archivos CSS. Así que ahora todo es realmente global y tiene efectos secundarios y el orden importa lo que hace que muchas cosas sean más complicadas. El orden importa de las cosas así que necesitamos averiguar en qué orden colocamos los módulos en estos chunks. Ya no puedes duplicar módulos porque si duplicas reglas de estilo básicamente aparecen en dos órdenes diferentes, eso rompe las cosas.

A veces puedes hacer overshipping de módulos, depende del tipo de estilos que tengas. Si tienes módulos CSS y están aislados, no tienen efectos secundarios, entonces puedes hacer overshipping de ellos, pero si tienes CSS global, generalmente tiene efectos secundarios o podría tener efectos secundarios en tu código y por lo tanto no está bien simplemente cargarlo cuando el usuario no lo solicitó. Así que en resumen, el CSS es súper fácil de chunkear, tienes toda la libertad para hacerlo, pero el CSS hace que todo sea súper difícil. Y especialmente por el orden. Así que cuando el orden importa, es un problema difícil y, sí.

¿Cómo averiguar el orden de colocación de los archivos CSS en tus chunks en primer lugar? Podrías simplemente pensar, podríamos simplemente hacer lo que dicen las importaciones, básicamente el orden de importación es el orden de carga del CSS, eso funciona bien siempre que solo tengas un solo grupo de chunks. Así que si solo tienes una sola página, sin importaciones asíncronas y esas cosas, eso funciona bien porque entonces hay un orden de importación definido.

Pero cuando tienes múltiples grupos de chunks y múltiples grupos de chunks se cargan en cualquier orden, no sabemos qué página es visitada primero por el usuario y esas cosas, podrían cargarse todas al mismo tiempo, la página y la importación asíncrona se cargan al mismo tiempo. Y entonces en este caso, hay múltiples órdenes de importación definidas de todos estos grupos de chunks y en la práctica siempre hay conflictos entre ellos, no es posible tener siempre el mismo orden de importaciones.

Así que ese enfoque no funcionó. El siguiente enfoque podría ser como decimos, pedimos al usuario que sea explícito sobre las dependencias entre archivos CSS, podría ser usando add import en un archivo CSS. Pero en la práctica, nadie hace eso y le gusta eso y es súper poco práctico y el CSS existente no funciona con eso, así que no funciona.

Podrías intentar analizarlo desde el CSS, el uso de JavaScript, cómo se usa el CSS, pero es demasiado complicado y tampoco es realmente posible. Así que ideamos un enfoque llamado dependencias implícitas, así que analizamos toda la aplicación, miramos todos los grupos de chunks a la vez y vemos si vemos algo que el módulo A o CSS A siempre se usa antes que el módulo B en todos los grupos de chunks, entonces decimos oh, esto probablemente es alguna dependencia que codifica que creemos que está ahí y lo extraemos y luego vemos como B depende de A. Eso es bastante genial porque obtienes un gráfico de dependencias limpio, no hay ciclos, así que es fácil llegar a un orden a partir de eso.

Pero en la práctica, también hay problemas con eso. Un ejemplo es lo que siempre es un problema aquí. Así que si dices que siempre necesitas que se extraigan las dependencias. Así que si tienes 1,000 páginas que usan A, B como orden y luego tu nuevo interno viene aquí y crea una nueva página que tiene un orden opuesto, esperas que solo esta página se rompa pero en realidad porque vemos que no siempre se usa en ese orden, no extraemos esta dependencia y luego toda tu aplicación puede romperse debido a eso. Así que eso tampoco es un problema. Así que el siguiente enfoque sería básicamente extraer el orden más común de uso del CSS.

Como si muchas páginas usan A, B como orden y solo algunas páginas usan B, A, entonces decimos que A, B gana y eso suena bien, pero también es realmente complicado debido a que tienes que construir un gran gráfico de todos los órdenes de todos los CSS en tu aplicación y luego hacer algunos análisis de ciclos extraños para romper todos los ciclos y averiguar qué dependencias se usan con más frecuencia.

Pero supongamos que todo eso funciona y tenemos algún tipo de orden extraído de tu aplicación. Ahora tenemos que dividirlo considerando esta cuestión de orden. Si tienes nuestros dos ejemplos aquí de nuevo, página legal y página de precios. La página legal tiene un CSS global, un CSS específico de la página legal en el pie de página y la página de precios tiene el mismo CSS global y algunos archivos CSS específicos de la página de precios.

Ves, si quieres mantener el orden siempre correcto, tienes que dividirlo en muchos chunks. Básicamente tienes que dividirlo con demasiada frecuencia, lo que causa en la práctica, causa muchas solicitudes y para aplicaciones reales con como miles de grupos de chunks, básicamente causó que casi cada archivo CSS sea un chunk separado. Así que eso realmente no funciona. Causa demasiadas solicitudes, lo que realmente no funciona para tu aplicación. Y el problema con eso es que realmente, usualmente en el mundo de JavaScript, podrías simplemente duplicar módulos para resolver para reducir la solicitud. Pero debido a que CSS depende del orden, no podemos hacer eso. Así que nuestra herramienta principal para reducir el conteo de solicitudes se ha ido y tenemos que idear una nueva herramienta para eso.

Y la nueva herramienta que ayuda aquí fue el overshipping, así que podemos, como podemos, overship módulos. Así que incluir módulos adicionales en chunks que no los necesitan para reducir el conteo de solicitudes porque entonces pueden ser reutilizados más a menudo. Y eso funciona muy bien. Por ejemplo, podríamos técnicamente reducir toda la aplicación a un solo chunk mediante el overshipping de mucho CSS. Así que se reduciría a solo una solicitud de eso, pero también podemos ser más granulares. También puedes moverlo un poco. Y hay básicamente muchos enfoques que puedes encontrar un umbral correcto de chunking. Nuevamente, es una heurística entre el tamaño de descarga y el conteo de solicitudes. Puedes equilibrar entre menos conteo de solicitudes, más tamaño de descarga o menos tamaño de descarga y más conteo de solicitudes. Y vuelve a ser como encontrar una heurística para resolverlo.

En la práctica, funciona bien porque a menudo cuando tienes muchos archivos CSS, a menudo son muchos módulos CSS. Y los módulos CSS están aislados, por lo que podemos overship ellos. Y también son a menudo pequeños, lo que significa que no es tan malo si los overship. No causa tantos problemas. Sí. Y todo este acto de equilibrio está nuevamente impulsado por heurísticas. Así que la conclusión de eso, realmente odio el ordenamiento de CSS. Ha causado tantos problemas en el pasado y como durante años ahora. Y no lo considero resuelto desde esa perspectiva. Como todo el asunto del ordenamiento siempre es problemático. Pero en general, también veo mucho potencial, un potencial futuro de más optimizaciones que podemos hacer con el chunking.

Un ejemplo, podríamos, actualmente establecemos cada grupo de chunks como independiente y igualmente en este sentido de chunking, pero este no es el caso. Tal vez tu página de inicio es más importante que tu panel de administración y quieres optimizar eso. Tal vez podamos dar pistas a los bundlers que ayuden con la optimización, rutas especiales o como darnos más margen en el proceso de optimización. También podríamos ser más genéricos al simplemente usar datos analíticos de un sistema de producción para averiguar qué tan probable es que los usuarios visiten nuestros grupos de chunks o páginas y optimizarlos basados en eso. Así que si la página de inicio es la página más visitada, entonces tal vez deberíamos darle la mayor prioridad en la optimización.

Sí. Así que gracias. Sí, tengo otro, me quedan dos minutos, así que puedo entrar con algunas cosas adicionales. También es realmente complicado, como tal vez, pero otra cosa interesante con el chunking es también el tiempo de compilación. Porque, como tienes este problema de que haces eso, haces, como, tal vez tienes este ejemplo aquí, tengo un gráfico de módulos, que como dos páginas están usando una importación asíncrona compartida. Así que si vuelves, vas desde el lado izquierdo aquí desde la página legal y lo divides, podría crear estos chunks azules. Pero si vas desde el lado derecho y lo divides, podría crear como diferentes chunks para esta importación asíncrona. Así que aquí ves que el módulo rojo solo se usa en el punto de entrada de la página izquierda. Así que no necesita ser dividido para esa versión, pero necesita ser dividido para la otra página. Así que eso crea muchos problemas con el tiempo de compilación. Porque ahora podríamos hacer lo que hizo Wepek, como el peor caso, chunking en grupo. Así que simplemente dividimos el peor caso de esta importación asíncrona compartida. Eso funciona bien, pero básicamente, como, lo sobreenvía, o para la página izquierda, sobreenvía este módulo rojo. Así que no es perfecto en cuanto al tamaño de descarga. Pero también podrías hacer este trazado de todas las rutas, donde básicamente creas dos chunks para estas importaciones asíncronas y eliges lo que quieras, lo que mejor se adapte, dependiendo de desde qué página vienes. Pero esto crea un problema de, como ... Este es realmente un pequeño ejemplo. Solo crea dos rutas para esta aplicación. Pero en la práctica, si implementas esto de esta manera, básicamente tienes que trazar todos tus posibles caminos a través de tu aplicación, y podría crear realmente cosas extrañas ... Si tienes 10 importaciones asíncronas anidadas y un ciclo con otras 10 importaciones dinámicas, básicamente multiplica todo eso y crea mucho trabajo, crea muchos archivos de salida, crea mucho trabajo para el empaquetador. Así que también hay una métrica sobre las consideraciones de tiempo de compilación sobre cómo divides las cosas. Así que hay muchas cosas a considerar cuando haces chunking. Sí. Gracias.

Con el auge de los componentes de servidor de React y los frameworks impulsados por servidor como Next.js, ¿cómo ha evolucionado la estrategia para el chunking? ¿Estamos trasladando la complejidad de la división de código del lado del cliente de nuevo al servidor? Sí, eso es algo que no consideré para esta charla. Los ejemplos eran solo como un Motograph simple, pero en la práctica, como, el Motograph contiene componentes de cliente y componentes de servidor. Así que todo está mezclado en un solo Motograph para hacer chunking a través de los límites de servidor y cliente, lo que crea muchos problemas y muchos desafíos. Y sí, creo que muchas cosas han cambiado, pero tampoco somos óptimos en cuanto al chunking del lado del cliente. Actualmente, siempre dividimos todos los componentes del cliente en la página, incluso si no es necesario. Pero técnicamente, hay muchas cosas dinámicas desde allí.

Así que el servidor decide qué componentes del cliente enviar. Podría ser como cualquier combinación de componentes de chunk que tengas que encontrar en la aplicación. Así que es como un proceso complicado. Creo que hay mucho potencial futuro para optimizar eso haciéndolo más inteligente, cómo dividir estos componentes del cliente para que sea posible no solo transferir componentes del cliente que realmente necesitas. Así que es como, hay mucha complejidad que aún no hacemos, pero hay mucho potencial futuro para hacer más optimizaciones aquí. Genial. Gracias.

El siguiente aquí, digamos, respecto a resolver el orden de CSS, si hay cinco clases donde A depende de B, y cinco clases donde B depende de A, ¿cuáles son los resultados del chunking? Básicamente no es para demostrar, ya que actualmente implementamos este enfoque tres, donde se espera estas dependencias implícitas. Y en este caso, si no siempre es el caso, básicamente está en cualquier orden. Así que no está definido. Necesitamos obtener algo de libertad del gráfico de módulos para decidir no tener que dividir cada módulo en un solo chunk. Así que lo distribuimos como podemos decidir en qué orden está y luego está en cualquier orden, básicamente, para el usuario. Eso es lo que más a menudo causa algunos problemas si esto es un problema. El problema es que está en cualquier orden, pero de alguna manera es determinista. Así que podría estar en este orden durante un año, y luego cambias algún código que técnicamente es independiente de eso, y eso afecta eso, y luego tal vez el orden cambia. Y eso podría romper tu aplicación de maneras extrañas. Así que eso es complicado. Muchos problemas complicados aquí.

¿Crees que los bundlers eventualmente se convertirán en infraestructura invisible, o los desarrolladores siempre necesitarán entender los gráficos de dependencias y las tuberías de construcción? Yo diría que ya es mayormente infraestructura invisible. Pero creo que sigue siendo valioso para el desarrollador conocer los conceptos. Por eso estoy tratando de explicar muchos de ellos. Y espero que sea mayormente transparente para ti, y no tengas que entenderlo y simplemente funcione, pero a menudo es genial entenderlo y ayuda en general. ¿Cómo vas a lograr que la gente lo entienda si ni siquiera leen su código estos días? Sí. No estoy seguro de lo que el mundo de la IA dice sobre eso. Sí, sí. De acuerdo. Sí, tal vez una atención a eso. Tratamos de ofrecer muchas herramientas para inspeccionar la salida, como tenemos un bundlerizer que te da mucha información sobre tu salida de empaquetado. Mayormente no es el chunking lo que es relevante, sino el gráfico de módulos que estás mirando y qué módulos enviar. Y creo que hay valor en mirar eso y entender por qué tu aplicación es tan grande o por qué estás enviando cualquier biblioteca grande cinco veces en diferentes versiones por ahí.

Así que intentamos ofrecer más herramientas para eso y también dar más acceso a la IA a estas herramientas para poder resolver estos casos y analizar sus cosas. Genial. Creo que esto sería, ¿cuál sería el orden de lo no importante... De acuerdo. Lo siento. Me cuesta leer este. ¿Sería el orden no importante para CSS cuando usas clases utilitarias como Tailwind? Tailwind es una buena solución a este problema de chunking u ordenamiento de CSS, porque básicamente CSS toma tu aplicación y genera un solo archivo CSS desde la perspectiva de Bundler. Así que un solo archivo CSS, y por lo tanto, el orden no es importante porque es un solo archivo desde nuestra perspectiva. Y Tailwind básicamente maneja el orden ellos mismos teniendo solo un orden fijo de estas clases que ocurren en ese orden. Así que eso es bastante bueno desde nuestra perspectiva, porque entonces no tenemos que preocuparnos por el orden nuevamente y también ayuda con eso. Así que Tailwind es la solución, o una solución, solución, solución/solución para este problema de ordenamiento. Y sí, todas las soluciones de CSS atómico son básicamente eso en ese sentido. Tiene compensaciones, de nuevo. Tailwind, porque hace un solo archivo, básicamente rompe todo tu tree-shaking. Así que obtienes solo las clases que usas en tu aplicación, pero no es específico de la página, no es específico del grupo de chunks. Así que en tu página de inicio, ahora estás cargando todas las clases CSS que necesitas en tu panel de administración, y eso tampoco está optimizado. Así que es una compensación de nuevo. Como siempre, todo es una compensación. Sí, correcto. Sí, exactamente. ¿Has explorado la ordenación topológica para el ordenamiento de CSS frente al conteo de solicitudes? Sí, así que hacemos ordenación topológica después de que determinamos un gráfico no cíclico de eso. Así que lo primero es obtener un gráfico no cíclico para hacer la ordenación topológica. Pero si tienes múltiples grupos de chunks, no tienes un gráfico no cíclico en primer lugar. Las diapositivas que estaba mostrando básicamente te muestran el proceso para determinar un gráfico no cíclico, y luego en este gráfico, hacemos la ordenación topológica, pero es bastante simple entonces. ¿Qué hay de las capas en CSS? Así que ahora dice que las capas están ampliamente disponibles en CSS, ¿no podrían ayudar a optimizar enormemente CSS? Pensé lo mismo, y lo intentamos, y no funcionó, porque las capas, si pones cada módulo CSS en su propia capa, y luego solo haces el ordenamiento en las capas, rompe todas estas cosas de preferencia de selectores CSS, porque entonces básicamente no funciona más, porque no puedes estilizar algo teniendo diferentes precedencias de selectores y esas cosas, así que rompe ese tipo de cosas. Así que las capas, lamentablemente, no funcionaron. Pensé lo mismo, y lo implementamos, de hecho, pero luego descubrimos que no funciona. Sí, es increíble que tengas que abordar todos estos problemas y bajar. Esto es tanta complejidad, ¿verdad? Veamos. En cuanto al orden de CSS, ¿qué tan común es el problema si escribes bien tus estilos, o tienes ejemplos comunes que afectarían a la mayoría de las personas? Sí, así que si estás usando el enfoque 3 actualmente por defecto, y eso depende de que escribas bien tus estilos, y funciona si escribes bien tus estilos, pero, sí, ese es un problema.

Pensé que un error podría romperlo todo. Si, en algún momento, en alguna página, como en tu aplicación de 1,000 páginas, no lo escribes bien, entonces podría romperse y podría afectar a otras páginas, y eso es algo que no queremos. Actualmente hacemos eso, pero tiene problemas, y no diría que está servido, pero algunas personas se encuentran con eso y rompieron su aplicación, y nosotros también lo hicimos. Por eso busco más soluciones para eso.

Sí, podemos hacer uno más aquí. Déjame ver. Si el ordenamiento de CSS es fundamentalmente un problema de gráfico de dependencias, ¿crees que las futuras características de CSS deberían proporcionar declaraciones de dependencia nativas en lugar de depender de herramientas para inferirlas? Quiero decir, ya proporcionamos eso. Add, import, existen en CSS. Simplemente no lo usamos. Creo que lo que realmente ayudaría es algo donde no dependas del orden en absoluto. Hubo una propuesta para eso para Web Components, creo, pero no fue aceptada o algo así. Sería genial si obtienes una solución de estilo que no dependa del orden. Eso sería genial. Creo que muchas personas estarían contentas con eso.

Bueno, muchas gracias, Tobias. Sí, gracias por invitarme. Excelente charla.