Turbopack. ¿Por qué? ¿Cómo? ¿Cuándo? y la Visión...

Gracias por recibirme. Mi nombre es Tobias Cauras, soy de Alemania, y les voy a contar algo sobre TurboPack. Comencé con el desarrollo web hace 10 años, cuando empecé a fundar Webpack y lo mantuve durante 10 años, así que ahora es bastante antiguo.

Hace casi 2 años me uní a Versil y trabajé con el equipo de Next.js en Next.js e integración con Webpack y cosas de rendimiento y cosas así. Y luego, durante 10 meses, he estado trabajando en TurboPack y les voy a contar algo sobre eso.

En primer lugar, ¿cuál es nuestra misión con TurboPack? Nuestra misión es crear el sucesor de Webpack. Queremos alinearnos con los objetivos de Webpack, queremos crear una herramienta que sea realmente como Webpack, similar a Webpack y que cumpla al menos los objetivos de Webpack. Sé que es una misión realmente ambiciosa y llevará años o mucho tiempo lograrlo, pero al menos esa es la dirección hacia la que estamos tratando de avanzar. Y esto básicamente nos motiva para nuestros objetivos de proyecto.

No queremos construir algo que sea solo para Next.js. Queremos construir algo que sea independiente del marco de trabajo. No queremos construir algo que sea solo para Versil. Queremos hacer algo para la comunidad de código abierto, que es un esfuerzo comunitario, y queremos alinearnos con los objetivos y la motivación detrás de Webpack. También queremos asegurarnos de construir algo tan flexible y extensible como Webpack. Queremos seguir los pasos de Webpack en ese sentido. En realidad, queremos crear un bloque de construcción para el desarrollo web de los próximos diez años.

De acuerdo. Veamos qué ha llevado a la creación de TurboPack en el pasado y también cómo funciona, y cuál es exactamente nuestra visión con TurboPack. Comencé cuando me uní a Versa y trabajé con el equipo de Next.js, y básicamente queríamos resolver algunos desafíos en la experiencia del desarrollador, y uno de estos desafíos era el rendimiento. Funciona bastante bien, pero hay algunos desafíos con el rendimiento, especialmente porque Next.js está principalmente construido sobre herramientas basadas en JavaScript, y las herramientas basadas en JavaScript para trabajos intensivos en cómputo tienen dificultades para aprovechar toda la potencia de tu computadora, por lo que aprovechar múltiples CPUs y realmente JavaScript puede que no sea el mejor lenguaje para trabajos intensivos en cómputo o para tareas de construcción. El equipo de Next.js y yo comenzamos a trabajar en la migración de una parte de Next.js o de la infraestructura del compilador del desarrollo web al mundo de Rust, por lo que se integró SWC en Next.js, y realmente tiene muchos beneficios en términos de rendimiento. Pero también hay algunos cambios en la integración. Siempre hay un límite entre el mundo de JavaScript y el mundo de Rust, y tienes los problemas de serialización. Aún así, hay desafíos al trabajar en eso. También hubo algunos compromisos que tuvimos que hacer en Next.js por el rendimiento. Un ejemplo fue que estamos resolviendo las solicitudes de módulos en Webpack, y tuvimos que ser realmente optimistas al respecto para que fuera similar en términos de rendimiento. Una vez que resolvimos algo con éxito, asumimos que no ha cambiado. También asumimos que los módulos de Node generalmente no cambian, y esto funciona bien para el 99 por ciento de los casos, pero es un compromiso y no queremos estar obligados a elegir eso. Pero también hay algunos desafíos de implementación en el equipo de Next.js.

Actualmente, Next.js utiliza cuatro o cinco compiladores de Webpack para hacer que todo esto funcione, uno para el cliente, para la representación del servidor, para la representación en el borde, para varios componentes y un compilador de respaldo para mensajes de error. Toda esta especie de trabajo de orquestación ligera entre estos compiladores no es tan fácil. Funciona más o menos, pero es una fuente de errores, donde puedes cometer errores o olvidar algo, o la comunicación no funciona correctamente, y eso no es algo que queramos que se nos obligue a hacer.

Por lo tanto, también hay algunos desafíos en el lado de WEPAC, WEPAC fue construido hace diez años, y todavía tiene la arquitectura de hace diez años, cuando las aplicaciones eran como cientos de módulos, y el desarrollo web ha crecido mucho en la última década, y sí, la arquitectura de WEPAC no fue realmente construida para este tipo de rendimiento de construcción incremental a gran escala. Eso es un problema, y no podemos solucionarlo fácilmente porque hay muchos complementos que dependen de la arquitectura de WEPAC, y es realmente difícil hacer cambios compatibles hacia atrás en la arquitectura, no podemos cambiar fácilmente la arquitectura y seguir siendo compatible hacia atrás. No queremos romper los casos de uso de todos cambiando la arquitectura de WEPAC, así que no es realmente una buena oportunidad para solucionarlo.

Por otro lado, hemos solucionado muchas cosas mientras trabajaba en Next.js en WEPAC para hacerlo más eficiente, pero teníamos un límite en el tipo de optimización que podíamos hacer sin reescribirlo todo. También hay otros desafíos como la invalidación de caché. En muchos casos, es demasiado sensible, por lo que si cambias algo, afecta, tiene que reconstruir una parte más grande de la aplicación, cuando probablemente no esté afectada. Por ejemplo, si cambias un comentario, ¿por qué tenemos que reconstruir el módulo? Podría ser más granular en lo que podemos almacenar en caché. Un problema de la arquitectura es este problema de costo de búsqueda de caché. Lo que hacemos al realizar una construcción incremental es básicamente comenzar de manera similar a una construcción completa, comenzar a construirlo y para cada trabajo que queremos hacer, primero verificamos si está en la caché, si ya está en caché, y luego podemos omitir ese trabajo, y eso suena genial, pero a esa escala, si buscas, como, 10,000 módulos de módulos en la caché, entonces tienes este serio costo de buscar cosas en la caché, y sí, eso es un problema.

Pero sí, estamos hablando de problemas de búsqueda cuando se trata de unos pocos segundos de reconstrucción. Si trabajas en el mundo nativo, sabrás que son tiempos incrementales de minutos o algo así. Sí, tenemos un problema realmente lujoso en el mundo del desarrollo web, ¡supongo! Pero también hubo algunas oportunidades que podríamos abordar mientras trabajamos en un nuevo Bundler. Entonces, en el mejor de los casos, tenemos esta herramienta llamada TurboRepo, y al combinar esto con Next.js, podemos muchas cosas de cada uno. Next.js tiene este almacenamiento en caché granular genial, como si cambias un módulo solo reconstruyes un módulo y algunas cosas de plantilla. Pero en la herramienta TurboRepo, siempre tienes esta granularidad de almacenamiento en caché de comandos completos. Y luego TurboRepo puede aprender de Next.js al tener un almacenamiento en caché más granular, pero también puede aprender al tener un modo de observación más enfocado en el desarrollo donde puedes tener este tipo de experiencia de observación-incremental-parte por defecto. Pero por otro lado, Next.js puede aprender de TurboRepo. TurboRepo tiene esta característica genial de almacenamiento en caché remoto, por lo que realmente puede compartir tu caché con tu equipo y se carga en la nube o es una solución de alojamiento propio. Y luego puedes compartir eso con tu equipo y no tienes que reconstruir lo que tus colegas ya han construido. Eso es genial. Queríamos tener eso en Next.js, como compartir caché con el equipo y compartir caché con la implementación para no tener que hacer todo el trabajo dos veces. Pero hay algunas nuevas oportunidades. He visto que muchos desarrolladores realmente quieren tener más información sobre el proceso de construcción. ¿Cuál es el tamaño de la página de componentes, cuál es el tamaño de las dependencias y cómo afectan las solicitudes de extracción al cambio de mi aplicación o al cambio de rendimiento de mi aplicación. Este tipo de información. Y queremos ofrecer más de estos tipos. También relacionado con el rendimiento de construcción, estadísticas meta, por qué mi construcción es lenta o cómo afecta mi tiempo de construcción, este tipo de estadísticas.

Así que hicimos este plan mágico donde tuvimos esta idea de construir algo nuevo. Y la idea era que tenemos estos desafíos comunes sobre el almacenamiento en caché y la invalidación y el modo de observación y las construcciones incrementales, y queríamos abstraer eso del empaquetador. Entonces, el plan era construir algún tipo de motor central que resolviera estos problemas comunes y luego construir un empaquetador sobre este motor central para no tener que resolver estos problemas una y otra vez y ocuparnos de la invalidación de caché en cada tipo de código que escribimos. Y luego, después de escribir este empaquetador, solo queremos usarlo en Next.js u otros frameworks para obtener los beneficios de esta nueva idea, y eso es básicamente lo que hicimos.

Siempre tuvimos en mente el objetivo de que las construcciones incrementales sean independientes del tamaño de la aplicación, lo que significa que mi aplicación puede crecer tanto como desee, pero mis construcciones incrementales deben ser constantes en rendimiento, es decir, siempre se debe emplear el mismo tiempo en las construcciones incrementales. Básicamente, las construcciones incrementales solo deben depender del tamaño de los módulos afectados o del cambio afectado en mi aplicación, no del tamaño total. Esto no ocurre en Webpack, por ejemplo.

Por lo tanto, sobre esta idea construimos un sistema de capas. Nuestro plan era utilizar Rust como capa base y lenguaje. La primera razón fue que queríamos utilizar SWC como analizador, ya que no queríamos volver a escribir un nuevo analizador y generador de código. Por lo tanto, queríamos utilizar SWC, que está basado en Rust. Fue una elección obvia utilizar Rust. Pero Rust también se adapta bien a nuestros desafíos. Tiene un rendimiento predecible, paralelismo, que es fácil de usar y compartir memoria, y también es un lenguaje seguro en cuanto a la seguridad de memoria, lo cual es importante para cuestiones de seguridad y remotas. Sin embargo, también hay desventajas al utilizar Rust. Por lo general, es mucho más difícil de escribir en comparación con JavaScript, lo cual podría ser un problema en cuanto a la experiencia del desarrollador cuando queremos ofrecer la posibilidad de escribir complementos.

Por lo tanto, tomamos la decisión de siempre proporcionar JavaScript y Rust como interfaces de complementos, para que siempre se pueda... El plan es permitir que el desarrollador escriba los complementos ya sea en JavaScript o en Rust. JavaScript puede ser un poco más lento, pero en muchos casos eso puede no ser relevante. Sin embargo, al final, aún puedes comenzar escribiendo tu complemento en JavaScript y luego pasarlo a Rust si descubres otros problemas y es un problema de rendimiento. Pero en la mayoría de los casos, probablemente no será un problema de rendimiento.

Y sobre Rust, básicamente construimos TurboEngine, que es este motor central común que resuelve estos problemas comunes, como el almacenamiento en caché, la invalidación y también algún tipo de abstracción de estas fuentes comunes de acceso externo, como el sistema de archivos, el almacenamiento en caché, la red, cosas así. Y sobre TurboEngine, construimos TurboPack, que es simplemente un empaquetador. Básicamente hace todo lo que hace un empaquetador, como CSS, activos estáticos, ECMAScript, TypeScript, imágenes, fuentes, hay muchas cosas, en realidad. Y luego TurboPack puede ser utilizado por Next.js como un tipo de empaquetador en reemplazo de Webpack. Pero también puede ser utilizado por otros frameworks, como cualquier otro. Ahora veamos cómo funciona TurboEngine. Toda la magia de TurboEngine radica en la capacidad de escribir TurboFunctions, que es una función a la que se le agrega una especie de anotación y se convierte en una TurboFunction. TurboFunctions significa que optas por la memorización de funciones para el almacenamiento en caché. Por lo tanto, automáticamente memorizará o almacenará en caché tus funciones. Si la llamas dos veces, no la calculará dos veces. Pero también hacemos algo para la invalidación de caché.

Por lo tanto, seguimos automáticamente todas las dependencias de la función. Si escribes este tipo de TurboFunction y luego accedes a algunos data, automáticamente los rastreamos y construimos un gran gráfico, al que llamamos gráfico de tareas, a partir de todas las ejecuciones de TurboFunctions. Así que tenemos este gran gráfico de tareas y dependencias entre ellas, y también puede realizar todo este tipo de trabajo de gráficos interesantes, como análisis de gráficos, sobre este gráfico de cálculo o gráfico de tareas . Y también podemos, al rastrear la dependencia, programar automáticamente su trabajo en segundo plano o en un grupo de hilos para lograr paralelismo automáticamente. Al rastrear la dependencia, significa que una vez que accedes a data desde diferentes tareas o diferentes TurboFunctions, podemos evitarlo en ese momento, porque lo rastreamos y hacemos, como, programación automática y trasplante para el uso de TurboEngine.

Sí. Tenemos un ejemplo de cómo se ve un gráfico de tareas. Es realmente una versión simplificada. En realidad, un gráfico de tareas tiene alrededor de 200 tareas por módulo de una aplicación web, por lo que es realmente detallado. Pero es solo una idea de lo que puedes esperar.

Tenemos este gráfico donde todas esas funciones, invocaciones y tareas están conectadas con otras dependencias. Y lo que podemos hacer con este tipo de gráfico es hacer compilaciones incrementales súper geniales, porque esto es como una compilación inicial. Tenemos que ejecutar todas las funciones, obviamente, solo una vez. Pero tenemos que ejecutarlas. Pero una vez que haces una compilación incremental, tienes algún tipo de fuente de cambio. Como un ejemplo de FileWatcher, que invalida una de las tareas o funciones. En este ejemplo, invalida la tarea de lectura y básicamente comenzamos a invalidar y recalcular el gráfico a partir de esa fuente externa. Y básicamente puedes propagar el cambio a través del gráfico siguiendo las dependencias hacia atrás. Y calculamos solo las tareas que son necesarias para acumular este cambio en el... Para actualizar el gráfico al nuevo cambio. Y esto tiene muchos beneficios. Como solo tenemos que tocar las tareas que realmente se ven afectadas por el cambio. Y también podemos detener la propagación del cambio. En este ejemplo, se muestra aquí. Donde algún cambio puede no afectar alguna salida de una tarea. En un ejemplo, cambiamos algún tipo de código que no afecta las importaciones. Y en este caso, no seguirá después de obtener las referencias del módulo. Veremos que las referencias son las mismas y se detendrá la propagación del cambio a través del gráfico y podemos detenernos en cualquier punto. Pero también puedes ver que podemos ejecutar automáticamente el código en paralelo. Ambas tareas dependen del análisis de TypeScript. Y podemos ejecutarlas en paralelo automáticamente. Y no tienes que preocuparte por este tipo de problemas comunes al escribir un paquete en la parte superior de TurboEngine. Esto resuelve muchos problemas. No tenemos este problema de JavaScript de un solo hilo, porque estamos escribiendo en Rust y tenemos programación y paralelización automática.

También resuelve los problemas de invalidación de caché. No puedes evitar invalidar la caché, porque es automático, no puedes romperla, o al menos es muy difícil de romper. También resuelve el problema de la invalidación de caché demasiado sensible, porque tenemos este gráfico de funciones realmente detallado donde podemos seguir los cambios y depende de una manera realmente detallada, lo que hace que la invalidación de caché sea realmente detallada y correcta.

También resuelve el problema de muchas cargas de caché, porque para todos estos gráficos que están en gris, no tenemos que hacer nada. No tenemos que buscar en la caché. Simplemente están ahí, sin ser afectados por el cambio en absoluto. Por lo tanto, no tienen ningún costo para una tarea inactiva. Esto significa que puedes tener una aplicación grande, tan grande como desees, y tu cambio solo se ve afectado por la... Tu rendimiento solo se ve afectado por la tarea que debes volver a calcular, lo cual es realmente mínimo. Esto nos permite lograr nuestro objetivo de que las compilaciones incrementales sean independientes del tamaño de la aplicación.

Y sobre esta base del sistema TurboEngine, construimos TurboPack, que es básicamente un empaquetador. Pero con dos diferencias importantes en comparación con WebPack. Tiene un sistema de entornos mixtos. En un gráfico de activos de TurboPack, básicamente puedes mezclar entornos. Puedes mezclar el servidor y el servidor está importando un componente del cliente o estás importando una función de borde de un componente del servidor, lo que sea. Puedes mezclar entornos en el gráfico y es solo un compilador que se encarga de todos los gráficos. Esto ofrece muchos beneficios, como la optimización entre entornos, como la eliminación de código entre entornos y cosas así. Muchas más oportunidades para optimizar tu código.

También tenemos este concepto de gráficos de activos perezosos. Esto significa que TurboEngine se encarga de las compilaciones incrementales. Pero, ¿qué pasa con la compilación inicial? ¿Queremos construir todas las tareas desde el inicio? Probablemente no. Por lo tanto, queremos tener algún tipo de sistema perezoso donde solo construimos un gráfico en un paquete. Construimos varios gráficos, como un gráfico de módulos y un gráfico de fragmentos, y construimos un gráfico de una manera que se deriva del gráfico anterior. El gráfico de módulos se deriva del código fuente y el gráfico de salida se deriva del gráfico de módulos. De esta manera, no tenemos que construir una función que convierta un gráfico en otro gráfico. Construimos este gráfico derivado y usamos funciones para obtener referencias, que es una función de Turbo. Y de esta manera, no tienes que construir el gráfico, simplemente lo construyes bajo demanda cuando accedes a él. Básicamente, esto significa que todo es perezoso por defecto. El gráfico completo se construye de forma perezosa. Y esto significa que solo si haces una solicitud HTTP al servidor de desarrollo, se calculará y leerá tus archivos, construirá un gráfico de módulos.

Solo para ese tipo de gráfico, se necesita para servir esta solicitud HTTP. Lo que lo hace realmente perezoso y debería ser una experiencia de transmisión cuando abres una página en tu servidor de desarrollo.

Y con este nuevo paquete, básicamente queremos usarlo en Next. Y para hacer eso, intentamos mover todas las características interesantes de Next a TurboPack, para que las tengamos en el núcleo, en el paquete. Y también disponibles para otros frameworks y Next.js, el sistema de compilación solo queda con algunas convenciones y un código de tiempo de ejecución específico de Next.js. Y eso es básicamente Next.js sobre TurboPack.

¿Cuáles son los próximos pasos? Los próximos pasos para Next.js, básicamente hicimos un lanzamiento alfa en la conferencia de Next.js y es de código abierto y básicamente buscamos comentarios. Obviamente, no está listo para su uso o no está listo para producción porque le faltan muchas características. Si queremos alcanzar la paridad de funciones con Next, ese es nuestro próximo paso. También queremos comenzar a utilizarlo internamente en nuestros propios sistemas, lo que brinda muchas pruebas y una conexión directa con las personas que lo prueban. Pero tú también puedes probarlo. Eso sería realmente útil. Por supuesto, hay muchos errores que corregir, como casos excepcionales que aún no hemos considerado y esas cosas. El próximo año queremos hacer un lanzamiento beta para que sea completo en funciones con Next.js y ponerlo en manos del público para probarlo. Pero nuestra visión es más amplia. Queremos que Turbo no sea opcional. Queremos que sea predeterminado. Probablemente llevará años hacerlo. Pero la visión es hacer que Turbo sea para todos. También tenemos muchas ideas. Cuando Turbo sea predeterminado, podremos deshacernos de la complejidad en el sistema antiguo, lo que realmente limita la innovación que podemos hacer. Queremos tener bloques de construcción más avanzados para generar ideas nuevas e innovadoras.

Y los próximos pasos para TurboPack básicamente son crear un sistema de complementos y mover el soporte de Next.js a un complemento y luego agregar más complementos de otros frameworks. No queremos que sea específico de Next.js. Realmente queremos agregar soporte de complementos y agregar más frameworks. Y esto debería ser algo utilizable por todos, por cada framework. Y no es específico de Next.js. Pero la visión es más amplia. Actualmente, un paquete no te brinda mucho control en tiempo de ejecución. Es realmente difícil probar la compilación de producción.

Debes reconfigurar el webpack para realizar una compilación de producción o hacer una compilación completa y probarla solo para verificar si funciona o si tienes errores exclusivos de producción. Queremos hacerlo más interactivo. Queremos darte control. En mi visión, hay un control deslizante en la interfaz de usuario del servidor de desarrollo donde puedes deslizarlo desde el desarrollo y la producción y probar la versión de producción de tu página solo en el servidor de desarrollo, y este tipo de experiencia es algo que queremos brindarte.

Y también hay más oportunidades de optimización. Actualmente, la capacidad de optimización en webpack está realmente limitada, ya que la mayoría de las optimizaciones más avanzadas tienen un costo de rendimiento muy alto. Por lo tanto, actualmente los módulos son la unidad más pequeña de optimización. Lo que podemos hacer en su lugar es dividir tus módulos en declaraciones y sentencias, lo que hace que sea la unidad más pequeña de optimización. Esto permite una eliminación de código más precisa. Puedes dividir módulos. Podemos dividir bibliotecas precompiladas en bloques de construcción. Podemos dividir módulos en diferentes fragmentos y realizar más optimizaciones para el usuario al mismo tiempo.

Para Turbo Engine, los próximos pasos ya están disponibles en código abierto. Pero no es realmente utilizable por sí solo. Pero realmente queremos hacer de Turbo Engine algo que también se pueda utilizar sin TurboPack. Puedes construir sobre él si quieres crear algo genial y optimizar incrementalmente las cosas. Faltan algunos pasos, como no tener un logotipo para ello. Y queremos estabilizar la API. Todavía estamos trabajando en ello. Podemos trabajar en ello mediante el uso de TurboPack. Eso es realmente genial. Y aún no hay documentación. Pero el plan es hacer un lanzamiento alfa, hacerlo utilizable por sí solo y luego se puede utilizar en otros escenarios que no sean solo el empaquetado. Pero la visión es aún más amplia. Actualmente, el gráfico de tareas está limitado a un usuario y un proceso. Y eso no es realmente lo que queremos hacer en el futuro. En el futuro, debería ser compartido con tu equipo, como mencioné antes. Debería ser un gráfico para todo tu equipo. Y pueden compartir módulos, compartir tareas y tareas computacionales.

Y apenas funciona porque puedes confiar en tu equipo que los cálculos que tu colega está haciendo, realizando todo el trabajo para tu caso. E incluso podemos ir más allá. Los cálculos aún ocurren en las máquinas locales. Pero podemos moverlos, al menos algunos de ellos, a la nube y hacer algún tipo de cálculo en el borde nube, que calcula parte de tu aplicación, si no quieres esperar tanto tiempo para que tu propia computadora lo construya. Esto es genial porque generalmente puedes confiar en la nube. Si confías en la nube, puedes obtener algo como almacenamiento en caché público, donde la nube... Cuando le pides a la nube que calcule algún módulo de nodo, es muy probable que alguien más en el mundo ya haya calculado este tipo de módulo de nodo antes. Entonces simplemente podemos usar esta capacidad de almacenamiento en caché público para hacerlo aún más rápido.

Pero también queremos brindarle más visibilidad. Por lo tanto, queremos tener más información sobre las compilaciones, queremos tener estadísticas de cómo se está desempeñando su compilación. Algunos de estos datos indican qué está afectando realmente el tiempo de compilación actual, y también algún tipo de sistema de linting o hinting para el rendimiento, donde puede describir... Esto no debería llevar más tiempo del que se indica, o lo que sea. Y también, esto es un analizador de paquetes en Webpack, pero también podría ser como un analizador de rendimiento de compilación, donde puede obtener el mismo tipo de información que un analizador de paquetes le brinda, pero para el proceso de compilación... ¿Cuánto tiempo están tomando los módulos? ¿Qué está afectando su rendimiento? Este módulo de nodo gigante está afectando todo el rendimiento, lo que sea. Y la misión de TurboGPro es obtener un almacenamiento en caché granular para todos. Todo el almacenamiento en caché granular que tenemos con TurboPack y Next.js, también podemos hacerlo para más operaciones, como otros marcos o para operaciones de archivos comunes y este tipo de cosas.

Gracias. Eso es todo lo que tengo que decir. Y si quieres encontrarme después, estoy en el stand de la empresa, o en la sala de preguntas y respuestas, o en la sala de discusión sobre rendimiento, o en la fiesta posterior. Día ocupado por ahí. Gracias. Por favor, pasa a mi oficina. Tengamos una charla rápida con Tobias sobre esto. Tenemos muchas preguntas. Vamos a responder algunas, y el resto, como recordatorio, puedes ir a verlo en la sala de oradores junto a la recepción. Entonces, ¿están listos? Primera pregunta. Creo que mencionaste esto un poco al principio. Pero, ¿por qué no lanzar lo mismo, pero como Webpack 6? ¿Por qué un nuevo producto? Lo hemos pensado. Pero el problema es que sigue siendo un cambio importante, como, no sería cómodo como Webpack 6 porque, como, básicamente obtienes alguna versión de Webpack 6, que es, como, Angular 2, que lo rompe todo. Y eso no es lo que el usuario espera. Creo que un nuevo nombre tiene sentido para una arquitectura completamente nueva. Que probablemente, si fuera Webpack 6, sería incompatible con todo lo anterior. Ninguno de los complementos funcionaría. Eso no es lo que queremos hacer. Un nuevo nombre tiene sentido para eso. Y también es más genial. Así que es principalmente una cosa diferente. Es una cosa diferente, pero con la misma motivación.

Pero también estamos trabajando en crear una buena historia de migración desde Webpack. Así que supongo que será una especie de complemento al estilo de Webpack, que te brinda la funcionalidad de Webpack. Con mucha configuración, al igual que cosas avanzadas para Webpack. Y en la herramienta, para facilitar la migración.

Es una transición perfecta a nuestra próxima pregunta, que es, ¿habrá rutas de migración de Webpack a Jerbo? Actualmente, no se puede migrar fácilmente porque no admitimos la mayoría de las cosas, pero una vez que lo hayamos hecho de manera que puedas migrar fácilmente, tendremos una puerta de migración avanzada con todo tipo de cosas. Realmente queremos que las personas que usan Webpack migren a Webpack, y por eso queremos ofrecer una buena guía de migración.

Hay una pregunta un poco picante sobre Webpack, que es que la configuración de Webpack era bastante complicada, según este preguntador, ¿se aborda de alguna manera este problema? Actualmente no tenemos ninguna configuración, pero el plan es... ¡Fácil! Sí, probablemente tendremos alguna configuración, pero sabemos que hay un problema con la configuración de Webpack, y no podemos solucionarlo fácilmente en Webpack debido a todos los cambios que romperían las cosas. Pero conocemos el problema y queremos hacerlo más fácil, eso es algo que tenemos en mente.

Bastante comprensible. Hay un par de preguntas aquí que se relacionan entre sí, y es un tema un poco preocupante, ya que está basado en Rust. ¿Será igual de sencillo integrarlo en un proyecto de JavaScript, o los complementos serán diferentes? ¿En qué lenguaje se escribirán? Actualmente ya está integrado en el ecosistema de JavaScript a través de Next.js, que lo utiliza. Next.js es técnicamente JavaScript, es una puesta en marcha, es JavaScript y luego se conecta a TurboPack. Por lo tanto, se puede integrar, es como un complemento nativo de NodeJS para la integración, pero también será probablemente algún tipo de ejecutable binario independiente, y haremos posible integrarlo. También, con nuestra historia de ofrecer complementos basados en JavaScript, podrá ejecutar código JavaScript e integrarse con eso. Por lo tanto, no todos tenemos que aprender Rust rápidamente.

Sí, no quiero esperar que los desarrolladores ejecuten Rust. Turbo aprender, por así decirlo. Sí, eso es lo que... Rust es una buena opción para el rendimiento, pero es muy difícil de aprender y de escribir. Por lo tanto, no me siento cómodo obligando a los desarrolladores a escribir complementos en Rust. No lo harán, y nadie quiere aprender Rust si solo trabajas en el desarrollo web. Por eso queremos ofrecer complementos de JavaScript y brindarte todo lo que... No tendrás que aprender Rust cuando quieras aprender TurboPack.

Me parece bien, ¡porque no sé Rust! Esta es divertida. ¿Es demasiado optimista esperar que TurboPack con Next salga de la versión beta antes del verano de 2023? Creo que no es demasiado optimista. ¡Ahí lo tienes! Al menos en la versión beta. Probablemente no será muy estable y listo para producción. Planeamos tener una versión beta a principios del próximo año que debería tener la mayoría de las características. Así que depende de cuán valiente te sientas, supongo. Básicamente, si tienes complementos personalizados de Webpack en Next.js, probablemente no tendremos esto hasta el verano. O tendrás que escribirlo en un sistema de complementos diferente. Pero al menos para el uso básico de Next.js, donde no tienes ninguna configuración avanzada, lo tendremos. Estoy bastante seguro de que tendremos esto a principios del próximo año, antes del verano. Debería estar bien.

Perfecto. Se nos acabó el tiempo para preguntas en el escenario, pero puedes encontrar a Tobias en la sala de preguntas y respuestas de los ponentes después de esto. Un aplauso. Por favor, gracias por acompañarnos. Gracias por tenerme.