Chunking

Mi nombre es Tobias Koppers, trabajo en Vercel como el equipo de TurboPack, y hoy otro tema de Bundler, chunking. Entonces, ¿qué es el chunking en absoluto? Así que 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 grafo 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 grafo de módulos, uno realmente pequeño para este caso. Así que tenemos un montón de módulos, estos puntos blancos, y estos módulos usualmente están conectados a través de dependencias, como un import o un require o un import asíncrono, y estos son los bordes del grafo. Y me di cuenta de un borde realmente especial aquí, porque es realmente especial para el chunking, es este rojo punteado. Eso es un import asíncrono, como un import dinámico o algo así, donde cargas algo bajo demanda.

Y también, usualmente, tu grafo de módulos tiene muchos puntos vacíos, tal vez tus páginas o esas cosas. Y aquí, las páginas más importantes de una aplicación son, 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 ciclado juntos se colocan en un archivo de salida. Y un ejemplo, como este import asíncrono aquí en el lado izquierdo, con la cosa punteada roja, la cosa punteada, se coloca en sus propios chunks para que podamos cargarlo bajo demanda.

Y tenemos todos los puntos de entrada siendo sus propios chunks, porque entonces podemos cargarlos independientemente de las otras páginas. Y también puedes, como en este ejemplo, poner el área media 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 maneras diferentes de ciclar estos módulos. Y sí, ese es el proceso de chunking, no de ciclado. Y cómo hacer chunking de una buena manera.

Además, 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 influyen en cómo dividimos las cosas en chunks. Y antes de que miremos las métricas, queremos mirar otro término, y ese es grupos de chunks. Y digo que los grupos de chunks son básicamente un conjunto de chunks que se cargan juntos. Eso podría ser en una carga inicial de página, cargas como estos 10 chunks en etiquetas de script, y ese es un grupo de chunks de carga inicial. Pero también hay otros tipos de grupos de chunks. Como en una importación dinámica, hay como un grupo 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, y 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 de salida que produce el bundler. Pero el tamaño total de esa carpeta rara vez 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 como el tamaño de descarga por grupo de chunks.

Y de manera 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 HTTP2 todavía hay un overhead, solo que menos que antes, pero aún así no es bueno cargar como millones de chunks, millones de archivos en tu aplicación. Y ahora ya tenemos dos métricas.

Y si miras un ejemplo, aquí hay uno realmente pequeño, tengo dos páginas, A y B. Y ambas comparten como un módulo compartido. Y ahora puedes idear como diferentes estrategias para hacer chunking aquí. Así que una estrategia podría ser poner módulos específicos de página en los chunks de página, como el azul y el verde, y luego hacer un chunk común donde pones como los módulos compartidos en él.

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 cargas como una sola solicitud y no la página B. Suena bien. Pero también hay otra estrategia, como podrías duplicar los 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, como la compresión generalmente funciona mejor si tienes chunks más grandes. Si lo divides, es básicamente peor en términos de compresión. Pero ahora tienes el problema, si navegas de la página A a la página B, descargas el módulo compartido nuevamente. Así que básicamente desperdicias un poco de tamaño de descarga en esa navegación. Así que es básicamente un compromiso, y ese es básicamente el esquema principal aquí.

Pero hay más métricas, y otra métrica es el almacenamiento en caché a largo plazo. Y especialmente lo menciono 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 recurrente de tu aplicación, un usuario que estuvo allí antes del cambio de código y ahora después, regresa. Significa que tienen que descargar estos chunks cambiados nuevamente, y significa que tienen que volver a descargar todos los módulos que terminaron en estos chunks.

¿Y cómo puedo afectar eso? 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 almacenamiento en caché porque menos módulos han sido re-descargados, tienen que ser re-descargados. 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 generalmente cambian juntos, 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 proveedor en vendor.js. Ahora el código de aplicación que cambia frecuentemente invalida app.js, y solo eso está cambiando, y el archivo vendor.js solo se invalida o tiene que ser re-descargado por el usuario si estás haciendo una actualización de dependencia, lo cual esperas hacer mucho.

Así que ves, hay muchos compromisos. Podrías hacer más, chunks más pequeños. Eso significa mejor almacenamiento en caché, pero más solicitudes. Podrías hacer menos, chunks más grandes, eso son menos solicitudes y peor almacenamiento en caché. Puedes duplicar módulos, eso significa que tienes menos solicitudes, pero tienes una descarga más grande en algunos casos. Así que básicamente no hay un chunking perfecto que puedas hacer. Básicamente hay muchos compromisos que debes considerar. Y a veces también es realmente costoso calcular todas estas heurísticas en una aplicación realmente grande porque hay muchas 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 entregamos a través de etiquetas de script. Y 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 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. Y eso es realmente importante aquí, como el aspecto de carga está separado del aspecto de ejecución.

Así que podemos cargarlo en un punto 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, así que podemos poner un módulo en un chunk y otro chunk. Se registrará dos veces en el tiempo de ejecución, pero no se ejecutará dos veces, porque el tiempo de ejecución está en el caso de ejecutarlo cuando realmente lo necesita y solo ejecutarlo una vez. También podemos sobreenviar módulos, así que 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 es posible, registras la fábrica de módulos en el tiempo de ejecución 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... 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 en el que 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. Así que el orden importa de las cosas, por lo 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 sobreenviar módulos, depende del tipo de estilos que tengas. Si tienes módulos CSS, están aislados, no tienen efectos secundarios, entonces puedes sobreenviarlos pero si tienes CSS global, generalmente tiene efectos secundarios o podría tener efectos secundarios en tu código, por lo que no está bien simplemente cargarlo cuando el usuario no lo solicitó. Así que en resumen, CSS es súper fácil de dividir en chunks, tienes toda la libertad para hacerlo, pero CSS hace que todo sea súper difícil. Y especialmente por el orden. Y así cuando el orden importa, es un problema difícil. Entonces, ¿cómo averiguar el orden de colocar archivos CSS en tus chunks en primer lugar?

Podrías simplemente pensar, podrías simplemente hacer lo que dicen las importaciones, básicamente el orden de importación es el orden de carga de CSS. Eso funciona bien, siempre y cuando solo tengas un solo grupo de chunks, 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 todas cargarse al mismo tiempo, como la página y la importación asíncrona se cargan al mismo tiempo. Y así en este caso, hay un orden de importación múltiple definido 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ó. Entonces, 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 at 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 analizar eso 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 importaciones llamadas 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, y en todos los grupos de chunks, entonces decimos, oh, esto es probablemente alguna dependencia en el código que creemos que está ahí y extraemos eso y luego vemos como, B depende de A. Y eso es bastante genial porque obtienes un gráfico de dependencias limpio. No hay ciclos, por lo que es fácil idear 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, si tienes 1,000 páginas que usan A, B como orden y luego tu nuevo becario viene aquí y crea una nueva página que tiene un orden opuesto, esperas que solo esta página esté rota. 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 una, tiene problemas. Y así, el siguiente enfoque sería básicamente extraer el orden más común de CSS siendo Si muchas páginas usan A, B como orden y solo algunas páginas usan B, A, entonces decimos que A, B gana.

Sí, pero supongamos que todo funciona. Y tenemos algún tipo de orden extraído de tu aplicación. Ahora tenemos que dividirlo considerando este orden. Así que si tienes nuestros dos ejemplos aquí de nuevo, página legal y página de precios, y como la página legal tiene un CSS global, un CSS específico del espacio legal y un pie de página y la de precios es como el mismo CSS global y algunos archivos CSS específicos de la página de precios. Y ves que, si quieres mantener el orden siempre correcto, tienes que dividirlo en muchos chunks. Básicamente tienes que dividir demasiado a menudo, lo que causa en la práctica, que haya muchas solicitudes. Y para aplicaciones reales, son como miles de grupos de chunks. Básicamente cuesta 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 es que realmente, usualmente en JavaScript, podríamos simplemente duplicar módulos para resolver eso, para reducir las solicitudes. Pero como CSS es auto dependiente, no podemos hacer eso. Así que nuestra herramienta principal para reducir el número 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, podemos enviar de más módulos. Así que incluir módulos extra en chunks que no los necesitan para reducir el número 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 enviando de más mucho CSS. Y así 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 como luchar un amplio umbral de chunking. Nuevamente, es una heurística entre el tamaño de descarga y el número de solicitudes. Puedes equilibrar entre menos número de solicitudes, más tamaño de descarga o menos tamaño de descarga y más número de solicitudes. Y se trata de 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 enviar de más. Y también son a menudo pequeños, lo que significa que no es tan malo si los envías de más. No causa tantos problemas.

Y todo este acto de equilibrio está nuevamente impulsado por heurísticas. Así que la conclusión de eso, realmente odio el orden de CSS. Ha causado tantos problemas en el pasado y como durante años ahora. Y no lo considero como resuelto desde esa perspectiva. Como todo el asunto del orden siempre es problemático.

Pero en general, también veo mucho potencial, un potencial futuro de más optimizaciones que podemos hacer con chunking. Un ejemplo, podríamos como 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 sea más importante que tu panel de administración y quieras como optimizar eso.

Tal vez podamos dar pistas a los bundlers que ayuden con la optimización de rutas especiales o como dar más peso a esto 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 nuestras páginas y optimizarlos basados en eso. Así que como si la página de inicio es la página más visitada, entonces tal vez deberíamos darle eso la máxima prioridad y optimización. Sí. Así que gracias. Sí. Me quedan dos minutos, así que puedo comentar con algunas cosas extra.

También es realmente complicado, como tal vez otra cosa interesante con chunking es el tiempo de compilación también. Porque como tienes este problema de que haces eso, haces como tal vez tienes este ejemplo aquí, tengo un Motograph, 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 en chunks, podría crear estos chunks azules. Pero si vas desde el lado derecho y lo divides en chunks, podría crear 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 en chunks para esa versión, pero necesita ser dividido en chunks 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 Repec, como el peor caso de chunking. Así que simplemente dividimos en chunks el peor caso de esta importación asíncrona compartida. Eso funciona bien, pero básicamente como que sobreenvía, 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 como este trazado de todos los caminos, donde básicamente creas dos chunks para esta importación asíncrona y eliges lo que mejor se adapte, dependiendo de desde qué página vienes. Pero esto crea un problema de como, este es un ejemplo realmente pequeño, solo crea como dos palabras para esta aplicación. Pero en la práctica, como 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 como crear realmente raro, si tienes como 10 importaciones asíncronas anidadas, entonces tienes un ciclo con como otras 10 importaciones dinámicas que básicamente multiplican todo eso y crean mucho trabajo, crean muchos archivos de salida, crean mucho trabajo para el bundler. Así que también hay como una métrica sobre consideraciones de tiempo de compilación sobre cómo divides en chunks las cosas.

Así que 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 chunking? ¿Estamos trasladando la complejidad de la división de código del lado del cliente de vuelta 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. Así que haces chunking a través de los límites del servidor y del cliente, lo que crea muchos problemas y como muchos desafíos. Y sí, creo que muchas cosas han cambiado, pero también como no somos óptimos con respecto al chunking del lado del cliente. Actualmente, dividimos en chunks todos los componentes del cliente en la página, incluso si no es necesario. Pero técnicamente, hay muchas cosas dinámicas desde allí. El servidor decide qué componentes del cliente enviar. Podría ser como cualquier combinación de componentes divididos en chunks que realmente tienes 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 en chunks estos componentes del cliente para que sea posible no solo transferir los 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.

Muy bien. Tenemos otro aquí. Digamos que 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 disminuir. Actualmente implementamos esta parte tres, donde se están extrayendo estas dependencias implícitas. Y en este caso, si no siempre es el caso, es básicamente en cualquier orden. Así que no está definido. Necesitamos obtener algo de libertad del grafo de módulos para decidir no tener que dividir cada módulo en un solo chunk. Así que lo establecemos como que podemos decidir en qué orden está. Y luego está en cualquier orden básicamente para el usuario que a menudo causa algunos problemas si esto es un problema.

Es 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 lo afecta. 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? Ya lo he visto mayormente como 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? No estoy seguro de lo que el mundo de la IA dice al respecto. Sí. Muy bien. Tal vez una atención a eso. Así que intentamos ofrecer muchas herramientas para inspeccionar el resultado, como tenemos un analizador de paquetes que te da mucha información sobre tu salida de empaquetado. Principalmente no es el chunking lo que es relevante, sino como el grafo de módulos que estás viendo y qué módulos enviar. Y creo que hay valor en mirar eso y ver, 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 como resolver estos casos y analizar sus cosas.

¿Sería el orden... Creo que esto sería lo que sería el orden de no importante... Bien. 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 para este problema de chunking o orden de CSS. Porque básicamente CSS toma tu aplicación y genera un solo archivo CSS desde la perspectiva del Bundler. Así que como un solo archivo CSS y por lo tanto ningún orden 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 para este problema de orden. Y sí. Todas las soluciones de CSS atómico son básicamente eso en ese sentido. Pero tiene compensaciones nuevamente. Como Tailwind, básicamente 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 como 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 como una compensación nuevamente. Es como siempre, todo es una compensación. Sí.

Sí. Exactamente. Así que exploraste la ordenación topológica para el orden de CSS frente al conteo de solicitudes. {{^}}Sí. Así que hacemos la ordenación topológica después de que determinamos un grafo no cíclico de eso. Así que la primera necesidad es básicamente un grafo no cíclico para hacer la ordenación topológica. Pero si tienes múltiples grupos de chunks, no tienes un grafo no cíclico en primer lugar. Así que las diapositivas que estaba mostrando básicamente te muestran el proceso para determinar un grafo no cíclico, y luego en este grafo hacemos la ordenación topológica, pero es bastante simple entonces.

¿Qué hay de las capas en CSS? Así que ahora se dice que las capas están ampliamente disponibles en CSS, ¿no podrían ayudar a optimizar enormemente el CSS? Pensé lo mismo. Y lo intentamos y no funcionó porque las capas, si pones cada módulo CSS en una capa propia y luego solo haces la ordenación en esas capas, rompe toda esta preferencia de selectores CSS porque entonces básicamente ya no funciona. Porque no puedes estilizar algo con 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í, por eso tienes que abordar todos estos problemas y profundizar. Es tanta complejidad, ¿verdad?

Veamos. Con respecto 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 estamos 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 el problema. Pensé que un error puede romperlo todo. Si, en algún momento, en alguna página, como en tu aplicación de 1000 páginas, no lo escribes bien, entonces podría romperse y podría afectar a otras páginas y eso no es lo que queremos. Actualmente hacemos eso, pero tiene problemas. Y no diría que es como surf, pero algunas personas se encuentran con eso y rompieron la aplicación y nosotros también lo hicimos. Y por eso estoy buscando más soluciones para eso. Sí, podemos hacer uno más aquí.