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

Gracias por invitarme. Mi nombre es Tobias Cauras, soy de Alemania, y voy a contarles algo sobre 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.

Y hace casi 2 años comencé a unirme a Versil y trabajé con el equipo de Next.js en Next.js y la integración con Webpack y Next.js y cosas de rendimiento y cosas así. Y ahora, desde hace 10 meses, estoy trabajando en TurboPack y voy a contarles algo sobre eso.

En primer lugar, ¿cuál es nuestra misión con TurboPack? Así que nuestra misión es crear el sucesor de Webpack. Queremos alinearnos con el objetivo de Webpack, queremos hacer algún tipo de herramienta que sea realmente como Webpack, similar a Webpack y que cumpla al menos los objetivos de Webpack. Así que sé que es una misión realmente ambiciosa y tomará años o mucho tiempo llegar allí, pero al menos esa es nuestra dirección a la que estamos tratando de dirigirnos. Y esto básicamente nos motiva para nuestros objetivos del proyecto.

No queremos construir algo que sea solo para Next.js. Queremos construir algo que sea independiente del framework. No queremos construir algo que sea solo para Verzi. Queremos hacer algo que sea para la comunidad de código abierto, que sea un esfuerzo comunitario, y queremos alinearnos con los objetivos y la motivación detrás de Webpack. También queremos asegurarnos de que estamos construyendo algo que sea tan flexible y tan extensible como Webpack. Así que queremos seguir los pasos de Webpack de esa manera. Así que realmente queremos crear un bloque de construcción para el desarrollo web para los próximos diez años de desarrollo web. Objetivos ambiciosos. Sí.

Bien. Entonces, veamos qué llevó a la creación de TorbaPack en el pasado y también cómo funciona, y cuál es exactamente nuestra visión con TorbaPack. Así que comencé cuando me uní a Versa y trabajé con el equipo de Next.js, y básicamente queríamos resolver algunos desafíos de developer experience, y uno de estos desafíos era el performance. Funciona bastante bien, pero hay algunos desafíos con el performance, especialmente porque Next.js está construido principalmente con herramientas basadas en Javascript, y las herramientas basadas en Javascript para trabajos pesados de computación tienen dificultades para aprovechar todo el poder de tu computadora, por lo que aprovechar múltiples CPUs y realmente Javascript puede que no sea el mejor lenguaje para trabajos pesados de computación, o para construir cosas. El equipo de Next.js y yo comenzamos a trabajar en la portación de una parte de Next.js o de la infraestructura del compilador de web development al mundo de Rust, por lo que SWC se integró en Next.js, y realmente tiene muchos beneficios en términos de rendimiento. Pero también hubo algunos cambios en términos de integración. Siempre hay una frontera entre el mundo de JavaScript y el mundo de Rust, y tienes los problemas de serialización. Entonces, todavía hay desafíos mientras trabajamos en eso. También hubo algunas concesiones que tuvimos que hacer en Next.js para el performance. Un ejemplo fue que estamos resolviendo solicitudes de módulos en Webpack, y tuvimos que ser realmente optimistas al respecto para que sea como el rendimiento. Una vez que resolvimos algo con éxito, simplemente asumimos que esto 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 una especie de concesión, y no queremos vernos obligados a elegir eso. Pero también hay algunos desafíos de implementación en el equipo de Next.js.

Actualmente, Next.js está utilizando de cuatro a cinco compiladores Webpack para hacer todo este trabajo, uno para el cliente, para la renderización del servidor, para la renderización de borde, para varios componentes y un compilador de respaldo para mensajes de error. Todo este tipo de trabajo de orquestación ligera entre estos compiladores no es tan fácil. Está funcionando, 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 ser forzados a hacer.

Entonces, también hay algunos desafíos en el lado de WEPAC, así que WEPAC se construyó hace diez años, y todavía tiene la architecture de hace diez años donde las aplicaciones eran cientos de modules, y el web development escaló mucho en la última década, y, sí, entonces la architecture de WEPAC no se construyó realmente para este tipo de rendimiento de compilación incremental a gran escala. Eso es un problema, y no podemos solucionarlo fácilmente porque hay muchos plugins que dependen de la architecture de WEPAC, y es realmente difícil hacer cambios compatibles con versiones anteriores en la architecture, realmente no podemos cambiar la architecture mientras seamos compatibles con versiones anteriores. No queremos romper los casos de uso de todos cambiando la architecture de WEPAC, así que eso no es realmente una buena oportunidad para solucionar eso.

Por otro lado, solucionamos muchas cosas mientras trabajaba en Next.js en WEPAC para hacer más eficiente, pero tuvimos un límite en el tipo de optimización que podemos hacer sin reescribir todo. También hay otros desafíos como la invalidación de la caché. En muchos casos es demasiado sensible, así que como cambias algo y afecta, tiene que reconstruir una parte más grande de la aplicación, mientras que probablemente no está afectada. En un 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 architecture es este problema de costo de búsqueda en caché. Lo que hacemos al hacer una compilación incremental es que básicamente comenzamos de manera similar a una compilación completa, comenzamos a construirla, 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 en esa scale, si buscas, como, 10,000 modules de modules 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 como cuando estás hablando de unos segundos de reconstrucción. Si trabajas en el mundo nativo, podrías saber que tienen tiempos incrementales de minutos o algo así. ¡Sí, tenemos un problema realmente lujoso en el mundo del web development, supongo! Pero también hubo algunas oportunidades que podríamos abordar mientras trabajamos en un nuevo Bundler. Así que en mejor de los casos, tenemos esta herramienta llamada TurboRepo, y cuando la combinamos con Next.js, podemos aprender mucho el uno del otro. 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 cosa de observación incremental por defecto. Pero por otro lado, Next.js puede aprender de TurboRepo. TurboRepo tiene esta característica genial sobre el almacenamiento en caché remoto, por lo que en realidad puede compartir tu caché con tu equipo y se sube a la cloud o es una solución autohospedada. Y luego puedes compartir eso con tu equipo y no tienes que reconstruir lo que tus colegas han construido. Eso es genial. Queríamos tener eso en Next.js, como compartir caché con el equipo y compartir caché con el despliegue para que no tengas que hacer todo el trabajo dos veces. Pero hay algunas nuevas oportunidades. He visto que muchos desarrolladores en realidad quieren tener más información sobre el proceso de compilación. ¿Cuál es el tamaño de la página de los componentes, cuál es el tamaño de las dependencias y cómo las solicitudes de extracción afectan el cambio de mi aplicación o el cambio de performance de mi aplicación. Este tipo de información. Y queremos ofrecer más de estos tipos. También relacionado con el rendimiento de la compilación, estadísticas meta, ¿por qué mi compilación es lenta o cómo afecta el tiempo de mi compilación, este tipo de estadísticas.

Así que hicimos este plan mágico en el que teníamos 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 compilaciones incrementales y queríamos abstraer eso del Bundler. Así que el plan era construir algún tipo de motor central que resuelva estos problemas comunes y luego construir un Bundler encima de este motor central para que no tengamos que resolver estos problemas una y otra vez y cuidar de la invalidación de la caché en cada tipo de código que escribimos. Y luego, después de escribir este Bundler, solo queremos usarlo en Next o en otros frameworks para obtener los beneficios de este tipo de nueva idea, y eso es básicamente lo que hicimos.

Y siempre tuvimos en mente este objetivo de que las compilaciones incrementales deberían ser independientes del tamaño de la aplicación, lo que significa que mi aplicación puede crecer tanto como quiera, pero mis compilaciones incrementales deberían seguir siendo constantes en términos de rendimiento, por lo que siempre debería ser el mismo tiempo gastado en compilaciones incrementales. Básicamente, las compilaciones incrementales sólo deberían depender del tamaño de los módulos afectados o del cambio afectado en mi aplicación, no del tamaño total. Lo cual no es el caso de Webpack, por ejemplo.

Así que, sobre esta idea, construimos una especie de sistema de capas. Lo que planeamos hacer, queríamos usar Rust como una capa base, como lenguaje. La primera razón fue que queríamos usar SWC como analizador, porque no queríamos reescribir un nuevo analizador y generador de código y todas esas cosas. Así que queríamos usar eso, que está basado en Rust. Así que era una elección obvia usar Rust. Pero Rust también se ajusta bien a nuestros desafíos. Tiene un rendimiento predecible, tiene paralelismo, que es fácil de usar y compartir memoria y cosas así. También es un lenguaje seguro, con seguridad de memoria, lo cual es un buen punto para cosas remotas y por razones de seguridad. Pero también hay desventajas al usar Rust. Rust suele ser mucho más difícil de escribir en comparación con JavaScript. Y esto podría ser un problema, podría ser un problema de experiencia del desarrollador, cuando queremos ofrecer al desarrollador la posibilidad de escribir plugins.

Así que tomamos la decisión de que siempre queremos proporcionar JavaScript y Rust como una interfaz de plugins, por lo que siempre... Así que el plan es permitir siempre al desarrollador escribir los plugins ya sea en JavaScript o en Rust. JavaScript podría ser un poco más lento, pero en muchos casos, eso podría no ser relevante. Pero al final, siempre puedes empezar escribiendo tu plugin en JavaScript y portarlo a Rust después si descubres otras cosas, 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 como este motor central común, que resuelve estos problemas comunes, almacenamiento en caché, invalidación, y también una especie de abstracción, estos tipos de fuentes comunes de acceso externo, como el sistema de archivos, almacenamiento en caché, redes, cosas así. Y sobre TurboEngine, construimos TurboPack, que es simplemente un empaquetador. Básicamente hace todo lo que un empaquetador hace, como CSS, activos estáticos, lo que sea, ECMAScript, TypeScript, imágenes, fuentes, hay muchas cosas, en realidad. Y luego TurboPack puede ser utilizado por Next.js como una especie de empaquetador en reemplazo de Webpack. Pero también puede ser utilizado por otros frameworks, como lo que sea. Así que vamos a ver cómo funciona TurboEngine. Todo lo mágico de TurboEngine es la capacidad de escribir TurboFunctions, que es una función que anotas con algún tipo de anotación y se convierte en una TurboFunction. TurboFunctions significa que optas por la memorización de funciones para el almacenamiento en caché. Así que 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 la caché.

Así que rastreamos automáticamente todas las dependencias de la función. Entonces, 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 hacer todo este tipo de trabajo de gráfico interesante, como análisis de gráficos, en la parte superior de esto, como gráfico de cálculo o gráfico de tareas. Y también podemos, al rastrear la dependencia, programar automáticamente tu trabajo en segundo plano o en un grupo de hilos para hacer paralelismo automáticamente. Al rastrear la dependencia, significa que una vez que accedes a data desde diferentes tareas o diferentes TurboFunctions, podemos evadirlo en ese punto, porque lo rastreamos y hacemos, como, programación automáticamente y transplante 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 granular. Pero es solo una idea de lo que puedes esperar.

Tenemos este gráfico donde todas esas funciones, invocaciones, tareas, están conectadas con otras dependencias. Y lo que podemos hacer con este tipo de gráfico, podemos hacer incrementables 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 a recomputar el gráfico desde ese tipo de fuente externa. Y puedes básicamente burbujear el cambio a través del gráfico siguiendo el HS 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 que solo tenemos que tocar las tareas que realmente están afectadas por el cambio. Y también podemos detener el burbujeo del cambio. En este ejemplo, es como 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 detendrá el burbujeo del cambio a través del gráfico y podemos detenernos en cualquier punto. Pero también ves que podemos ejecutar automáticamente el código en paralelo. Como, ambas tareas dependen del análisis de TypeScript. Y podemos ejecutarlas en paralelo automáticamente. Y no tienes que pensar en este tipo de problemas comunes al escribir un paquete en la parte superior de TuberEngine. Esto resuelve muchos problemas. No tenemos este problema con JavaScript de un solo hilo, porque estamos escribiendo en Rust y tenemos programación automática y paralelización.

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

También resuelve el problema de muchas cargas de caché, porque para todos estos gráficos que son grises No tenemos que hacer nada. No tenemos que buscar en la caché. Simplemente está ahí, sin ser tocado por el cambio en absoluto. Así que simplemente no tiene ningún costo para una tarea inactiva. Lo que básicamente permite que puedas tener una aplicación tan grande como quieras, y tu cambio solo está afectado por... Tu cambio performance solo está afectado por la tarea que tienes que volver a calcular, lo cual es realmente mínimo. Así que, básicamente, nos da nuestro objetivo de que las compilaciones incrementales deberían ser independientes del tamaño de la aplicación.

Y encima de este tipo de sistema de TurboEngine construimos TurboPack, que es básicamente un bundler. Pero con dos grandes diferencias en comparación con WebPack. Así que tiene un sistema de entornos mixtos. Así que en un gráfico de activos de TurboPack básicamente puedes mezclar entornos. Así que puedes mezclar servidor y servidor importando un componente de cliente o estás importando una función de borde de un componente de servidor, lo que sea. Puedes mezclar entornos en el gráfico y es solo un compilador que se encarga de todos los gráficos. Y esto da muchos beneficios, como que podemos hacer una optimization entre entornos, como sacudir el árbol entre entornos y esas cosas. Muchas más oportunidades para optimizar tu código.

También tenemos este concepto sobre 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. Así que queremos tener algún tipo de sistema perezoso donde solo construimos un gráfico en un paquete. Construimos múltiples 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 derivan del gráfico anterior. Así que 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. Y 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 utilizan funciones para obtener referencias, que es una función Turbo. Y de esta manera, no tienes que construir el gráfico, simplemente lo construyes a demanda cuando lo accedes. Así que básicamente, esto significa que todo es perezoso por defecto. El gráfico completo se construye de manera perezosa. Y esto significa que solo si haces una solicitud HTTP al servidor de desarrollo, calculará y leerá tus archivos, construirá un gráfico modular.

Solo para ese tipo de gráfico, se necesita para atender 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, tratamos de mover todas las cosas geniales de Next a TurboPack, para que tengamos esto en el núcleo, en el paquete. Y también disponible para otros frameworks y Next.js, el sistema de construcción, solo queda con algunas convenciones y un poco de código de tiempo de ejecución específico de Next.js. Y eso es básicamente Next.js encima de TurboPack.

¿Y cuáles son los próximos pasos? Entonces, 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 retroalimentación. Obviamente no está listo para su consumo o no está listo para producción porque le faltan muchas características. Si queremos alcanzar la paridad de características con Next, ese es nuestro próximo paso. Y también queremos comenzar a dogfooding para nuestros propios sistemas, lo que da mucho testing y conexión directa con las personas que lo testing. Pero también puedes probarlo. Eso sería realmente útil. Por supuesto, hay muchos errores a corregir, como casos límite que aún no hemos considerado y esas cosas. Y el próximo año queremos hacer un lanzamiento beta para hacerlo completo en características con Next.js y darlo en manos del público y probémoslo. Pero nuestra visión es más grande. Queremos tener turbo no como una opción. Queremos hacerlo predeterminado. Probablemente tomará años hacer eso. Pero la visión es hacer turbo para todos. Y también tenemos muchas ideas. Cuando el turbo es la opción predeterminada, podemos deshacernos de la complejidad en el sistema antiguo, lo que realmente limita la innovation que podemos hacer. Entonces, queremos tener un bloque de construcción más advanced para generar ideas nuevas e innovadoras.

Y los próximos pasos para TurboPack es básicamente hacer un sistema de plugins y mover el soporte de Next.js a un plugin y luego agregar más plugins de otros frameworks. No queremos ser específicos de Next.js. Realmente queremos agregar soporte para plugins 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 grande. Entonces, actualmente un paquete no te da mucho control en tiempo de ejecución. Entonces, es realmente difícil probar la construcción de producción.

Tienes que reconfigurar el webpack para hacer una compilación de producción o tienes que hacer una compilación completa y probarla solo para probarla, si está funcionando, o si tienes errores solo de producción. Queremos hacerlo más interactivo. Queremos darte control. En mi visión, hay un deslizador en el servidor de desarrollo UI donde puedes deslizarlo de desarrollo a producción y probar la versión de producción de tu página justo en el servidor de desarrollo, y esta clase de experiencia debería ser algo que queremos darte.

Y también hay más oportunidades de optimization. Actualmente la capacidad de optimization en webpack está realmente limitada por la mayoría de las optimization más advanced tiene un costo de performance realmente grande. Así que actualmente los modules son la unidad más pequeña de optimization. Entonces, lo que podemos hacer en su lugar es que podemos dividir tus modules en declaraciones y declaraciones que hacen de esto la unidad más pequeña de optimization. Esto hace que el tree shaking sea realmente más granular. Puedes dividir modules. Podemos dividir las bibliotecas pre-empaquetadas en los bloques de construcción. Podemos dividir modules en diferentes chunks y hacer más optimization para el usuario a la vez.

Para Turbo Engine, los próximos pasos ya están en código abierto. Pero no es realmente consumible por sí solo. Pero realmente queremos hacer de Turbo Engine algo que también sea consumible sin TurboPack. Puedes construir encima de él si quieres construir algo genial y optimizar incrementalmente las cosas. Entonces, faltan algunos pasos, como que no tenemos un logo para ello. Y queremos estabilizar la API. Así que todavía estamos evolucionando. Podemos evolucionar trabajando en TurboPack. Eso es realmente genial. Y todavía no hay documentation. Pero el plan es hacer un lanzamiento alfa, hacerlo utilizable de forma independiente. Y luego puede ser utilizado en otros escenarios que no sean el bundling tal vez. Pero la visión es aún más grande. Así que actualmente el gráfico de tareas está limitado a un usuario para un proceso. Y eso no es realmente lo que queremos hacer en el futuro. Así que en el futuro debería ser compartido con tu equipo, como mencioné antes. Debería ser como un gráfico para tu equipo. Y pueden compartir como modules, compartir tareas y tareas computacionales.

Y apenas funciona porque puedes confiar en tu equipo en que los cálculos que tu colega está trabajando, haciendo todo el trabajo para tu caso. Y podemos ir incluso más allá. Los cálculos todavía ocurren en máquinas locales. Pero podemos trasladarlos, al menos algunos de ellos a la cloud y hacer algún tipo de cálculo en el borde de la cloud, que calcula parte de tu aplicación, si no quieres esperar tanto tiempo para que tu propio ordenador la construya. Esto es genial porque normalmente puedes confiar en la cloud. Si confías en la cloud, puedes obtener algo como almacenamiento en caché público, donde la cloud... Cuando le pides a la cloud que calcule algún módulo de nodo, hay una buena posibilidad de que alguien más en el mundo ya haya calculado este tipo de módulo de nodo antes. Así que podemos usar esta capacidad de almacenamiento en caché público para hacerlo aún más rápido.

Pero también queremos darte más visibilidad. Así que queremos tener más información sobre las construcciones, queremos tener estadísticas de cómo tu construcción está funcionando. Algo de esto, que dice qué es lo que realmente está afectando el tiempo de construcción actual, y también algún tipo de sistema de linting o de sugerencias para performance, donde puedes describir... Esto no debería tardar más de cierto tiempo, 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 performance de construcción, donde puedes tener el mismo tipo de información que te da un analizador de paquetes, pero para el proceso de construcción... ¿Cuánto tiempo están tomando los modules? ¿Qué está afectando tu performance? Este gigantesco y enorme módulo de Node está afectando toda la performance, lo que sea. Y la misión de TurboGPro es conseguir un caché granular para todos. Todo el caché granular que tenemos con TurboPack con Next.js, también podemos hacerlo para más operaciones, como otros frameworks, 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, estaré en el stand del barco, o en la sala de preguntas y respuestas, o en la sala de discusión de performance, o en la fiesta posterior. Día ajetreado por ahí. Gracias. Por favor, entra en mi oficina. Vamos a tener una charla rápida con Tobias sobre esto. Teníamos muchas preguntas. Vamos a llegar a un par, y el resto, solo como recordatorio, puedes ir a verlo en la sala de conferencias junto a la recepción. Entonces, ¿están arriba? Primera pregunta. Creo que tocaste esto un poco al principio. ¿Pero por qué no lanzar lo mismo, pero como Webpack 6? ¿Por qué un nuevo producto? Pensamos en eso. Pero el problema es que todavía es un gran cambio rompedor para ser, como, no sería cómodo como Webpack 6 porque es, como, básicamente obtienes una versión de Webpack 6, que es, como, Angular 2, que 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. Todos los plugins no funcionarían. Eso no es lo que queremos hacer. Un nuevo nombre tiene sentido para eso. Y también es más cool. Así que es principalmente una cosa diferente. Es una cosa diferente, pero con la misma motivación.

Pero también estamos trabajando en hacer una buena historia de migración desde Webpack. Así que supongo que será algún tipo de plugin al estilo Webpack, que te da el tipo de cosa Webpack. Con mucha configuración, mucho como las cosas advanced para Webpack. Y en la herramienta, para facilitar la migración.

Es una perfecta introducción a nuestra siguiente pregunta, que es, ¿habrá caminos de migración desde Webpack a Jerbo? Así que una vez que - como, actualmente no puedes migrar realmente aún, porque no soportamos la mayoría de las cosas, pero una vez que lo hayamos hecho de manera que puedas migrar fácilmente, tendremos como una guía de migración advanced con todo tipo de cosas. Realmente queremos llevar a la gente de Webpack a Webpack, y por eso queremos ofrecer una buena guía de migración.

Hay una pregunta un poco picante sobre Webpack, que es, la configuración de Webpack era bastante complicada, según esta persona, ¿se aborda de alguna manera este problema? Así que actualmente no tenemos ninguna configuración, así que - 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 rompedores y cosas como esa, pero sabemos sobre el problema y queremos hacerlo más fácil, y eso es definitivamente algo que tenemos en mente.

Justo. Hay un par de preguntas aquí que están un poco relacionadas, que es un poco un problema nervioso, ya que se basa en Rust. ¿Será igual de sencillo integrarlo en un proyecto de JavaScript, o los plugins serán diferentes? ¿En qué lenguaje estarán? Así que actualmente ya está integrado en el ecosistema de JavaScript ya que Next.js lo está usando por lo que Next.js es técnicamente JavaScript, es un inicio, es JavaScript y luego llama a TurboPack. Y así se puede integrar, es como un plugin nativo de NodeJS para integrar, pero probablemente también será algún tipo de ejecutable binario independiente, y haremos posible integrarlo. También con nuestra historia de que queremos ofrecer plugins basados en JavaScript, será capaz de ejecutar código JavaScript e integrarse con eso. Así que no todos tenemos que aprender Rust muy rápido.

Sí, no quiero esperar que los desarrolladores corran Rust. Aprender Turbo, si quieres. Sí, eso es lo que... Rust es una buena elección para el rendimiento, pero es realmente difícil de aprender y de escribir. Así que no me siento cómodo obligando a los desarrolladores a escribir plugins en Rust. No lo harán, y nadie quiere aprender Rust si solo estás trabajando en desarrollo web. Así que queremos ofrecer plugins de JavaScript y darte todo el... No tendrás que aprender Rust cuando quieras aprender TurboPack.

Me parece bien, porque no sé Rust! Esta es una divertida. ¿Es demasiado optimista esperar que TurboPack con Next salga de la beta antes del verano de 2023? Creo que no es demasiado optimista. ¡Ahí lo tienes! Al menos en versión beta. Probablemente no será super estable y listo para producción. Planeamos 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 plugins personalizados de Webpack en Next.js, probablemente no tendremos esto hasta el verano. O tendrás que escribirlo en un sistema de plugins diferente. Pero al menos para el uso básico de Next.js, donde no tienes ninguna configuración advanced, lo tendremos. Estoy bastante seguro de que lo tendremos a principios del próximo año para el verano. Debería estar bien.

Perfecto. Nos hemos quedado sin tiempo para preguntas en el escenario, pero puedes encontrar a Tobias en la sala de preguntas y respuestas de los oradores después de esto. Un aplauso. Por favor, gracias por unirte a nosotros. Gracias por invitarme.