Rspack Recientemente Fue Premiado como Avance del Año en JSNation

♪♪♪ Muy bien, bueno, gracias por venir a mi charla. Bien, entonces primero, ¿alguien sabe qué es RSPack? No puedo ver a nadie, así que... Bien, genial. Entonces, alguien sí lo sabe. Para aquellos de ustedes que no saben qué es, es esencialmente una reescritura de Webpack en Rust que terminamos haciendo. Así que, realmente, de lo que voy a hablarles hoy, ya que estoy en JS Nation, la conferencia de Ámsterdam, RSPack de hecho ganó Breakthrough of the Year, así que pensé que sería una oportunidad fantástica para hablar un poco sobre la razón detrás de su creación.

Entonces, solo un poco de contexto sobre cómo se ve WebInfra en ByteDance en términos de su escala es, uno, tenemos que mantener un conjunto muy vasto de herramientas, frameworks, sistemas que soportan todas las funciones comerciales de la empresa. Tenemos aproximadamente más de 1,000 aplicaciones únicas de aplicaciones web o nativas. Tenemos decenas de miles de front-ends, y hacemos decenas de miles de despliegues en producción cada semana. Así que, en general, hay bastante rendimiento y mucha presión en todo lo relacionado con la infraestructura. Y nuestro trabajo, realmente, es unificar la DX de prácticamente todo en soluciones centrales que puedan funcionar para varias funciones del negocio. Así que, eso es un poco de contexto sobre lo que hacemos.

Entonces, una de las cosas es que hay muchas complejidades en las herramientas de construcción subyacentes y en el tipo de stacks con los que tenemos que trabajar. Así que, lo que hemos descubierto a lo largo del camino es que las operaciones, específicamente entre, digamos, código abierto versus operaciones internas, tienen algunas diferencias clave. Las principales que hemos visto son generalmente, diría yo, solo la complejidad del negocio que tenemos que soportar es generalmente mayor de lo que verías en tus típicos proyectos de código abierto. El alcance de la responsabilidad, también, es bastante diferente. De lo que a menudo vemos en un proyecto de código abierto es que generalmente tendrías un tipo de enfoque único. Así que, si pensamos en Next.js, es principalmente para web, SSR, o React Native, que obviamente se centra en aplicaciones nativas. Pero necesitamos soportar un ecosistema realmente vasto que pueda impulsar varias funciones del negocio y buscar herramientas que realmente hagan eso bien en su conjunto. Diría que probablemente la mayor diferencia, sin embargo, que hemos visto son las obligaciones de guardia. Típicamente, en código abierto, no hay obligación de guardia. Abres un problema en git, y podría ser respondido, y así sucesivamente. Pero para nosotros en el equipo de Inver, considerando que soportamos, creo, 150,000 empleados actualmente, tenemos una expectativa realmente alta de cerrar estas guardias, mientras que, ya sabes, la mayoría de ellas se resuelven dentro de las 24 horas, y casi cualquier cosa, en cualquier lugar, se resuelve dentro de una semana. Así que, eso es una demanda y presión bastante alta.

Entonces, ¿por qué terminamos buscando escribir un empaquetador personalizado? Entonces, uno, las cosas se estaban complicando. Muchas de estas diversas herramientas, ecosistemas, productos, diseñados para soportar funciones muy diferentes del negocio, desde sistemas nativos hasta sistemas embebidos hasta desarrollo de hardware personalizado, web, web híbrida, y así sucesivamente, continúa creciendo. Encontrar una solución adecuada fue bastante complicado, especialmente si estamos buscando cosas que funcionen realmente, realmente bien con nativos, que sean rápidas y eficientes, pero también, quizás, funcionen en entornos muy exóticos. No sé si alguien ha trabajado alguna vez con una aplicación de WeChat o algo así, pero no están basadas en JavaScript, así que estás escribiendo módulos JSON, y necesitarías un compilador que pueda emitir, esencialmente, JSONs en lugar de emitir JavaScript. Así que, realmente, también tuvimos que intentar trabajar dentro de entornos exóticos. Así que, obviamente, lo que estamos buscando es algo que vaya a soportar el negocio realmente bien, algo que sea estable, algo que vaya a ser eficiente, algo que pueda escalar, especialmente a medida que el número de productos bajo el portafolio continúa creciendo. Y un gran desafío que habíamos visto es que muchas de nuestras obligaciones de guardia generalmente iban a depurar problemas en la construcción, así que tratar de reducir esa presión de guardia fue muy crítico para nosotros. Entonces, ¿cómo comenzó realmente RSPack? En realidad, comenzó con algo que llamamos Link Speedy, que es esencialmente nuestra solución de desarrollo multiplataforma interna. Creo que lo estamos haciendo de código abierto en 2025, a principios de 2025. Estamos planeando hacerlo de código abierto. Pero los orígenes de RSPack realmente comenzaron aquí con Links. Inicialmente, lo que era en realidad, era solo llamado Speedy, y era básicamente un plugin de ES Build, y eso era todo.

Y funcionó realmente bien al hacer que nuestras aplicaciones multiplataforma se construyeran muy rápidamente. Estas aplicaciones no tenían muchas restricciones en ese momento debido a cómo Links fue construido. No soportábamos algo, digamos, como la división de chunks o cosas así en ese momento. Así que era fácil simplemente enviar una gran carga útil de una sola vez, y Speedy hizo un muy buen trabajo. Sin embargo, cuando comenzamos a intentar usar Speedy en algo como PIA, que es nuestro tipo de framework web-slash-native, en lugar de completamente nativo, nos encontramos con grandes problemas allí, principalmente porque ES Build crearía demasiados chunks granulares, y HMR y otros tipos de, ya sabes, problemas de cascada comenzaron a impactar la producción, ya sabes, la optimización que el usuario experimentaría, así como veríamos desafíos con, como, HMR y cosas así, como, ya sabes, creo que la base de código promedio es como 50,000 módulos o más. Así que se volvió un poco desafiante.

Así que lo que terminamos haciendo es mirar, bien, dado que esto no está funcionando, tal vez necesitamos buscar una solución más personalizada. Así que pasó de Speedy y realmente se transformó en lo que RSPack parece hoy. Así que cambiarlo, reescribirlo en Rust. Creo que una de las principales motivaciones detrás de Rust fue simplemente, allá por, creo que fue 2018, 2019, era, ya sabes, genial, y queríamos probar un nuevo lenguaje, y Rust parecía interesante. Así que decidimos escribirlo en Rust. Gran parte del desarrollo realmente fue mirar, bien, ES Build hizo muchas cosas que realmente nos gustaron, pero también había algunos aspectos que nos gustaría mejorar. Así que estábamos mirando un diseño inicialmente alrededor de, ya sabes, cómo se vería una combinación de las capacidades de Rollup y ES Build? Si realmente miras nuestra rama heredada en el repositorio, verás el diseño original, que está muy basado en ES Build. Y así, realmente, las limitaciones que estamos tratando de abordar no es reescribir Webpack, sino simplemente solucionar los problemas que teníamos en ES Build. Pero a medida que las iteraciones continuaron, las principales cosas que estábamos tratando de obtener de aquí eran, bueno, una, arreglar la división de bundles, dos, abordar los problemas de recarga de módulos en caliente, y algo que Rollup no tenía era el soporte de common JS. Así que queríamos asegurarnos de que teníamos estos tres aspectos críticos disponibles para nosotros.

En el proceso, antes de simplemente, ya sabes, decidir, oye, escribamos algo en Rust, hicimos bastante investigación de mercado. Así que nuestro equipo de Infra básicamente tomó cada empaquetador que se ha escrito en el mercado, los desarmó todos, reescribimos bastantes de ellos en el proceso, mirando cómo funcionaban, cómo estaban arquitectados, pros y contras, ya sabes, básicamente todo lo que necesitaríamos saber. Pasamos tiempo desarmando todo, incluso mirando cosas como el Rust Analyzer y cómo funciona el Rust Analyzer, mirando cómo funciona TypeScript, ya sabes, el TS Checker de TypeScript y todo eso funciona para obtener una muy buena comprensión de la arquitectura del compilador en general. Así que una cosa que también habíamos notado, simplemente porque obviamente intentamos tomar decisiones informadas por datos al trabajar en nuestra infraestructura, fue cuál es el tipo de, simplemente me referí a ello como la latencia de la velocidad del producto o latencia del producto, pero correlacionada con la cantidad de tiempo que pasamos esperando en CI. Así que lo que fue bastante interesante, puedes ver es que si tu tiempo de CI tomaba más de 35 minutos o así, lo que estás viendo es una latencia de aproximadamente 16 horas entre la fusión versus si era de cinco minutos o menos, veríamos que la mayoría de las fusiones ocurrirían dentro de los próximos 20 minutos o así. Así que eso es un cambio bastante drástico en términos de simplemente la velocidad del producto, qué tan rápido las cosas pueden realmente avanzar, porque lo que supongo es, ya sabes, si toma 40 minutos, te distraes, vas a hacer otra cosa, y luego te olvidas de ello. Y luego nuevamente, esta latencia entre abrir el PR y fusionarlo, generalmente tenía una correlación realmente fuerte con cuánto tiempo tomaría la construcción. Así que lo que también habíamos visto, es que una vez que entras en esa zona de cinco minutos para una construcción de producción, el ROI o el valor prácticamente se reducía. Así que encontramos que una construcción de un minuto versus, digamos, una construcción de cuatro minutos no tenía prácticamente ninguna diferencia en valor. Así que esto también nos dio una buena comprensión de, como, cuándo comienzas a alcanzar la ley de rendimientos decrecientes, al menos, ya sabes, a través de esta dimensión. Así que de todos modos, como dije, desarmamos prácticamente cada empaquetador que pudimos conseguir, reescribimos un par de ellos. Y en el proceso, identificamos cosas que realmente nos gustaron y cosas que, ya sabes, tal vez no nos gustaron tanto, o simplemente algunas debilidades que habíamos encontrado. Creo que Rollup fue uno, nuevamente, nos inspiró bastante temprano. Y uno de los aspectos realmente fue, ya sabes, es una salida de bundle muy limpia y minimalista que crea, es una experiencia bastante optimizada.

Tiene realmente un buen tree shaking, eliminación de código muerto, cosas así, hizo un muy buen trabajo en eso. Pero los desafíos con los que nos encontraríamos serían algo como el soporte de CommonJS. Cómo funciona todo, y de hecho la mayoría de los empaquetadores tienen problemas con esto. Creo que ESBuild es una de las excepciones, y, ya sabes, Webpack y Parcel, pero muchas herramientas de construcción son solo ESM.

Así que un gran desafío con el que nos encontraríamos es si tienes algo que es CommonJS, tienes que tomar tu CommonJS no estricto y convertirlo en ESM estricto. Y esto causó varios desafíos en la interoperabilidad y simplemente otros problemas en general con las limitaciones de que todo tenga que ser ESM de primera clase. Otra gran debilidad realmente es que terminó siendo más lento que Webpack, principalmente porque al menos Webpack tenía un caché, y sin un caché construir una aplicación de 50,000 módulos, todavía la estás construyendo en JavaScript. Sin soporte real para HMR, lo cual fue definitivamente doloroso, y, ya sabes, el rendimiento del modo de observación no cumplía exactamente con las expectativas que el negocio quería de la herramienta.

Mirando ESBuild, las fortalezas que tenía era ese soporte de CommonJS, y tenía una velocidad de construcción realmente excepcional, pero la API era realmente restrictiva, el ecosistema de complementos también. Experimentamos muchos desafíos con algo como el rendimiento del lado del cliente, creando cascadas muy largas de chunks o encontrando varios casos límite con, como, tree-shaking de CSS. No mucho control sobre el proceso de chunking real, lo cual parece, ya sabes, parece algo pequeño, pero cuando estás lidiando con una salida de construcción optimizada de 800 megabytes, un gigabyte, ya sabes, esto se convierte en una gran limitación. Y nuevamente, el HMR también fue muy doloroso de trabajar, causando, ya sabes, una recarga completa de la página o algo así. Y creo que probablemente uno de los mayores factores motivadores fue que también usamos la federación de módulos bastante intensamente. Creo que probablemente tenemos la implementación más grande del mundo de esto. Así que tratar de implementar ese tipo de capacidades avanzadas fue muy difícil dadas las limitaciones con ESBuild.

Dicho esto, Webpack no era tan bueno tampoco en ciertos aspectos. Y si alguien ha usado Webpack, estoy seguro de que ha sentido algunos de sus dolores. Uno de los grandes problemas realmente es todo el efecto de caja negra. Si algo sale mal, es muy difícil entender qué o por qué. Sabes, ¿por qué el bundle se está inflando? Sabes, no había mucha visibilidad. También causó mucha presión de guardia. Como dije, mucho de nuestro tiempo de guardia se había dedicado a problemas relacionados con la construcción. Así que al menos pudimos resolver, como, los problemas de depuración al lanzar rsdoctor, pero eso realmente no nos ayudó con nuestras limitaciones de rendimiento.

Así que, de nuevo, manejar un proyecto realmente grande fue muy difícil de hacer. Intentamos, ya sabes, bastantes cosas para mejorar solo la velocidad de construcción de Webpack. Cache loader, thread loader. En un momento intenté reemplazar el analizador con algo que estaba basado en Rust, pero en última instancia no hubo mucho éxito en ese enfoque. Con la caché habilitada, un desafío con el que nos encontramos también es si intentas persistirlo en CI o, ya sabes, otras cosas así, obtendrías estos tipos de desajustes donde no se reconstruiría correctamente. A veces la caché se queda atascada.

Así que otro enfoque que terminamos considerando en algún momento de este proceso fue, ya sabes, creo que esto es, de nuevo, era 2019, 2020. Así que VEET obviamente se estaba volviendo bastante popular, y eso fue algo que habíamos considerado. Oye, ¿podría funcionar VEET? ¿Podría funcionar un enfoque de doble motor usando la estabilidad de la construcción y producción de Webpack y usando la experiencia de desarrollo más rápida de VEET en desarrollo? Pero los grandes problemas con los que nos encontramos son, creo, los que esperarías. Cualquier sistema de construcción de doble motor lucha con la interrupción del complemento, lo hace más complicado de mantener. Varios problemas de rendimiento con los que nos encontramos en el modo de desarrollo debido a, como, las soluciones no empaquetadas.

Así que, ya sabes, creo que algunos de los más grandes que habíamos visto fue que una recarga en caliente tomaría 10 minutos solo porque estás descargando, ya sabes, 15,000, 20,000 módulos en el navegador. Cada vez que tiene que hacer una actualización. Así que varias limitaciones allí que creo que los proyectos más grandes han experimentado. Y luego un roll-up de nuevo, tuvimos problemas de rendimiento y falta de caché persistente todavía, lo que creó muchas limitaciones. Creo que el mayor desafío que hemos visto es realmente la inconsistencia de un enfoque de doble motor. Si estás usando algo en desarrollo diferente de producción, es muy difícil asegurar que estos van a ser, como, consistentes y lo que obtienes aquí es lo que esperas en el otro extremo. Así que la especie de evolución por la que pasamos y por qué elegimos Webpack para la arquitectura de RSPack realmente se redujo a que necesitábamos algo que sabíamos que funcionaba, que estaba garantizado que funcionara, y que estaba probado en batalla. Gran parte del desarrollo que habíamos hecho a lo largo de este proceso, terminamos básicamente tratando de reconstruir cosas que Webpack ya tenía. Así que la única diferencia, sin embargo, es que no teníamos una década de pruebas. Todo era código nuevo, nueva arquitectura que estos empaquetadores en sus formas originales no soportaban. Así que estamos un poco volando a ciegas y, ya sabes, eso obviamente introduce mucho riesgo.

Entonces, si de todos modos terminamos recreando Webpack, ¿qué pasaría si simplemente tomáramos Webpack y lo moviéramos a Rust? Y esa fue la idea que tuvimos, ya sabes, por la que optamos. Así que así es como terminamos en lo que RSPack más o menos se parece hoy.

Ahora, ¿alguien sabe qué tienen en común estos? Puedes gritarlo si lo sabes por casualidad. Bien. Entonces, las principales cosas que tienen en común, bueno, una, todos están basados en Rust. Pero dos, estos en realidad, sus orígenes se pueden rastrear hasta ByteDance. Así que Ploy fue en realidad uno de los proyectos competidores con el equipo de RSPack. Ahora se conoce como Farm, y el autor de Ploy lo lanzó de forma independiente. Y el resto del equipo de Ploy se fusionó en RSPack. Rolldown también se inició en otro lugar, ya sabes, de forma independiente como un proyecto paralelo de uno de los miembros que ahora se ha unido al equipo de Vite, llevando Rolldown a, ya sabes, el extremo de Vite.

Así que, ya sabes, algunas de las cosas realmente para nuestras prioridades de lo que estábamos buscando es, sobre todo, la integridad del artefacto. Necesitamos garantizar que esto siempre va a funcionar, que no vamos a tener sorpresas aquí considerando el riesgo que tiene el negocio y el tamaño de las aplicaciones que soportamos. Hay, ya sabes, miles de millones de usuarios usando estos, cientos de miles de empleados trabajando en estas aplicaciones. Así que necesitábamos algo que realmente nos ayudara a obtener nuestro rendimiento en un buen lugar, pensar en el costo de la gestión del cambio, pensar en las mejoras de productividad, y, ya sabes, esencialmente mirando métricas orientadas al negocio para cómo debería funcionar este empaquetador para realmente impulsar el valor empresarial por encima de todo. Y a largo plazo, ya sabes, hacer apuestas confiables, seguras sobre lo que estamos eligiendo. Uno de los desafíos que creo que hemos aprendido con Speedy es cuando comenzamos a construir Speedy, ES Build había, creo, salido recientemente y tenía un ciclo de desarrollo realmente, realmente activo. Así que pensamos que era una apuesta bastante buena que muchas cosas como HMR o división de chunks o cosas así probablemente se resolverían. Pero creo que a medida que pasó el tiempo, tal vez las prioridades cambiaron allí, pero algunas de esas cosas no sucedieron. Así que esto fue, de nuevo, una de las grandes cosas que tomamos en cuenta es, ya sabes, ¿cuáles son los riesgos cuando intentas ir por, digamos, un proyecto orientado a la comunidad? Y de nuevo, la presión de guardia, cosas así, simplemente crea un nivel diferente de expectativas. Así que realmente, nuestro objetivo aquí era hacerlo rápido, hacerlo funcionar, y luego lo haremos más rápido.

Así que otro aspecto, realmente, que admiramos de RSPack Webpack es el tipo de manejo agnóstico al lenguaje. Así que, como dije, muchas herramientas son usualmente, como, solo ESM. Todo se convierte en ESM y así es como funciona el analizador y así es como obtienes lo que necesitas. Pero de nuevo, complicaciones alrededor de la estricta, ya sabes, conversión de no estricto a estricto de common JS u otros formatos de módulo, si estás lidiando con sistemas de módulos mixtos, también crea complejidad adicional a medida que comienzan a aparecer peculiaridades. Y, ya sabes, generalmente, simplemente tuvimos problemas con la escalabilidad de, ya sabes, de solo poder usar ESM y convertir todo a ESM y luego volver a algo más. Así que creo que una cosa a destacar aquí es que Parcel probablemente no recibe suficiente crédito por esto, pero Parcel también es un enfoque agnóstico al lenguaje. Creo que la única razón por la que RSPack no se modeló realmente a partir del diseño de Parcel fue que simplemente conocíamos mejor las APIs de Webpack. Pero realmente podría haber sido cualquiera de los dos porque tienen una arquitectura realmente, realmente fuerte bajo el capó. Así que la principal cosa, sin embargo, con este enfoque agnóstico al lenguaje es que nos da mucho espacio para extender este compilador para hacer más. No estamos simplemente atascados con, digamos, oh, bueno, todo tiene que convertirse en ESM, pero podríamos, ya sabes, incorporar, digamos, como, CSS es un soporte de lenguaje de primera clase o TypeScript es un soporte de lenguaje de primera clase, no tener que depender de, como, un cargador o un paso de transformación separado que el empaquetador no necesariamente conocería.

Entonces, de nuevo, diseño de API, ¿cuáles eran las características clave que estábamos buscando? Algo que tuviera un ecosistema de plugins de JavaScript realmente robusto. Esto realmente nos ayuda con, como, el lado empresarial de las cosas, asegurándonos de que pueda hacer todo lo que necesita hacer. Rendimiento, obviamente, asegurándonos de que sea eficiente, que pueda desempeñarse bien. Y, como, la composabilidad de esto, que es otro aspecto importante, asegurándonos de que lo que vamos a construir hoy realmente pueda hacer lo que los equipos de negocio y producto quieren que haga en el futuro. Y esas son algunas peticiones bastante locas, ideas, cosas así.

Así que tratar de construir algo que garantice, ya sabes, tan amplio como un tipo de— tan amplio como un nivel de soporte que podamos obtener para cubrir tanto del negocio bajo una solución. Así que obviamente el enfoque que terminamos tomando fue buscar un equilibrio entre rendimiento y versatilidad. Debería ser lo suficientemente rápido. Y sabemos que esa ventana muestra una vez que comenzamos a ir, ya sabes, en ese rango de cinco minutos y menos, el ROI de la velocidad comienza a disminuir, asumiendo que tu HMR sigue siendo rápido. Entonces, de nuevo, ¿cuánto puede hacer versus qué tan rápido es? Y ¿qué estás sacrificando al perseguir la velocidad en términos de usar todo ese poder y Rust para hacer cosas más complicadas, para hacer más optimización, para, ya sabes, simplemente aprovechar la potencia? Así que tratar de encontrar ese buen equilibrio fue realmente importante para nosotros.

Y obviamente todo aquí ha sido muy adaptado para negocios y empresas. Los usuarios, casos de uso, cosas así. Como, de nuevo, nuestro propio caso de uso, necesitamos soportar, ya sabes, miles de millones de usuarios trabajando en esto desde varios lugares del mundo, varios tipos de tecnologías que tienen, varios entornos. Así que tratar de encontrar algo que realmente funcionara bien para el tipo de problemas que tienen las empresas más grandes fue un objetivo principal para nosotros. Así que de todos modos, terminamos llegando allí y lo hemos implementado bastante ampliamente. Y también hemos visto algún tipo de retorno de inversión al hacer todo esto.

Entonces, ya sabes, solo algunas cosas generales que habíamos visto que realmente me gustaron fue probablemente la más grande aquí fue una reducción del 80% en los costos de la nube en general. Así que cuando implementamos esto en masa, nuestros costos de CI, la mayoría de nuestros costos de la nube se redujeron en un 80%, lo cual fue un número asombroso en una empresa de ese tamaño. En promedio, veríamos una reducción de unos 30 minutos en nuestros tiempos de construcción. Y en términos de CI, veríamos, creo que era por proyecto por día, alrededor de 200 horas de CI ahorradas.

Así que cada proyecto al año ahorraría, ya sabes, digamos 80,000 horas al año en, como, horas de CI. Y para un desarrollador, trabajando en, como, tu modo de desarrollo localmente, asumiendo que podrías tener que cambiar de rama aquí y allá, lo pusimos como si tuvieras que hacer cinco, ya sabes, reinicios de tu servidor de desarrollo, hemos, ya sabes, calculado que, está bien, ya sabes, aproximadamente estás viendo alrededor de siete horas a la semana ahorradas por desarrollador en la empresa o, ya sabes, aproximadamente 400 horas al año por desarrollador. En el lado financiero, sin embargo, también vimos algunos números excelentes. Así que para nuestro propio uso personal, hemos visto alrededor de $200 millones al año de ahorros del proyecto o por lo que estamos invirtiendo en él versus lo que estamos obteniendo de él, alrededor de $200 millones al año.

Hemos tenido usuarios externos que también han adoptado esto, y han sido lo suficientemente amables como para darnos su propia información financiera sobre las reducciones. Y estamos viendo, ya sabes, nuevamente, para otro usuario, $32 millones al año. Y lo que realmente me pareció impresionante fue, considerando que estábamos mirando ese tiempo medio para fusionar, que tratamos como latencia del producto. Entre crear algo y llevarlo a producción, ¿cuál es la latencia entre eso? Y tenemos, ya sabes, la mayoría de las construcciones son realmente masivas, así que vemos que el CI toma más de 35 minutos. Así que, ya sabes, por año, solo en un solo repositorio, pudimos recuperar más de 1.6 millones de horas en latencia del producto.

Así que ese es el tiempo desde obtener el PR hasta llevarlo a producción. Y ese es solo uno de los repositorios que tenemos entre los, ya sabes, miles que hay. Así que realmente hubo mucho valor que terminamos viendo de ello, lo cual obviamente es genial para nosotros ver que nuestras teorías habían funcionado. Otro aspecto en el que hemos visto mucho retorno es en realidad el ahorro de ancho de banda, ya que mucho de lo que hemos enfocado el proyecto es realmente buena optimización, realmente buen chunking, métodos inteligentes sobre cómo dividir la aplicación, en lugar de solo, como, Webpack, soluciones súper verbosas allí, tratar de refinarlas un poco más.

Y, ya sabes, hemos tenido usuarios que informan hasta un 50% de ahorro en el ancho de banda de salida en su infraestructura, lo cual para ellos también se tradujo en un par de miles de millones de dólares al año, lo cual, nuevamente, fue bastante agradable de ver. Así que solo para resumir aquí, algunas de las ideas futuras que hemos estado mirando con RSPack es, nuevamente, esa solución agnóstica de lenguaje va a ser muy útil para TypeScript. Estamos buscando hacer de TypeScript un ciudadano de primera clase, lo que nos permitiría hacer cosas como optimizaciones en tiempo de enlace, poder usar toda la información de tipado para optimizar aún más, agitar el árbol, eliminar código muerto en, digamos, métodos privados que no se exportan, cosas que generalmente se pierden en el proceso de transpilación.

Existe la posibilidad de investigar, como, la integración de la verificación de tipos en el empaquetador o crear algo como un servidor de lenguaje ya que la diferencia entre, digamos, empaquetar y verificar tipos son en realidad muy pocas. Hay muchas superposiciones en cómo están construidos. Algunas otras cosas que hemos estado mirando es que probablemente hayas visto algunas de estas características de, como, TurboPack de las que han estado hablando. Una de ellas sería, como, el caché remoto a nivel de función. Así que eso es algo que planeamos hacer de código abierto y lanzar para que lo autohospedes para RSPack, creo que probablemente en el próximo trimestre o dos. No puedo recordar la línea de tiempo exacta allí, pero esencialmente significará que cualquiera que esté construyendo tu aplicación, puedes reciclar sus cachés y tener un caché remoto distribuido del que todos puedan beneficiarse sin costo alguno. Y otro grande sería la división de código a nivel de exportación.

Usualmente cuando divides tu aplicación ahora mismo, la estás dividiendo en base a, cómo lo llamas, la estás dividiendo en base al módulo. El archivo completo con lo que sea que se exporte allí puede ser fragmentado. Pero lo que estamos buscando hacer es en realidad a nivel de exportación, poder tomar una exportación y reubicarla en función de cómo se usa, lo que nos dará mucha más optimización entre módulos y simplemente mucho más, ya sabes, mejor salida de nuestros artefactos, cargas útiles más pequeñas.

Y luego mirando hacia, como, RSPack v2, creo que lo que hemos descubierto es, aunque es bastante rápido, definitivamente podría ser mucho más rápido. Y uno de los experimentos que habíamos hecho para comprobarlo fue, ¿qué pasaría si eliminamos las dependencias de Webpack de él y en su lugar usamos, creo que usamos Unplugins? Así que usamos, como, el SDK en el que hemos estado trabajando para, ya sabes, esencialmente permitirte crear tu propio compilador. Y probamos usar la API de Unplugins como las principales dependencias para RSPack. Al hacerlo, teníamos aproximadamente una décima parte de capacidad solo porque la superficie de la API es obviamente más pequeña. Pero también vimos que los tiempos de construcción eran aproximadamente 100 veces más rápidos. Así que fue muy interesante ver las diferencias allí.

De todos modos, gracias por venir aquí. Y si tienes alguna pregunta, siempre puedes encontrarme por aquí. Si quieres ver más sobre RSPack, solo escanea el código QR, y eso te llevará a la página de inicio. Así que tenemos la primera pregunta aquí. La gente quiere saber, ¿cómo se comparan RSPack y TurboPack? Así que diría probablemente la... Quiero decir, ambos... Hay muchas cosas en común. Como, si miras la salida subyacente de ellos, verás que ambos tienen este tipo de concepto de un runtime de Webpack. En Webpack, ya sabes, el runtime es como un, como, prototipo de función en Webpack require. Y TurboPack simplemente envía un objeto del que desestructuras los métodos. Pero ambos tienen mucho en común en términos de diseño. Diría que una de las mayores diferencias, sin embargo, es realmente el sistema de recarga en caliente de TurboPack. Así que TurboPack es de hoja hacia arriba, mientras que el HMR de Webpack va desde, genial, ¿cuál es el nodo padre?, y lo reconstruye hacia abajo. Así que hay algunas diferencias de velocidad en HMR. Pero creo que también en general, a medida que avanzamos hacia V2, estamos planeando alinearnos con la arquitectura de TurboPack. Así que lo que sea que puedas esperar allí, probablemente puedas esperarlo también de RSPack. Eso tiene sentido. Gracias. Muy bien. La siguiente, tres votos. Para una empresa más pequeña que no tiene los problemas de escala como ByteDance, ¿cuáles son las cosas más importantes a considerar al elegir un empaquetador, en tu opinión? Y esta es la última pregunta del día. Está bien. Diría que probablemente lo más importante es, como, ¿qué necesitas que haga la herramienta? Sabes, ¿realmente importa el rendimiento? ¿Necesitas, sabes, va a ser un problema la fragmentación, lo cual, sabes, hemos visto mucho de esto, pero, y también solo en qué te sientes cómodo? ¿Cuánto necesitas usar la herramienta, y elige lo que creas que va a hacer todo lo que necesitas que haga cómodamente. Obviamente, estas herramientas están más, sabes, orientadas a medida que la empresa crece, o a medida que crecen los requisitos, tienes un espacio casi ilimitado para moverte. Pero en general, lo que estoy buscando es, ¿qué va a ser fiable? ¿Qué va a ser seguro? ¿Qué va a resolver el problema rápidamente? ¿Y qué va a producir una experiencia de usuario sólida? Porque realmente, no importa qué tan rápido sea para mí, si no soy capaz de crear una salida altamente optimizada para el usuario final, porque ese es el embudo de ingresos. Los desarrolladores, es agradable si es rápido para nosotros, pero no somos el embudo de ingresos principal. Así que esas son las principales cosas que miro. Suena bien. Suena como seguridad, fiabilidad, y tus casos de uso. Bueno, eso es todo el tiempo que tenemos. Como recordatorio, si tienes más preguntas, puedes acorralarlo justo afuera y asegurarte de que no se vaya hasta que responda tus preguntas.