¿El Fin de la Fragmentación del Frontend? Cómo Rust está Unificando Frameworks y Herramientas

Imagina que tienes la gran oportunidad de comenzar este proyecto Greenfield, y no Microsoft Windows XP, por supuesto. Así que lo primero que podría venir a la mente es qué elegir. ¿Qué stack, qué framework, tal vez, verdad? Y con suerte uno de estos frameworks aquí. Y ahora podrías preguntarte, está bien, ¿por qué estos frameworks específicos? Podría haber incluso más, por supuesto, pero ¿qué tienen todos en común? Y la respuesta aquí es Vite como la infraestructura compartida de la web, por así decirlo.

Pero, por supuesto, eso no nos detiene aquí. Decimos, está bien, volvamos por un segundo y digamos, bien, elegimos Vue o Svelte o React o Remix 3 o lo que sea. Continuamos aquí más o menos con elecciones. Eso significa que ahora tenemos que elegir un framework de pruebas. Así que tenemos que pensar, está bien, qué usar para la prueba de extremo a extremo, cómo hago mis pruebas de componentes, mis pruebas unitarias, etc. Y luego, bueno, si pensamos, está bien, tenemos un framework y una herramienta de pruebas, hemos terminado.

Sorpresa, no lo estamos. También tenemos que pensar en esto, linting y formateo, y, bueno, un runtime también, porque ese es el JavaScript en el que vivimos. Así que en lugar de hacer una elección difícil, hacemos unas pocas. Bueno, bastantes, demasiadas, si me preguntas a mí y a muchas otras personas por ahí, porque todos estamos de alguna manera hartos de todas estas elecciones que tenemos que hacer. Y si ahora te digo que todas las herramientas y el framework que podrías elegir, también podrían ejecutarse en diferentes cosas bajo el capó, como una de estas cosas y una combinación de estas cosas. Sí, eso no hace las cosas más rápidas o mejores.

Así que, bienvenidos a mi charla, The End of Framework Fragmentation? Signo de interrogación, muy importante. Cómo Rust está unificando frameworks y herramientas. Un poco sobre mí, soy Alex. Soy desarrollador web y dev rel en Void Zero. También soy consultor de ingeniería web, y doy charlas, masterclasses, etc. También estoy en el equipo de NUX, pero ese no es un tema para la charla de hoy. Y, bueno, estoy activo en las redes sociales. Hago un video en YouTube una vez a la semana y transmito si tengo tiempo, así que casi nunca, pero bueno. Y, por supuesto, tengo un sitio web de portafolio, y siempre digo que tengo que actualizarlo. Nunca sucede debido a, bueno, razones de tiempo. Conoces el problema también. Pero hablemos de nuestro proyecto Greenfield. Eso es mucho más interesante, o tal vez un proyecto legado también. Pero en todos los casos, queremos los mejores frameworks, las mejores herramientas, lo mejor de todo. Pero, ¿qué significa realmente? Bueno, en primer lugar, deberían ser fáciles de usar y también fáciles de configurar, ¿verdad? No queremos, como, aprender un idioma completamente nuevo solo para usar un nuevo framework, necesariamente. Y también deberían trabajar juntos y sin problemas con nuestras necesidades. Así que eso debería ajustarse a lo que nuestra aplicación requiere, lo que el negocio requiere. Y como queremos tal vez aprender uno nuevo o usar algo existente, también necesitamos algún tipo de documentación. Debería ser bastante buena. No importa si, como, con vibras de la vieja escuela pasamos por los archivos MD o a través del sitio web, o simplemente preguntamos a nuestro modelo de IA favorito, también necesitan algunos datos para entender el framework, y el código a menudo no es suficiente. Y para no reinventar la rueda, también queremos tener un ecosistema rico, ¿verdad? Así que plugins, extensiones, integraciones, etc. Y luego, en todo, también deberían ser increíblemente rápidos, pero también fiables. Así que deberían funcionar idealmente. Y, bueno, no podemos dejar de hablar sobre estar preparados para el futuro porque no queremos reescribir nuestra aplicación en medio año cuando el proyecto no se mantenga. Ya hablamos sobre el ecosistema rico en términos de bibliotecas para tus frameworks favoritos, bibliotecas de componentes, integraciones, etc. Pero también debería ser fácil de extender y fácil de adaptar. Así que idealmente se ajusta, una vez más, a tus necesidades. Y por supuesto, el mantenimiento debería estar ahí, debería estar bien mantenido, las correcciones de errores deberían llegar regularmente, y así, así, así. Esta no es una lista exhaustiva, pero al final, todo lo que queremos es una gran DX. Así que, afortunadamente, esto aquí, la infraestructura compartida de la web moderna, nos lo da.

Porque, bueno, obtienes una experiencia de desarrollador con un increíble servidor de desarrollo con HMR directamente. No tenemos que, como, refrescar nuestra página. E incluso funciona con proyectos HTML simples. Ni siquiera necesitas un framework para eso, lo cual es increíble. Obtenemos ESM nativo directamente. Obtenemos configuraciones predeterminadas realmente sensatas que podemos cambiar si lo necesitamos. Obtenemos ese rico ecosistema de plugins basado en plugins de Rollup, que sigue siendo una gran API para usar. Obtenemos builds de producción optimizadas y más.

Pero, para ser justos, algunos de ustedes podrían no usar Vite, ¿verdad? Todos los usuarios de Next.js por ahí, por ejemplo, porque no pueden. No está basado en Vite, sino en Fabpack y hoy en día TurboPack. Aún así, echemos un vistazo rápido a la pila actual de Vite. Porque, bueno, bajo el capó, se están utilizando muchas herramientas de construcción. Tenemos ESBuild que está ahí para el pre-empaquetado para un servidor de desarrollo para, como, al menos concatenar algunas cosas para transformaciones y también para la modificación de producción. Luego tenemos Rollup, ya mencionado, un buen empaquetador basado en JavaScript. Mientras que ESBuild está escrito en lenguaje nativo en Go, lo que lo hace bastante rápido. Así que Rollup está, por supuesto, ahí para hacer un chunk al final, las optimizaciones de build de producción.

Sí, lo está haciendo bastante bien. El control de chunks es, bueno, podría ser un poco mejor. Y estos son dos empaquetadores, por así decirlo. Pero hay un tercero bajo el capó. Si estás usando React, entonces podrías querer usar SWC, que está escrito en Rust, y es una alternativa para transformaciones y también soporta React refresh. Así que, aunque esto es algo genial, también no lo es, porque ahora tenemos tres empaquetadores dividiendo las tareas. Y en algún momento, el punto era pensar, como, oye, ¿no podemos simplemente deshacernos de ellos? ¿Podemos simplemente unificarlos en una sola cosa? Y bueno, eso es lo que pasó. Así que ahora mismo, si estás usando Vite, reutilizas estas tres herramientas diferentes o tal vez dos herramientas diferentes si no usas React o no optas por eso. Bueno, en su lugar, simplemente nos deshacemos de ellos y añadimos este aquí, Rolldown. Ese es un nuevo empaquetador basado en Rust. Y ahora pienso, Dios, ¿por qué otro empaquetador, verdad? Como, inserta XKCD con estándares aquí. O tal vez también te preguntas, espera, pero ¿qué es realmente un empaquetador y por qué necesito uno? Vamos a por ello rápidamente, porque se vuelve obvio después de un tiempo. Este es un gran comienzo. Esto es tal vez cómo podría verse tu aplicación.

Y los detalles no son tan importantes. Esto es básicamente un gráfico de dependencias, pero no de tus node modules, sino de tus propios archivos. Así que podrías decir, está bien, genial. Hay un cierto archivo que depende de otros. Los verdes son dependencias. Luego tenemos, como, archivos TS y lo que sea. Y así es básicamente como escribimos código, ¿verdad? Importamos diferentes módulos. Podríamos querer usar dependencias, etcétera. Y un empaquetador eventualmente escupirá esto aquí.

Eso es un gráfico Dreamweb. Podrías haberlo visto si analizaste tu bundle. Si nunca has visto eso, definitivamente deberías echar un vistazo. Y aquí vemos los diferentes chunks. Así que cada color es un chunk diferente. Y luego ves cajas dentro de cajas. Así que, por ejemplo, a la derecha, tenemos esta gran caja. Dice Sheeky en la parte superior. Y luego tenemos diferentes cajas más pequeñas dentro, que son los archivos que realmente se juntan en este único chunk. De lo contrario, cada archivo estaría solo. Descargaríamos miles de archivos. Así que eso no es necesariamente ideal. Y lo mismo para el resto.

Pero ahora te preguntarías, está bien, ¿por qué sucede? Acabo de mencionar todo el asunto de la descarga, claro, pero ¿hay alguna otra razón? Y bueno, hace un par de años, podríamos haber visto esta parte aquí. DHH en el escenario diciendo, no, build. No necesitamos un paso de construcción. Bueno, en fuerte desacuerdo aquí. Definitivamente necesitamos un paso de construcción. Así que vamos a ver por qué exactamente. Está bien. Un caso muy simple es este, ¿verdad? Si echamos un vistazo, eso es JSX.

Eso es genial. ¿Alguna vez has intentado escribir JSX en un navegador? Bueno, no puedes. No es JavaScript. Así que no funcionará. Entonces necesitamos algo que convierta el JSX en JavaScript. Lo mismo ocurre con otros formatos como los componentes de archivo único de Vue, como quieras llamarlo, etc. Así que esto es algo que necesitas a menos que quieras escribir funciones de renderizado o similar a React, lo cual es posible pero doloroso. O si dices, está bien, por ejemplo, uso Vue y solo uso un CDN, pero entonces no los tienes archivo por archivo de todos modos. Tenemos algunas desventajas, no importa lo que elijamos.

Y lo siguiente es esta constante a: número igual a uno. Y eso es TypeScript. Eso en realidad también es TypeScript incorrecto porque los números están en cadena, pero es TypeScript y eso tampoco se ejecuta en el navegador. Así que necesitamos eliminar los tipos aquí al menos. Así que tenemos que quitar el dos puntos número. De lo contrario, las cosas no funcionarán. Y si dices, está bien, ¿sabes qué?

Solo uso componentes web y uso JavaScript puro, está bien. Veamos qué más hay. Tomemos este código, por ejemplo. Aquí decimos que tomamos una función de date functions, gran biblioteca hasta que obtengamos temporals y esperemos no tener que preocuparnos más por las fechas en JavaScript donde los meses comienzan en cero. Pero digamos que queremos formatear la fecha. Entonces solo queremos usar el código que es relevante para la función de formato y no todas las otras cien más funciones de date functions, que son todas geniales, pero no para este caso de uso. Así que si no tuviéramos un bundle, no podríamos hacer esto.

Pero con un bundle, podemos hacer tree shaking de todo el conjunto y eliminar el código muerto. La eliminación de código muerto no es una palabra para eso. Y eso también significa un bundle más pequeño, lo cual siempre es genial porque entonces, bueno, los usuarios, tienen una mejor experiencia. Lo cargan más rápido, menos solicitudes, etc.

Y luego también tenemos esto. No te preocupes, no espero que leas todo el código. Este es en realidad el código de justo ahora, pero minificado, así que con tree shaking y minificado. Aquí vemos que, por supuesto, la máquina no tiene que leer el código como nosotros. Así que podemos hacer algunas optimizaciones y mejoras para incluso exprimir y hacer el bundle un poco más pequeño.

Así que al final, obtenemos un mejor rendimiento también aquí, menos cosas transferidas. Así que eso es útil, especialmente también en dispositivos de gama baja o con, bueno, una conexión que no funciona bien. Así que TLDR, ¿por qué necesitamos un bundler? Bueno, un bundler transforma tu código no-JS en JavaScript. Elimina el código no utilizado. También combinará o también distribuirá tu código para que no cargues todo de una vez.

Solo cargas las cosas que necesitas. Por ejemplo, si dices, oye, tengo diferentes páginas, no necesitas cargar el JavaScript para todas las páginas a la vez. Así que podemos cargar cosas bajo demanda. Tenemos menos solicitudes de red y cascadas, lo cual siempre es agradable. Así que eso responde qué es un bundler y por qué, pero ¿por qué otro más? Bueno, en primer lugar, si echamos un vistazo al panorama general de un Vite de antes, múltiples bundlers llevan a más complejidad. Así que entendemos eso. Y también hay inconsistencias entre dev y prod si usas diferentes herramientas.

Otra parte importante es que hay limitaciones por bundler o características que ni rollup ni ES built soportan. Así que están un poco fuera de alcance. También las construcciones de producción podrían ser mucho más rápidas, por lo que finalmente elegimos tener una herramienta de construcción nativa aquí. Así que hablemos de rolldown. Y sí, el logo simplemente rodó hacia abajo. Eso es correcto. Y rolldown es más que solo un rollup Rustificado. Es muy importante, aunque el nombre sugiera eso.

E inicialmente la idea era, oye, ¿por qué no intentar portar rollup a Rust? Esto no funcionó finalmente, principalmente porque había tantas otras cosas geniales que son tan importantes para el ecosistema. Así que en lugar de simplemente decir, oye, tomemos rollup, ¿por qué no tomar todas las cosas buenas que existen, que existen de arte previo, de bundlers previos, y combinarlas? Así que tenemos la API de Rollup porque aún queremos ser compatibles con eso, con el sistema de plugins y hacer que los plugins funcionen. También queremos tener la velocidad de ES built, por así decirlo, ¿verdad? Herramientas nativas, pero también algún comportamiento como define, inject, etc.

Y aquí hay un nombre que quizás no hayas escuchado por tanto tiempo, Vappack. Sí, eso también fue inspiración de Vappack porque Vappack tiene características de optimización realmente, realmente buenas en términos de chunking, controlando para decir qué archivos JavaScript deberían ir en un solo chunk. ¿Cómo debería verse eso? ¿Qué criterios deberíamos crear un nuevo grupo, etc., etc. Y por supuesto, más allá de eso, también hay características experimentales, ¿verdad? HMR incorporado, generación inbound, empaquetado de CSS, federación de módulos de primera clase, y así sucesivamente. Y para un bundle de grado de producción, también necesitamos magnificación, así que también está ahí. Y genial. Bien, estamos en racha, por así decirlo. Tenemos el bundler, y en realidad, no se detiene ahí porque, bueno, si construyes un bundler, necesitas muchas herramientas subyacentes. Necesitas algún tipo de base, y ahí elegimos OXE. También antes de que el creador del proyecto se uniera a la empresa.

Y si miras el logo, ¿verdad?, este es un ancla. Es un ancla marrón, así que se podría decir que está rustificado. Y, bueno, como ves el agua en el fondo, y cómo es, como, el óxido realmente se crea? Con como, sí, necesitas agua seguro, y aire, oxidación. Así que vamos a repasar lo que realmente hay ahí, en el compilador OXE, y repasar los componentes, y lo que realmente haces. Así que, algunas cosas podrían ser interesantes, especialmente para personas interesadas en, como, todas estas cosas de bajo nivel, pero también hay cosas que tú, como desarrollador de aplicaciones, necesitas. Vamos a por ello. Primero que nada, el parser. Así que si dices que tienes tu código JavaScript o TypeScript escrito, entonces quieres crear una representación técnica de eso, ¿verdad?

Es algo llamado un AST, un árbol de sintaxis abstracta, y eso es necesario para hacer más cosas, para hacer operaciones sobre eso. Y en realidad, para eso, tienes el parser. Así que tenemos el parser OXE, que es el parser de JavaScript más rápido que existe. También es importante, hay enlaces en las diapositivas para todos los benchmarks, así que cuando digo más rápido, esto es realmente un benchmark, no solo como una estimación aproximada diciendo, oh, sí, tal vez. También es conforme a las especificaciones, así que pasa todas las pruebas para el test de estado 4. Es un conjunto de pruebas de conformidad. Muy importante porque no quieres que tu aplicación falle al construir o que dé un código de tiempo de ejecución incorrecto. Así que, esto es clave. También es tres veces más rápido que SWC, y cinco veces más rápido que BIO. Solo como comparación con otras herramientas basadas en Rust, no necesariamente tenemos que comparar con otros parsers porque, bueno, eran mucho más lentos que eso. Echemos un vistazo al gráfico. Aquí, también vemos lo que acabamos de discutir, que el parser es bastante rápido aquí.

También vemos, por supuesto, que más corto es mejor aquí. Eso es analizar el archivo TypeScript.js. Ahora al resolver, porque ahora hemos analizado nuestro archivo, pero solo usamos un archivo. Ahora, por supuesto que no, usamos muchos archivos. Así que echemos un vistazo a la resolución de estos módulos y señalando a diferentes archivos y dependencias y cómo funciona. Ahora, también tenemos ESM y CGS en JavaScript, por lo que diferentes formatos de módulos. Y bueno, tienen diferentes algoritmos de resolución. Así que esto también necesita ser soportado. Y una cosa más que hicimos es decir, oye, ¿por qué no soportar tsconfig directamente porque TypeScript es casi un hecho hoy en día, ¿verdad? Así que eso también soporta referencias de proyectos, extiende, rutas, alias, y así sucesivamente. Y probablemente es 28 veces más rápido que enhanced resolve, lo que lo convierte en un resolvedor rápido aquí. Y también tenemos un gráfico aquí. Claro, no es un gran problema. Enhanced resolve está tardando mucho más.

Así que estamos aquí en bastante tiempo. Y luego el transformador. Así que ahora analizamos el archivo. Podemos encontrar los otros archivos y también analizarlos. Pero especialmente si quieres apuntar a todos los navegadores o usar características más modernas, entonces necesitas transformar el código. Pero también necesitas transformar TypeScript a JavaScript o cualquier otra cosa. Así que hay un par de opciones. Aquí es donde entra en juego el transformador. Y también tiene React Refresh incorporado. Así que para todos los de React, eso es increíble. Y la reducción de sintaxis que acabo de mencionar, como convertir el operador de coalescencia de conocimiento, como el doble signo de interrogación al equivalente como polyfill, por así decirlo, o como el encadenamiento opcional es necesario si quieres soportar todos los navegadores. Incluso si dices que solo soportamos la línea base, eso todavía significa que aquí y allá necesitas reducir la sintaxis de bastantes cosas. Otra cosa que el transformador OXC puede hacer es que puede emitir los archivos de declaración de tipo. Y por supuesto, mucho más rápido que TSC con declaraciones aisladas habilitadas. La razón también es, bueno, porque no hace verificación de tipos. Aquí hay algo interesante una vez más para los de React. Style components es en realidad una característica incorporada.

Aunque se podría decir que es legado, ralentizaría mucho tu construcción. Entonces, ¿por qué no tener eso incorporado para asegurarte de que puedas construir bastante rápido como una transformación? Así que si usas style components y te molesta el tiempo de construcción, entonces usar OXC transformer o roll down, que utiliza OXC transformer, he oído que es un buen cambio allí. Y este es también el transformador más rápido que existe. Comparación, comparación de velocidad solo para emitir archivos DTS. Más bajo es mejor aquí, por supuesto, también.

Y comparado con Babel o Babel y SWC, también allí más bajo es mejor. Y ahora podemos hablar un poco sobre un minificador. Y la cosa es que ahora dijimos mucho como, está bien, el minificador es importante para tener una aplicación de grado de producción. Eso es cierto. Y tengo que decepcionarte aquí porque no es el minificador más rápido que existe. Ahora estoy pensando, está bien, definitivamente producirá los archivos más pequeños, ¿verdad? Debe ser si eso es parte de la presentación. En realidad, no, no es el caso. Lo siento si pensaste eso.

Entonces, bueno, ¿por qué es eso? La razón es bastante simple. Porque el minificador más rápido nunca produce los archivos más pequeños. Y uno de los archivos más pequeños nunca es el más rápido.

Así que básicamente por eso dijimos, oye, tengamos un buen equilibrio allí, para ser súper rápidos y aún así tener archivos pequeños de buena manera. Así que este es uno de los mejores equilibrios entre velocidad y compresión.

Y para echar un vistazo a la prueba comparativa, bueno, no traje ningún gráfico. En su lugar, echamos un vistazo a la prueba comparativa de Private Number porque él hizo una prueba de minificación muy extensa aquí comparando diferentes archivos y usando diferentes herramientas. Y allí, también está automatizado. Así que eso es genial.

Echemos un vistazo. Por ejemplo, React, donde SWC está liderando aquí con un tamaño minzip de 8.19 kilobytes. Y luego OXC Minify con 8.4 kilobytes. Así que solo tenemos una diferencia de 0.2 kilobytes. No es tan grande. Es interesante porque dependiendo de la aplicación, podrías ver a SWC al frente, OXC, y a veces también otra herramienta.

Entonces, si vamos, por ejemplo, directamente a TypeScript, entonces vemos que OXC Minify aquí gana claramente el tamaño minzip por bastante y, de hecho, el minificador basado en C gana en velocidad aquí, mientras que OXC es aproximadamente cinco veces más lento, por así decirlo. Pero también, bueno, el minificador basado en C produce un minzip de 1.13 megabytes. Así que esa es también una parte complicada. Al final, es importante que el objetivo sea, por supuesto, ser el número uno en la mayoría de estas partes. Este es también un puntaje ponderado, por lo que tomará en cuenta tanto el tiempo como el tamaño. Así que, por supuesto, estamos trabajando arduamente en eso para asegurarnos de que saldremos en la cima en todos los benchmarks en algún momento.

Lo más importante es que es un escenario complejo de probar y estamos en ello, pero también necesita algunas mejoras más y tiempo también. Bien, ahora hablamos de todas las cosas que son necesarias para el bundler, y las dos siguientes cosas serán súper interesantes para todos ustedes porque sé que estos son temas que molestan a mucha gente. Así que hablemos de linting. Sí, de hecho tenemos un linter en este conjunto, e importante, mencioné componentes antes. Puedes usar todas estas cosas por separado. Así que si quieres probar el POS o el Transformer para tu herramienta interna, adelante. No necesitas tener todo el conjunto. Lo mismo con el linter aquí, por ejemplo. Se llama OxLint. Es un linter para JavaScript y TypeScript, ¿verdad? Así que TSX y JSX también son compatibles. Tiene soporte para componentes personalizados, parcialmente, y es de 50 a 100 veces más rápido que ESLint. Bastante decente, diría yo. Transferimos más de 570 reglas a Rust desde plugins populares, ESLint Core, etc. Se utiliza en muchos proyectos grandes y es estable, pero por supuesto todavía trabajamos en muchas características como hyperlinting, que existe y está en vista previa, y que también funciona más rápido en TypeScript ESLint gracias a TS Go Lint. También soportamos plugins de ESLint, de hecho, desde hace como un buen mes, lo que significa que queremos ser más eficientes, pero eso es algo que podemos ajustar más adelante.

Lo más importante es que queremos ser compatibles con ESLint, y cubrimos una gran parte de la API de ESLint, más por venir, para que puedas usar tu plugin favorito de ESLint, ya sea a través de las reglas nativas o si no hay equivalente, simplemente a través de un plugin JS. Solo para dar una idea de los números, uno de los más grandes fue como, oh sí, más de 265,000 archivos con el conjunto de reglas estándar en 22.5 segundos. Así que eso es bastante rápido, diría yo. En términos de plugins personalizados, es realmente fácil. Incluso puedes escribir tus propias reglas o tener las reglas de tu empresa o equipo para ser soportadas, lo cual es una gran ventaja para migrar. Todo se basa en, bueno, puedes configurar plugins JS, ponerlos allí, y luego estás listo para usar las reglas como las usarías. Y desde el Linter, también cubrimos un formateador porque esta es la segunda parte que todos ustedes podrían estar interesados. Todavía está en progreso, en el momento de la grabación, pero técnicamente ya puedes probarlo. Llegaremos a eso al final.

La idea es ser muy eficiente con valores predeterminados bastante compatibles, para que puedas migrar fácilmente, ¿verdad? En términos de rendimiento, ¿qué significa? Bueno, tengo algunos primeros números para ti, que es de 2 a 3 veces más rápido que biome y también 45 veces más rápido que Prettier. Si usas Prettier con el OXC Pulsar como Pulsar, lo cual puedes hacer, de hecho, es como 32 veces más rápido. Así que sigue siendo magnitudes más rápido. Ahora te preguntarás, ¿por qué simplemente rustificar Prettier? No exactamente. También queremos asegurarnos de que podemos abordar algunos problemas típicos como el ajuste de línea, el ancho de impresión, etc. Y también estamos apuntando a la mejor herramienta compatible con Prettier, así que la mejor conformidad con Prettier. Así que cuando cambies, simplemente funcionará. No te dará grandes diferencias. La ranura debería estar incorporada, el soporte para tailwind también. Y hay un RFC. Así que si estás interesado, por favor comparte tus pensamientos como de costumbre.

Y luego las pruebas. Bueno, vinimos de OXC un poco más allá hacia las pruebas en sí. Mencionamos las pruebas al principio. Y por supuesto, ahora todos los grandes entornos de ejecución tienen pruebas, ¿verdad? Son ejecutores de pruebas, con suerte también pruebas, pero ejecutores de pruebas como Node, Deno, Bun. Y por supuesto, con Jest está alrededor y VTest también está ahí. Así que, bueno, con VTest, tienes el buen beneficio de que si usas VT, entonces simplemente funcionará sin problemas, pero ni siquiera necesitas VT para eso necesariamente. Es simplemente compatible a nivel de API. Obtienes soporte listo para usar para todas las cosas modernas, lo cual es increíble. Tiene un modo SmartWatch, y también tiene un modo llamado Browser Mode. Y con el Browser Mode, que, por cierto, se basa en PlayWrite o WebDriver.io, puedes elegir eso. No necesitas ninguna biblioteca DOM falsa. No necesitas jsDOM. No necesitas happy DOM. Puedes ejecutar tus pruebas de UI en el navegador con un mínimo de sobrecarga. Eso no significa pruebas de extremo a extremo porque ya puedes hacerlas con PlayWrite o con WebDriver.io o lo que quieras usar. Selenium, si eres de la vieja escuela. No, en cambio, realmente ejecutas tus pruebas de componentes en el navegador real, aún rápido y, lo más importante, confiable. Así que eso es increíble. Y si eso no te convence, bueno, deberías probarlo seguro, también tiene la mayor satisfacción entre las herramientas de prueba según el estado de JS 2024.

Y también ahora se usa como el predeterminado, no solo si usas V en algún lugar, sino que también Angular está comenzando a usar pruebas V como predeterminado para V 21, etcétera, etcétera. Así que estamos yendo en una dirección recta allí.

Y ahora echemos un vistazo desde arriba nuevamente. Elegiste tu framework, donde el código de la aplicación y tu UI y lógica viven en algún lugar, como si tuvieras código encima de eso. Luego vas a Vite como tu herramienta de construcción, tu sistema de plugins del servidor de desarrollo, pruebas V, un empaquetador roll down usado en Vite en algún momento, ¿verdad? Para esa eliminación de código, división, tree shaking, el proceso de empaquetado, y luego allí abajo, OXC se usa como, bueno, parser resolve para Transformer, Minifier, y también para ti mismo, con aux y aux format, como Linter o Formatter.

Y una vez más, puedes usar estas partes todas por separado o todas juntas en algún momento. Pero volvamos a Vite aquí y hablemos sobre los planes futuros para roll on Vite. Porque ahora mismo estamos en una fase, bien, tenemos un paquete separado para estabilizar y probar roll on Vite. La fase dos será la beta de Vite 8. Podría estar ya disponible si estás viendo esto, dependiendo de cuándo lo hagas, ¿verdad? Así que ya no hay un paquete separado. En su lugar, solo usaremos la beta allí. Y luego, en algún momento, esto se volverá completamente estable, y roll down será entonces el empaquetador predeterminado para Vite, lo que hace que todo sea más fluido y rápido.