Rust Meets React: Adentrándose en la Próxima Generación de la Canalización de Construcción para Aplicaciones React

Cómo empezar con React Cuando pensamos en nuestra configuración favorita, rápidamente, esto viene a nuestra mente. No la pantalla de Windows XP, sino en realidad un proyecto Greenfield. Y ahí es donde ya comienza. Cuando pensamos en un proyecto Greenfield, tenemos que tomar muchas decisiones. En primer lugar, ¿qué framework usamos? ¿Vamos con React puro, con Solid? ¿Usamos algo como React Router, Waku, CanStick Start? ¿O vamos con Laravel más React, o Rails? ¿O vamos con Next.js? Y, por supuesto, esta es solo una de muchas elecciones. Pensamos en todas las bibliotecas que podemos elegir para la gestión de estado, UI, etc.

Y una vez más, ni siquiera hablando de meta frameworks y así sucesivamente. Y luego, cuando pensamos en el código de la aplicación, bien, ahí vamos. Pero también deberíamos escribir pruebas. Así que ahí también tenemos una gran elección de, bueno, por supuesto, los entornos de ejecución que en realidad ofrecen ejecutores de pruebas hoy en día, desde herramientas de prueba de extremo a extremo, o también ejecutores de pruebas simples y cosas más complejas. Y a veces no es suficiente una sola herramienta, sino que necesitas múltiples. Una para extremo a extremo y otra para ejecutar el resto. Y una vez más, te digo, esto no es el final todavía.

También tenemos que pensar en cosas como el linting, el formateo, y el propio entorno de ejecución que mencionamos, y así sucesivamente, así sucesivamente, así sucesivamente. Y aún no hemos escrito ninguna línea de código de aplicación, donde a menudo también incorporamos otras dependencias. Así que el problema clásico de la elección en realidad se multiplica por, bueno, incluso más botones que los que ves aquí. Y si te digo ahora que esto también significa que todas las herramientas que eliges en tu canalización de construcción, pueden depender de diferentes cosas bajo el capó que no son necesariamente compatibles, y puede que ni siquiera sepas sobre eso. Bueno, está claro por qué las construcciones se vuelven lentas y los bucles de retroalimentación se vuelven lentos.

Así que, bienvenido a mi charla, Rust Meets React, sumergiéndonos en la próxima generación de canalización de construcción para aplicaciones React aquí en React Advanced London 2025. Unas palabras sobre mí, soy Alex. Soy DevRel en Void Zero, también Consultor de Ingeniería Web, Orador e Instructor, como puedes ver aquí. También soy parte del equipo de Nuxt, así que un poco de intruso viniendo a la Conferencia Roja aquí desde el lado de Vue. Sin embargo, también publico regularmente en redes sociales, YouTube, y si encuentro el tiempo, también hago transmisiones en vivo en Twitch. Pero eso es raramente el caso hoy en día. También tengo un sitio web de portafolio, pero bueno, como todos saben cómo es con los sitios web de portafolio, suelen ser los últimos en la cadena de actualizaciones, pero estamos llegando allí. Pero volviendo a la charla. Técnicamente, queremos lo mejor para nuestro proyecto, los mejores frameworks, las mejores herramientas. Y si pensamos en lo que significa lo mejor, bueno, eso significa que deberían ser fáciles de usar, ¿verdad? Y también fáciles de configurar. Definitivamente queremos asegurarnos de que funcionen juntos sin problemas para nuestras necesidades, no solo en general, sino también para nuestro escenario. Deberías tener una gran documentación, un ecosistema rico, por supuesto, porque no queremos reinventar la rueda.

Deberían ser adecuadamente rápidas, ¿verdad? Confiables, preparadas para el futuro. Siempre es una gran palabra, pero también es como que no quieres reescribir tu aplicación cada par de meses o años. {{^}}Deberían ser extensibles y adaptables, para que una vez más, podamos adaptarlas a nuestras necesidades empresariales, especialmente porque también podrían cambiar de vez en cuando. Y también el mantenimiento en general. La forma de mantener esto es importante, así que nos aseguramos de que también se liberen correcciones de errores y nuevas características, y así sucesivamente. Pero todo esto se puede resumir en que queremos una gran experiencia de desarrollador.

Y si comenzáramos un proyecto Greenfield ahora, genial, podemos elegir las mejores herramientas que podamos imaginar, y podemos comenzar bien. Pero desafortunadamente, la mayoría de nosotros realmente no trabajamos en un proyecto Greenfield, por así decirlo. De lo contrario, bueno, supongo que puedes considerarte afortunado por eso. Pero te diré algo. En esta charla, repasamos cómo podemos realmente recuperar un poco de esas vibraciones de Greenfield directamente en tu proyecto, al menos para la canalización y la experiencia del desarrollador. Y hay una cosa simple para comenzar, y esto es VEET, también conocido como la infraestructura compartida del desarrollo monolab.

Para los usuarios de Next.js por ahí, primero que nada, lo siento, pero no te preocupes. Habrá mucho contenido para ti aquí también. Espera un segundo, llegaremos allí. Pero volviendo a eso por un segundo. Así que VEET te ofrece, por supuesto, un servidor de desarrollo con recarga de módulos en caliente, soporte nativo de ESM, configuraciones predeterminadas muy agradables, un rico ecosistema de plugins. Así que puedes elegir cualquier framework basado en JSX que desees y también integrarte fácilmente con metaframeworks, como 10-Stack Start siendo un plugin de VEET hoy en día, ¿verdad? Obtienes construcciones de producción optimizadas, gracias a rollup, bajo el capó, y mucho más.

Pero si echas un vistazo a VEET, aunque no es perfecto, por supuesto, la pila actual de VEET es realmente bastante interesante porque VEET es una herramienta de construcción que utiliza diferentes empaquetadores bajo el capó. Aquí tenemos, en primer lugar, ESBuild escrito en Go, y se utiliza para algunas pequeñas tareas de pre-empaquetado para transformaciones y para minificación en una construcción de producción. Y luego tenemos rollup, que hace la mayor parte del trabajo para la construcción de producción, ¿verdad? El empaquetado en sí para producción. Tiene la API de plugins que todos amamos, y también en la que se basan los plugins de VEET. Y también puede hacer algún control de fragmentos aquí y allá. Y luego, para todas las personas que prefieren cosas aún más rápidas, hay SWC como una alternativa para hacer transformaciones y también para React fast refresh. Pero la mayoría de ustedes están familiarizados con eso, por supuesto.

Ahora, tres herramientas bajo el capó para VEET es, bueno, es un poco complicado, ¿verdad? Hace las cosas más difíciles. Y a veces surge la idea, ¿por qué no unificar este empaquetador subyacente? Así que en lugar de decir, oye, tenemos tres herramientas, deshagámonos de todas ellas y en su lugar usemos una nueva herramienta llamada Rolldown. Y ahora podrías pensar, bueno, está bien, ¿por qué una cuarta herramienta? ¿Por qué otro empaquetador? Y tal vez algunos de ustedes piensen, espera, ¿qué es un empaquetador, en realidad? ¿Y por qué necesito uno? Así que respondamos esa pregunta rápidamente.

En primer lugar, tenemos este encantador gráfico aquí. Realmente no tienes que entrar en los detalles porque básicamente es solo un gráfico de dependencias, pero no se trata necesariamente de módulos de Node aquí. Aunque para ser justos, hay algunos. Los verdes son módulos de Node, pero el resto son en realidad solo archivos en uno de los muchos, muchos proyectos. Así que archivos que dependen unos de otros o donde importas diferentes archivos, etc. Y un empaquetador toma este, digamos, gráfico complicado y lo convierte en eso. Sí, no es solo otra representación. Este es un gráfico de mapa de árbol. Y aquí ves que las cosas se combinan de cierta manera. Todos los colores son básicamente como un archivo JavaScript por color. Así que tienes un azul claro aquí, ¿verdad? Como tienes uno travieso que es bastante grande. Luego tienes en la parte inferior el índice y como un color rojo óxido, anaranjado y en la parte superior atajos y así sucesivamente. Finalmente, estas son las diapositivas aquí. También hechas con SlideF y Vite. Bajo el capó. Y sí, el empaquetador básicamente está haciendo esto en esta representación. Pero ahora podrías preguntarte, está bien, ¿por qué necesitamos esto? ¿Por qué necesitamos combinar todos estos archivos que hemos visto antes? Podemos simplemente lanzarlos todos, ¿verdad? Y hay algunas personas que piensan lo mismo. Yo digo, mira, no necesitamos construir. De hecho, ¿por qué necesitamos siquiera un paso de construcción? Más famoso, DHH dijo eso hace un par de años en RailsWorld, ¿verdad? Pero estoy aquí para decirte, bueno, en cierto modo sí necesitamos un paso de construcción. Así que adelante y construye.

Déjame decirte por qué exactamente. Comenzamos simple con esto. Todos saben qué es esto. Este es un componente JSX. Y estaría muy curioso si alguien pudiera mostrarme un ejemplo de simplemente escribir JSX en el navegador para que el navegador lo entienda sin un paso de construcción intermedio. Curiosamente, esto también se aplica a otros componentes personalizados como Svelte, Vue, etc, etc. Y también este de aquí, ¿verdad? Tenemos, por supuesto, este TypeScript, ¿verdad? También, TypeScript incorrecto porque el número no es igual a la cadena uno. Eso no encaja en términos de tipo. Pero sin embargo, también aquí necesitarías un paso de construcción o al menos una forma de eliminar estos tipos si usas la llamada sintaxis borrable. Si usas enums, por ejemplo, o namespaces, entonces realmente necesitas generar algo de código y no es suficiente simplemente eliminar los tipos. Así que también aquí necesitamos al menos algún tipo de paso de construcción.

Y, bueno, hasta ahora todo bien. Hay dos cosas que usamos comúnmente, ¿verdad? JSX y TypeScript. Así que aquí hay otro. Digamos que tenemos una biblioteca y solo queremos usar una función. Entonces, por supuesto, no queremos importar todas las otras, digamos, un millón de funciones de date F y S aquí. En su lugar, solo queremos tomar format y lo que sea que format esté llamando bajo el capó. El problema es, bueno, usualmente no es así como funciona. Simplemente obtienes todo a menos que tu, bueno, paso de construcción, tu empaquetador esté haciendo alguna eliminación de código muerto, también conocida como tree shaking. Así que para hacer eso, una vez más, necesitas un paso de construcción.

Y luego hay una cosa más. Esta de aquí. Tómate unos segundos para pensar qué es. Probablemente la mayoría de ustedes ya lo adivinó. Quiero decir, estamos en React avanzado aquí, ¿verdad? Este es código minificado, en realidad código minificado de justo antes. Así que ese código justo aquí, por supuesto, no el completo que sería unas cuantas líneas más de 20, pero vemos algunas cosas como T por siete podría ser débil. T por 365.2425 podría ser un año completo, etc, etc. Así que vemos que el código está ahí. Y por supuesto queremos minificar el código para asegurarnos de reducir nuestro tamaño de paquete, lo que significa aplicaciones pequeñas, menos ancho de banda y usuarios felices porque pueden descargar tu aplicación más rápido. Así que el TLDR de qué es un empaquetador? Bueno, ¿por qué necesitas uno? El empaquetador está ahí para transformar un código no JavaScript en JavaScript.

Elimina el código no utilizado de las dependencias, ¿verdad? Recombina el código que usas en archivos. Así que no tienes que descargarlos todos a la vez. Por ejemplo, un código no utilizado se puede descargar más tarde. No tienes que hacerlo de inmediato, ¿verdad? Así que eso significa JavaScript a demanda, lo cual es bastante asombroso y por lo tanto reduce las solicitudes de red y también las cascadas. Y a nadie le gustan las cascadas. Quiero decir, excepto las reales que están ahí.

Y por último, pero no menos importante, también tenemos paquetes más pequeños debido a la minificación. Así que, bien, ahora sabemos qué es un bundler, pero la pregunta podría ser por qué otro bundler aquí? Y para esto, pensemos en el escenario de VEED. Bueno, primero que nada, teníamos estas tres herramientas de construcción, ¿verdad? Y queríamos asegurarnos de que reducimos la complejidad porque, bueno, todas ellas bajo el capó, no es tan fácil. Y también hay inconsistencias entre el desarrollo y la producción, dado que el servidor de desarrollo de VEED no está empaquetado.

Así que comparado con Webpack, por ejemplo, siempre tenían este paso de empaquetado antes. Su desarrollo y puerto están mucho más alineados. Así que esto es también otra cosa que Rolldown puede resolver a largo plazo. Y un factor más grande allí es que en realidad hay limitaciones para todas estas herramientas donde, por ejemplo, ni Rollup ni SBuild ni SWC soportan o quieren soportar. Decimos como, oye, mira, está fuera de alcance. Está bien. Y por supuesto, por último, pero no menos importante, las construcciones de producción, espera, podrían ser mucho, mucho más rápidas. Y pronto veremos cómo. Así que ahora es el momento de conocer a Rolldown.

Sí, el logo simplemente rodó de arriba a abajo. Me atrapaste. Y aunque el nombre suena como, está bien, solo tomemos Rollup y portémoslo a Rust, en realidad es más que eso. Al principio, este era el pensamiento como, está bien, solo Rustifícalo. Pero muy rápidamente, llegó la realización de que eso no funciona completamente porque hay muchas herramientas ahí fuera. Y solo tomando el hecho de que VEED depende de ESBuild y de Rollup, tienes que combinar algunas cosas. Y hay más.

Entonces, ¿por qué no simplemente tomar lo mejor de todos los mundos, lo mejor del arte previo existente y combinar eso en algo completamente nuevo? Así que aquí tomamos la API de Rollup, el ecosistema de plugins de Rollup, porque mientras queremos mantenernos compatibles con todos ellos, y Rolldown lo es. Así que eso es genial. Queremos tomar la velocidad como entre comillas, porque mientras ESBuild está escrito en Go y Rolldown está escrito en Rust. Así que no es el mismo lenguaje, pero aún así nativo. Así que la velocidad de ESBuild, y también algunos comportamientos como define, inject. Había muchas buenas ideas allí.

E incluso de Webpack, se tomaron algunas inspiraciones debido a una cosa que Webpack puede hacer súper bien, que es el chunking, ¿verdad? Chunking avanzado para definir qué JavaScript debería agruparse, diferentes restricciones. Así que eso es extremadamente útil. Y Rolldown también hará un mejor chunking que, por ejemplo, Rollup o ESBuild. Y luego hay algunas características más experimentales como HMR incorporado, generación de mapas de importación, empaquetado de CSS, que también vendrá en el futuro, y también federación de módulos de primera clase que deberían ir directamente al bundler, lo cual es bastante importante.

Muchas de estas cosas como HMR son manejadas directamente por Veed, así que por la capa encima de él, pero en realidad quieres manejar todo esto a nivel del bundle, lo que hace las cosas aún más rápidas. Y luego la minificación también se maneja a través de OXC. Y ahora podrías preguntarte, bien, genial, Alex, ¿por qué hablar de este Rolldown y Rolldown Veed? ¿Por qué importa, verdad? Y quiero decirte por qué es importante para ti como desarrollador de React allá afuera.

En primer lugar, construcciones de producción más rápidas y construcciones más rápidas en general significan ciclos de retroalimentación más rápidos, ¿verdad? Así que no tienes que esperar para que un PR se ejecute para siempre. Si puedes reducir tu tiempo de construcción por magnitud, también significa, por ejemplo, retroalimentación 10 veces más rápida, lo cual siempre es genial. Hace que la vista previa de despliegue, el despliegue pre-producción, etc., etc., sean más rápidos. Así que también tienes más tiempo para construir características, menos cambio de contexto, y así sucesivamente. También significa menores costos de CI, lo cual es genial para una empresa, o si pagas tú mismo, no te arruinas tanto en esto. Y otra cosa, Rolldown incluso puede llevar a bundles más pequeños.

Depende, por supuesto, del proyecto, pero también hay algunas cosas que ganar allí. Por último, pero no menos importante, siempre puedes asegurarte con esta API de chunking avanzada que probablemente podría llenar toda una charla propia que puedes reducir el JavaScript inicial y asegurarte de que las cosas estén mejor fragmentadas. Y el impacto real es bastante interesante porque, por supuesto, Rolldown es un trabajo en progreso desde hace un tiempo. Está en beta ahora mismo. Y aquí tenemos una aplicación mínima de React router, y vemos que el tamaño del bundle, tuvo como dos grandes aumentos. Pero desde entonces, va continuamente hacia abajo, abajo, abajo a lo largo de las versiones de Rolldown en sí. Así que también vemos que los aumentos de rendimiento están llegando constantemente, y todo esto solo actualizando la versión, lo cual también es bastante asombroso.

Bien, pero esto aún no nos dice cómo se beneficia un proyecto del mundo real de eso, ¿verdad? Así que aquí vamos con Xcalibur. Uno de los grandes ejemplos, aplicación de React de código abierto, ya usa Vite. Así que echemos un vistazo. Y lo que acabo de hacer es, bien, lo tomé, y digo que lo construiré con Vite simple. El último, 7.2 punto algo. Y solo echaré un vistazo. Y se construyó en como 52.5 segundos. Bien, y vemos aproximadamente también algunos chunks aquí. Y luego pensé, bien, sabes, haré una cosa más. Solo quiero cambiar todo a Rolldownbeat. Así que lo actualicé, y aquí vamos. Y los tiempos de construcción, bueno, son 7.5 veces más rápidos. Y esto es sin ajustes finos. Esto es realmente como cambiar las dependencias. Tengo algunos pasos más para llegar a la última velocidad. Te lo diré en un segundo. Pero esta diferencia es realmente solo un alias diferente para la dependencia, y eso es todo. Te diré que hay más ajustes finos posibles porque Xcalibur ya vio un aumento de velocidad de construcción de 16x en el pasado a través de Rolldownbeat. Así que hay más posible. Es solo como la forma más fácil de probar cosas.

Luego también vemos que hay archivos parcialmente más pequeños. Algunos se hicieron un poco más grandes, algunos se hicieron un poco más pequeños. Pero al final, deberíamos salir de ahí con un tamaño GZIP y minificado más pequeño, lo cual también es increíble al simplemente, una vez más, cambiar la dependencia. Así que eso es bastante fuerte. Y todo eso mientras se mantiene la compatibilidad como antes, mientras se tiene la funcionalidad allí. Ahora, déjame decirte rápidamente cómo lo hice. Y como dije antes, solo actualicé todo a la última versión de VEED, así que la versión estable de VEED. Tuve que aumentar SAS debido a, bueno, algunas APIs obsoletas. Y luego simplemente cambié a Rolldownbeat. Así que eso es más o menos todo lo que hice, nada más.

Y eso ni siquiera tomó mucho tiempo. Así que esto fue como, no sé, menos de, creo, 15 minutos. Y la mayor parte de esto fue lidiar con SAS. Así que es genial. Y Xcalibur es solo uno de muchos ejemplos.

Tenemos la lista aquí. Es de un repositorio llamado Rolldownbeat PerfWins. Y aquí también vemos, bien, genial. Xcalibur está aquí listado de 22.9 segundos a 1.4 segundos. Definitivamente es una versión más antigua que fue probada. Así que antes era así de rápido. Además, por supuesto, tu experiencia puede variar dependiendo del dispositivo.

Pero aquí, SafiRad, uno de los miembros del equipo central de VEED, también parte de Void0, aprovechó la oportunidad para simplemente crear una construcción reducida, y obtenemos una mejora de tiempo de construcción de 16x. Más notablemente, Outline, otra gran aplicación de código abierto, también construida con React. Allí pasamos de 47.27 segundos con VEED simple hasta 2.12 segundos, lo cual es, sí, es una locura. Es un aumento de 22.3x. Y hay muchos, muchos más. Por supuesto, no todos tienen estos números enormes, enormes. Y eso también está más que bien.

Pero vamos en la dirección correcta allí. Y estos ya tienen magnitudes. Así que podría ser una gran oportunidad para probar cosas.

Ahora, por supuesto, no se detiene allí. Porque, OK, ahora tenemos un bundler. Pero para construir un bundler, necesitas muchas herramientas y algún tipo de base. Así que déjame hablar un poco sobre el subyacente de OXC, el compilador de oxidación de JavaScript, y un poco sobre algunos componentes aquí.

Porque, bueno, para construir un bundler, necesitas algunas cosas. Necesitas tener un parser. Así que necesitas tomar tus archivos JavaScript o TypeScript y transformarlos en una presentación técnica, ¿verdad?

, en un AST, un árbol de sintaxis abstracta. Y el parser de OXC es el parser más rápido aquí. Es conforme a las especificaciones. Así que analiza todos los conjuntos de pruebas de conformidad del TC49. Así que prueba 262 pruebas de ECMA Stage 4, lo cual es genial. Es tres veces más rápido que SWC y aproximadamente cinco veces más rápido que BIO.

Tienes un gráfico rápido que muestra eso exactamente. Pero todas las cosas también están vinculadas a los benchmarks que hacemos. Así que todo esto tiene una buena base, no solo como, oh, sí, es el más rápido. Hay números reales detrás de eso. Luego necesitamos resolver algunos módulos, tanto para, bueno, TypeScript, JavaScript, ¿verdad?

, y ESM, y CGS. Así que tenemos diferentes algoritmos de resolución de módulos que también están implementados. Y lo bueno es que el resolver también tiene soporte para tu tsconfig, ¿verdad? Así que eso será bastante bueno si tienes cosas como referencias de proyecto o IDS de ruta, que deberías usar según el equipo de TypeScript, pero la gente todavía lo hace. Así que tenemos que soportarlo.

También hay una resolución mejorada 28 veces más rápida. Es un resolver rápido por ahí, así que bastante decente.

También, una vez más, comparación rápida, por supuesto, más bajo es mejor. Y, bueno, luego queremos hablar sobre el transformador rápidamente, que es, por supuesto, lo grande que transforma nuestro TypeScript en AS Next o JavaScript en AS Next también, como lo baja o JSX en JavaScript. Tiene React refresh incorporado, por supuesto, y el descenso de sintaxis es posible, así que puedes decir, hey, tengo JavaScript, pero, por ejemplo, el operador de coalescencia de conocimiento debería simplemente convertirse en un polyfill porque los navegadores aún no lo soportan.

Así que eso también es por lo que es bastante rápido. Más rápido que TSC, pero necesita declaraciones aisladas. Eso también es bastante importante. De lo contrario, no funcionará.

Y luego también tenemos algo bastante especial para todos los fanáticos de Stack Component aquí, o personas que todavía están usando Stack Components. Tiene soporte incorporado para ello, no para todas las características, pero para un subconjunto que puedes usar. Esto es parte del transformador.

Así que antes, usualmente, Stack Components, bueno, están en cada componente si los usas, por lo que podrían ralentizar tu compilación. Y, bueno, con esto, ya no. Y en realidad también es el transformador más rápido que existe.

También hay comparaciones con gráficos, uno solo para emitir DTS aquí, y el otro es para transformar y reducir en comparación con SWC y Babel. Bien, hasta ahora, todo bien.

Hablemos del minificador rápidamente porque, bueno, el minificador en realidad no es el más rápido. No es el minificador con la mejor compresión. Así que, hasta ahora, era como el más rápido, o, bueno, con los minificadores, es un poco difícil porque los más rápidos, nunca producen los archivos más pequeños.

Y los que tienen los archivos más pequeños son realmente los más rápidos. Así que echemos un vistazo aquí. El benchmark que no hice yo mismo, tampoco es de nosotros. Es de private number. Hizo un gran trabajo comparando minificadores.

Y el minificador OXC, puedo adelantar eso ya, es el que tiene la mejor relación de velocidad de compresión, o al menos uno de los mejores. Bien, echemos un vistazo rápido. Dije uno de los mejores porque también depende de qué archivo benchmarks.

Con los minificadores, siempre depende de los archivos fuente reales que revisamos. Por ejemplo, para React en sí, para minificar eso directamente, tenemos SWC, déjame hacerlo un poco más grande, SWC ganando aquí bastante claramente con 8.19 kilobytes en 12 milisegundos.

Y luego rápidamente detrás de eso 8.4 kilobytes, así que solo 0.2 kilobytes más, OXC, minify. Y luego tenemos eso en aproximadamente 1/4 del tiempo, así que en tres milisegundos aquí. Mientras que si echamos un vistazo a, no sé, Moment.js, por ejemplo, también están los SWC al frente.

La diferencia es como, no sé, medio KB aproximadamente. Y siempre tenemos un cuarto del tiempo para OXC minify.

Si echamos un vistazo a TypeScript en sí aquí, por ejemplo, OXC minify toma la delantera frente al resto cuando se trata del tamaño minzip mientras sigue siendo más rápido que SWC, por ejemplo. Así que siempre vemos que, como dije, depende mucho de los archivos probados, pero definitivamente las cosas están en un rango similar.

Lo bueno es que, por supuesto, estamos trabajando en todo esto para asegurarnos de que también podamos escalar a la cima en los benchmarks, no por el bien del benchmark, sino para obtener archivos más pequeños para, bueno, aún un tiempo de construcción bastante rápido.

Pero ahora viniendo de cosas que suelen ser interesantes para personas que construyen, bueno, frameworks, bibliotecas, empaquetadores, etcétera, porque puedes usar todos estos componentes por separado.

Las cosas que son interesantes para ti, si no eres un autor de frameworks, lo cual probablemente la mayoría de ustedes no lo sean, eso también está más que bien porque todos construyen aplicaciones increíbles, supongo. Así que hablemos de linting.

Y quiero hablar un poco sobre Oxlin, que es la parte de linter de OXC. Es un linter para JavaScript y TypeScript. Así que sí, JSX, TSX, por supuesto, incluidos, y tiene soporte parcial para componentes personalizados. Por ahora, hay más en la hoja de ruta para más adelante.

Es aproximadamente de 50 a 100 veces más rápido que ESLint. Eso sin tipo de linting. Y hemos portado más de 600 reglas, así que más que eso, desde plugins populares de ESLint. Así que eso también significa que una gran parte de hooks específicos de React ya están integrados. Así que, por ejemplo, exhaustive deps, rule of hooks, etcétera, etcétera. Listo para usar.

Por cierto, todavía hay algunos que no están implementados aún. Así que si estás interesado en contribuciones, es una gran oportunidad para también explorar un poco más Rust. Sin embargo, se utiliza en proyectos bastante grandes como Preact, Bund, Vue, Linear, Shopify, Airbnb, y así sucesivamente. Así que vale bastante la pena. También ya es estable.

Tuvimos de 1 a 26 veces de lanzamiento. Y todavía hay algunas características en las que se está trabajando. Por ejemplo, tipo de linting, que ya funciona. Está allí en vista previa técnica, pero todavía hay algunas cosas más por hacer. Y es una de las cosas clave por las que tu linting suele ser lento.

Así que eso funciona junto con tsgo lint, y es bastante rápido. Y hay soporte para plugins de JS. Así que en realidad reglas de lint personalizadas que puedes haber escrito o alguien en tu equipo o empresa, o simplemente dices, hey, quiero usar algún plugin de ESLint porque la idea es que deberían ser de rendimiento, pero el rendimiento viene después, ¿verdad? Hazlo primero, y luego puedes hacerlo agradable y rápido.

Pero la idea es ser compatible con ESLint, y eso ya funciona bastante bien.

Así que si tienes algún tipo de plugin personalizado de ESLint que quieras ejecutar, deberías probarlo. La mayoría de ellos simplemente funcionarán. Y hay algunas cosas más de las que podemos hablar sobre en qué trabajar. Pero lo más importante, algunos números. Si piensas en unos 265,000 archivos, ¿cuánto tiempo tomaría hacer linting con tu herramienta de linting favorita? Bueno, con Auxlint, tomó 22.5 segundos con 10 hilos y 101 reglas, lo cual no debería incluir reglas de tipo, pero aún así es bastante sorprendente pasar por eso. Así que definitivamente deberías echarle un vistazo si piensas, oh sí, mi linting, eso podría ser un poco más lento de lo que debería ser.

Y antes de pasar a la siguiente parte, echemos un vistazo a los plugins personalizados de JS una vez más, porque esta es nuestra configuración para Auxlint. Ni siquiera necesitas una configuración. Esa es la mejor parte. Puedes simplemente ejecutarlo, y por defecto simplemente buscaremos la corrección, que es para lo que está el linting, ¿verdad? Algunos plugins están habilitados por defecto, pero también podemos definirlos por nuestra cuenta o decir que queremos eliminar algunos. Aquí, por ejemplo, tomamos TypeScript y React, y para ellos las reglas de corrección. Pero ahora con los plugins de JS, podemos simplemente decir, tomemos el plugin solid de ESLint, por ejemplo.

Nos aseguramos de que esté instalado para nuestro gestor de paquetes favorito, y luego este es un buen comienzo. Y en nuestro objeto de reglas, podemos simplemente decir, por ejemplo, solid prefer for, danos un error, por favor, cuando eso aplique. Y por supuesto, no tiene que ser un paquete de ESLint de npm. También puede ser tu propia regla a la que apuntes, tu propio plugin, incluyendo las reglas. Y luego puedes decir, hey, este es mi increíble plugin, nunca uses un hecho para hacer solo yo. Y por supuesto, lanza un error si eso sucediera. Habría ayudado a algunas personas aquí y allá, ¿verdad?

Porque aquí, Oxlint no hace ninguna regla estilística. No hay soporte para eso. Podríamos llegar al soporte de plugins JS para eso. Pero internamente no importamos nada que sea puramente estilístico. Eso es parte del formato.

Y Oxformat es, bueno, un trabajo en progreso y un momento de grabación. Y el lanzamiento alfa está bastante cerca. Así que eso podría estar ya disponible cuando veas esta charla. La idea es tener un formateador de rendimiento con valores predeterminados compatibles con Prettier. Y por supuesto, para asegurarse de que la migración sea fácil, pero también queremos abordar algunos problemas.

Tenemos algunos números de referencia preliminares, ¿verdad? Es el primero de todos. Esto es como dos a tres veces más rápido que Biome y aproximadamente 45 veces más rápido que Prettier. Si usas Prettier con el OXC pause ya, lo cual ya puedes hacer, entonces es como 32 veces más rápido. Así que todavía bastante, bastante decente. Y como mencioné, queremos abordar algunos problemas como el ajuste de líneas, imprimir algunos puntos problemáticos con el ecosistema actual de Prettier. Pero por otro lado, también queremos asegurarnos de que tengas la conformidad de Prettier por defecto.

Pero por otro lado, también queremos asegurarnos de que tengas la conformidad de Prettier por defecto. Así que cambiar será súper fácil porque idealmente nada debería cambiar. También hay un RFC, si estás interesado, donde discutimos por qué, por ejemplo, quieres agregar ordenación de importaciones incorporada, soporte de primera clase para Tailwind, y así sucesivamente. Así que por favor asegúrate de compartir tus pensamientos si tienes alguna opinión al respecto, siempre, siempre es apreciado. Y si quieres, entonces siéntete libre de probarlo. Pero llegaremos a eso en un segundo.

Ahora, una vez más, Excalidraw. Echemos un vistazo. ESLint para toda la base de código tomó como 26 segundos en total. Y para OXLint con un conjunto de reglas similar, estamos en cuatro. Así que eso es bastante decente. Sin reglas conscientes de tipos, en realidad estaríamos en 0.9 segundos, así que ni siquiera un segundo, lo cual también es realmente, realmente bueno. Y luego decimos, está bien, más aproximadamente 200 milisegundos para formatear. Eso es ahora solo JavaScript y TypeScript, pero creo que eso también sigue siendo bastante aceptable para toda la base de código. En este caso, solo los archivos JavaScript y TypeScript en JSX, TSX también.

Así que al final, es importante mencionar que el rendimiento siempre está mejorando, similar al gráfico para tamaños de paquete más pequeños. Para Rolldown, también veremos siempre mejoras para OXLint, Oxfam, y toda la suite OXC también. Está bien, así que echemos otro vistazo a nuestro proyecto Greenfield completo o tu proyecto Brownfield que obtendrá un poco más de vibraciones Greenfield-y. Y por supuesto, comenzamos con tu framework, tu código de aplicación, tu lógica, etc., etc., etc. Y debajo de eso, tienes Vite como la herramienta de construcción, el servidor de desarrollo, sistema de plugins, y mucho más en el futuro, por así decirlo, o tal vez algo más. Pero sin embargo, esto no te detendrá de usar Vitest del que ni siquiera hablamos porque, bueno, tiempo. Como un corredor de pruebas basado en Vite, también puedes usarlo de forma independiente. Esa es la biblioteca de referencia para ejecutar cualquier tipo de pruebas hoy en día, no importa lo que uses. Y sí, entonces puedes usar Rolldown ya sea por separado si quieres para algún tipo de bibliotecas a través de tsdown del que tampoco hablamos o como parte de Rolldown Vite para esa eliminación de código, tree-shaking, empaquetado, y división de código.

Y luego Rolldown en sí mismo utiliza OXC. Es como el analizador, el resolutor, el transformador y el unificador. Y también puedes usar partes de eso, especialmente el linter y el formateador. Y luego tenemos más o menos toda la cadena de herramientas juntas que puedes usar por separado pero también así.

Así que al final, solo quiero reiterar rápidamente sobre los planes futuros de Rolldown Vite, en realidad. Y la fase uno fue básicamente, está bien, tenemos este paquete separado para estabilizar y probar. Y luego en la fase dos, obtenemos como la beta de Vite 8 y ya no hay paquete separado. Luego tenemos una fase llamada 2.5 donde obtenemos un modo de paquete completo experimental. Así que empaquetamos en desarrollo nuevamente también. Esa es otra parte interesante.

Si tienes una pregunta, ejecútala, siéntete libre de enviarme un DM. Definitivamente llegaremos allí para asegurarnos de que nuestro, digamos, un inicio de servidor de desarrollo, el inicio del código, no la recarga dura para proyectos más grandes será mucho mejor porque esa es una de las deficiencias de no empaquetado. Y ahora con un empaquetador súper rápido basado en Rust, hay más posibilidades de mejorar eso. Así que eso es genial, especialmente para los grandes proyectos. Y luego en la fase tres, bueno, obtenemos todo en Vite y obtenemos que el empaquetador predeterminado para Vite sea entonces Rolldown, y eso sería Vite 8 entonces. Así que esa es la visión general y el plan aproximado.

Entonces la pregunta es, ¿estás listo para usar las herramientas? Para todo Vite es bastante fácil porque la mayoría de ustedes ya podrían estar en Vite y usemos Next.js en este caso. Sí, desafortunadamente, pero afortunadamente también hay otros meta marcos geniales y Vite en sí mismo también puede hacer SSR si no lo sabías. Así que si estás en Vite, cambiar es súper fácil. Es básicamente de aquí para allá, directo. O si la beta ya está disponible, entonces simplemente iremos por la 8.0.0 beta. Y eso está bien.

Para AuxLint, no importa lo que uses bajo el capó. No necesitas usar Vite ni nada. Es completamente independiente. Así que adelante, simplemente ejecuta npx-auxlint en tus proyectos para ver qué saldría de ahí y para ver qué tan rápido sería con el conjunto de reglas predeterminado general. Por supuesto, puedes configurar cosas y hacerlas conscientes del tipo. Ahí necesitas instalar el paquete auxlint-ts-golint solo porque todavía está en vista previa. Así que puedes ejecutarlo con npx-auxlint --"type-aware." Y también ver allí cómo irán las cosas. Y puedes agregar una configuración y hacer más cosas. Pero esa es la forma más fácil de empezar.

Y para aux-format, bueno, si realmente estás ansioso, entonces simplemente ejecuta npx-aux-format para formatear tus archivos. Y eso es todo. De hecho, hay una cosa más que quiero mencionar. Vite Plus escribe nuestro enfoque para la cadena de herramientas unificada para el WAP. Así que si estás interesado en todas estas herramientas, pero ejecutándolas juntas, entonces podría valer la pena echar un vistazo a viteplus.dev. Y eso es todo lo que tengo para ustedes hoy. Muchas gracias por su atención. Y si hay alguna pregunta, estoy curioso por ellas ahora en el Q&A. Gracias a todos.