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

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

FAQ

TurboPack busca ofrecer un sistema más avanzado de gestión de caché y compilaciones incrementales independientes del tamaño de la aplicación, utilizando un modelo de paralelismo y un sistema de entornos mixtos en sus gráficos de activos. Está diseñado para ser más eficiente y menos susceptible a errores de invalidación de caché.

Rust fue elegido por su rendimiento predecible, facilidad para manejar paralelismo y seguridad en la gestión de memoria, características ideales para abordar los desafíos de rendimiento y seguridad en el desarrollo de TurboPack.

No, TurboPack está diseñado para ser independiente del marco de trabajo y no específico para Versil. Aunque puede usarse eficientemente con Next.js, está destinado a ser utilizable con múltiples frameworks en la comunidad de código abierto.

TurboPack intenta superar limitaciones como la arquitectura antigua de Webpack, problemas de rendimiento con compilaciones incrementales a gran escala y desafíos con la invalidación de caché demasiado sensible.

Se espera que TurboPack alcance una versión beta a principios del próximo año, con la mayoría de las funciones implementadas, aunque no necesariamente estará listo para producción inmediata.

TurboPack es una herramienta diseñada para ser el sucesor de Webpack, con la misión de alinearse con los objetivos de Webpack y crear una herramienta similar que sea flexible y extensible. Su objetivo es ser un bloque de construcción clave para el desarrollo web en los próximos diez años.

Tobias Koppers
Tobias Koppers
32 min
02 Dec, 2022

Comments

Sign in or register to post your comment.
Video Summary and Transcription
La charla discute TurboPack, un sucesor de Webpack, con el objetivo de crear una herramienta independiente del framework, flexible y extensible para la comunidad de código abierto. Aborda los desafíos de rendimiento integrando SWC en Next.js. Los desafíos con Next.js y Webpack incluyen problemas de orquestación, restricciones de compatibilidad hacia atrás y problemas de invalidación de caché. TurboEngine y TurboPack proporcionan un rendimiento constante en compilaciones incrementales, aprovechando el rendimiento predecible y el paralelismo de Rust. La charla también cubre temas como el seguimiento de dependencias, gráficos de tareas, invalidación de caché, gráficos de activos perezosos y la integración de TurboPack con Next.js. Los planes futuros involucran reconfigurar Webpack y TurboEngine, mover cálculos a la nube, proporcionar información sobre las compilaciones y facilitar la migración e integración con proyectos de JavaScript.

1. Introducción a TurboPack

Short description:

Comencé con el desarrollo web hace 10 años, fundé y mantuve Webpack durante 10 años. Ahora estoy trabajando en TurboPack, el sucesor de Webpack, con la misión de crear una herramienta similar a Webpack que se alinee con sus objetivos. Nuestro objetivo es construir algo independiente del framework, para la comunidad de código abierto, y tan flexible y extensible como Webpack. Nuestra meta es crear un bloque de construcción para los próximos diez años de desarrollo web.

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í.

2. Creación de TorbaPack y Desafíos de Rendimiento

Short description:

Queríamos resolver algunos desafíos de experiencia del desarrollador, uno de los cuales era el rendimiento. Next.js, al estar construido principalmente con herramientas basadas en Javascript, enfrentaba desafíos para aprovechar al máximo el poder de la computadora. Para abordar esto, integramos SWC en Next.js, lo que resultó en un rendimiento mejorado. Sin embargo, se hicieron concesiones para el rendimiento, como asumir que las solicitudes de módulos y los módulos de Node no cambian. El equipo de Next.js también enfrentó desafíos de implementación.

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.

3. Desafíos con Next.js y Webpack

Short description:

Actualmente, Next.js está utilizando varios compiladores de Webpack para diferentes propósitos, pero la orquestación entre ellos es desafiante y propensa a errores. La arquitectura de Webpack, que tiene más de una década, no está diseñada para el rendimiento de compilaciones incrementales a gran escala. Arreglar esto es difícil debido a las restricciones de compatibilidad hacia atrás y la dependencia de los plugins. La invalidación de la caché y los costos de búsqueda también son problemas, especialmente cuando se trata de un gran número de módulos. A pesar de estos desafíos, existen oportunidades para mejorar el proceso de compilación aprovechando herramientas como TurboRepo y aprendiendo de sus características como el almacenamiento en caché granular y el almacenamiento en caché remoto. Además, los desarrolladores buscan más información sobre el proceso de compilación, incluido el tamaño de los componentes y las dependencias, y el impacto de las solicitudes de extracción en el rendimiento de la aplicación.

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.

4. Construyendo un Motor Central y un Empaquetador

Short description:

Tuvimos la idea de construir un motor central para resolver desafíos comunes como el almacenamiento en caché, la invalidación, el modo de observación y las compilaciones incrementales. Luego construimos un Empaquetador encima de este motor para evitar resolver estos problemas repetidamente. El objetivo era utilizar este Empaquetador en Next.js y otros marcos de trabajo para beneficiarse de este nuevo enfoque.

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.

5. Construyendo TurboEngine y TurboPack

Short description:

Apuntamos a un rendimiento constante en las compilaciones incrementales, independientemente del tamaño de la aplicación. Construimos un sistema de capas utilizando Rust como lenguaje base, aprovechando su rendimiento predecible, paralelismo y seguridad de memoria. Proporcionamos tanto JavaScript como Rust como interfaces de plugins, permitiendo a los desarrolladores elegir la opción más adecuada. TurboEngine, construido sobre Rust, resuelve problemas comunes como el almacenamiento en caché y la invalidación. TurboPack, un empaquetador, puede ser utilizado por Next.js y otros frameworks. La magia de TurboEngine radica en TurboFunctions, que permiten la memorización de funciones para el almacenamiento en caché y la invalidación de la caché.

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é.

6. Seguimiento de Dependencias y Gráfico de Tareas

Short description:

Rastreamos automáticamente las dependencias de las TurboFunctions y construimos un gráfico de tareas. Este gráfico permite realizar análisis de gráficos interesantes y programar automáticamente el trabajo en paralelo. Al rastrear las dependencias, podemos optimizar la programación y utilizar TurboEngine de manera efectiva.

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.

7. Gráfico de Tareas e Incrementales

Short description:

Un gráfico de tareas consta de múltiples tareas por módulo en una aplicación web, lo que permite un seguimiento granular de las dependencias y las compilaciones incrementales. Los cambios pueden propagarse a través del gráfico siguiendo las dependencias hacia atrás, actualizando solo las tareas afectadas. Este enfoque ofrece beneficios como optimizar el rendimiento al ejecutar tareas en paralelo y evitar las limitaciones de JavaScript de un solo hilo aprovechando la programación automática y la paralelización de Rust.

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.

8. Resolviendo la Invalidación de Caché y los Gráficos de Activos Perezosos

Short description:

TurboPack es un empaquetador que resuelve los problemas de invalidación de caché, invalidación de caché demasiado sensible y muchas cargas de caché. Permite mezclar entornos en el gráfico de activos, lo que permite la optimización entre entornos y más oportunidades para la optimización del código. TurboEngine se encarga de las compilaciones incrementales e introduce el concepto de gráficos de activos perezosos, donde los gráficos se construyen a demanda. El gráfico completo se construye de manera perezosa, reduciendo la necesidad de construir todas las tareas desde el inicio.

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.

9. Integración de TurboPack y Next.js

Short description:

Queremos usar TurboPack en Next.js y otros frameworks, convirtiéndolo en la opción predeterminada. Nuestros próximos pasos incluyen alcanzar la paridad de características con Next.js, comenzar a dogfooding y planear una versión beta para el próximo año. Nuestra visión es hacer de TurboPack la opción predeterminada para todos, permitiendo bloques de construcción más avanzados e ideas innovadoras. Los próximos pasos para TurboPack implican la creación de un sistema de plugins, agregar soporte para otros frameworks y proporcionar más control en tiempo de ejecución.

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.

10. Reconfigurando Webpack y Turbo Engine

Short description:

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. También hay más oportunidades de optimización. Actualmente, los módulos son la unidad más pequeña de optimización. Podemos dividir tus módulos en declaraciones y declaraciones, haciéndolo más granular. Para Turbo Engine, los próximos pasos implican hacerlo consumible sin TurboPack, estabilizar la API y hacerlo utilizable en otros escenarios. La visión es tener un gráfico de tareas compartido para que los equipos compartan módulos y tareas computacionales.

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.

11. Traslado de Cálculos a la Nube

Short description:

Los cálculos se pueden trasladar a la nube, lo que permite una construcción de aplicaciones más rápida. Se puede aprovechar el almacenamiento en caché público en la nube para acelerar el cálculo de los módulos de nodo comunes.

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.

12. Información sobre las Construcciones y Caché Granular

Short description:

Queremos ofrecerte más información sobre las construcciones y estadísticas sobre el rendimiento. TurboGPro tiene como objetivo proporcionar caché granular para todos, extendiéndolo a otros marcos de trabajo y operaciones de archivos comunes. Gracias.

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.

13. Migración, Integración y Planes Futuros

Short description:

Estamos trabajando en un plugin al estilo Webpack para facilitar la migración de Webpack a Jerbo. Aunque la configuración de Webpack es compleja, planeamos abordar este problema y facilitarla. TurboPack se puede integrar en proyectos de JavaScript, y ofreceremos plugins basados en JavaScript para una integración más fácil. No se requiere Rust para el desarrollo de plugins. Esperamos que TurboPack con Next esté en beta a principios del próximo año, y debería ser adecuado para el uso básico de Next.js.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Vite: Repensando las Herramientas de Frontend
JSNation Live 2021JSNation Live 2021
31 min
Vite: Repensando las Herramientas de Frontend
Top Content
Vite is a next-generation build tool that leverages native ES modules for improved performance. It eliminates the need for bundling and improves hot module replacement. Vite provides an opinionated default configuration while still allowing advanced customization through plugins. It is framework agnostic and can be used for React and other applications. Vite is being adopted by Next.js and Create React App, and integration with Nuxt 3 offers significant speed improvements.
Compilador React Forget - Entendiendo React Idiomático
React Advanced 2023React Advanced 2023
33 min
Compilador React Forget - Entendiendo React Idiomático
Top Content
Joe Savona
Mofei Zhang
2 authors
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
Acelerando tu aplicación React con menos JavaScript
React Summit 2023React Summit 2023
32 min
Acelerando tu aplicación React con menos JavaScript
Top Content
Mishko, the creator of Angular and AngularJS, discusses the challenges of website performance and JavaScript hydration. He explains the differences between client-side and server-side rendering and introduces Quik as a solution for efficient component hydration. Mishko demonstrates examples of state management and intercommunication using Quik. He highlights the performance benefits of using Quik with React and emphasizes the importance of reducing JavaScript size for better performance. Finally, he mentions the use of QUIC in both MPA and SPA applications for improved startup performance.
SolidJS: ¿Por qué tanto Suspense?
JSNation 2023JSNation 2023
28 min
SolidJS: ¿Por qué tanto Suspense?
Top Content
Suspense is a mechanism for orchestrating asynchronous state changes in JavaScript frameworks. It ensures async consistency in UIs and helps avoid trust erosion and inconsistencies. Suspense boundaries are used to hoist data fetching and create consistency zones based on the user interface. They can handle loading states of multiple resources and control state loading in applications. Suspense can be used for transitions, providing a smoother user experience and allowing prioritization of important content.
Los Átomos de Jotai Son Simplemente Funciones
React Day Berlin 2022React Day Berlin 2022
22 min
Los Átomos de Jotai Son Simplemente Funciones
Top Content
State management in React is a highly discussed topic with many libraries and solutions. Jotai is a new library based on atoms, which represent pieces of state. Atoms in Jotai are used to define state without holding values and can be used for global, semi-global, or local states. Jotai atoms are reusable definitions that are independent from React and can be used without React in an experimental library called Jotajsx.
De GraphQL Zero a GraphQL Hero con RedwoodJS
GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
De GraphQL Zero a GraphQL Hero con RedwoodJS
Top Content
Tom Pressenwurter introduces Redwood.js, a full stack app framework for building GraphQL APIs easily and maintainably. He demonstrates a Redwood.js application with a React-based front end and a Node.js API. Redwood.js offers a simplified folder structure and schema for organizing the application. It provides easy data manipulation and CRUD operations through GraphQL functions. Redwood.js allows for easy implementation of new queries and directives, including authentication and limiting access to data. It is a stable and production-ready framework that integrates well with other front-end technologies.

Workshops on related topic

Uso de CodeMirror para construir un editor de JavaScript con Linting y AutoCompletado
React Day Berlin 2022React Day Berlin 2022
86 min
Uso de CodeMirror para construir un editor de JavaScript con Linting y AutoCompletado
Top Content
Workshop
Hussien Khayoon
Kahvi Patel
2 authors
Usar una biblioteca puede parecer fácil a primera vista, pero ¿cómo eliges la biblioteca correcta? ¿Cómo actualizas una existente? ¿Y cómo te abres camino a través de la documentación para encontrar lo que quieres?
En esta masterclass, discutiremos todos estos puntos finos mientras pasamos por un ejemplo general de construcción de un editor de código usando CodeMirror en React. Todo mientras compartimos algunas de las sutilezas que nuestro equipo aprendió sobre el uso de esta biblioteca y algunos problemas que encontramos.