viteJs para frontend

ViteJs para frontend en entornos de desarrollo

 

Hace días me encontré que quería actualizarme con las nuevas tendencias de reactJs, que es una librería de javascript que me gusta pero no la he trabajado profesionalmente y en esto me compre con vitejS y que es vitsJs y de que va, antes de que los módulos ES estuvieran disponibles en los navegadores, los desarrolladores no tenían un mecanismo nativo para crear JavaScript de forma modular. Es por eso que todos estamos familiarizados con el concepto de «empaquetado»: usar herramientas que rastrean, procesan y concatenan nuestros módulos fuente en archivos que pueden ejecutarse en el navegador.

Con el tiempo, hemos visto herramientas como webpack , Rollup y Parcel , que mejoraron enormemente la experiencia de desarrollo para los desarrolladores frontend.

Sin embargo, a medida que creamos aplicaciones cada vez más ambiciosas, la cantidad de JavaScript con la que nos enfrentamos también aumenta drásticamente. No es raro que los proyectos a gran escala contengan miles de módulos. Estamos empezando a encontrarnos con un cuello de botella de rendimiento para las herramientas basadas en JavaScript: a menudo puede llevar una espera irracionalmente larga (¡a veces hasta minutos!) poner en marcha un servidor de desarrollo, e incluso con Hot Module Replacement (HMR), las ediciones de archivos pueden tomar un tiempo. un par de segundos para que se refleje en el navegador. El ciclo de retroalimentación lento puede afectar en gran medida la productividad y la felicidad de los desarrolladores.

Vite tiene como objetivo abordar estos problemas aprovechando los nuevos avances en el ecosistema: la disponibilidad de módulos ES nativos en el navegador y el surgimiento de herramientas JavaScript escritas en lenguajes nativos de compilación.

Inicio lento del servidor

Cuando se inicia un servidor de developer su setting de compilación en un paquete que tenia que seguir o rastrear y compilar primeramente antes de que pueda funcionar, por cual esta librería de viteJs mejora considerablemente  el inicio del servidor de Desarrollo dividiendo los módulos de las aplicaciones en dos categoria en dependencias y código fuentes

  • Las dependencias son en su mayoría JavaScript simple que no cambia con frecuencia durante el desarrollo. Algunas dependencias grandes (por ejemplo, bibliotecas de componentes con cientos de módulos) también son bastante caras de procesar. Las dependencias también se pueden enviar en varios formatos de módulos (por ejemplo, ESM o CommonJS).Vite preagrupa las dependencias mediante esbuild . esbuild está escrito en Go y preagrupa las dependencias entre 10 y 100 veces más rápido que los paquetes basados ​​en JavaScript.
  • El código fuente a menudo contiene JavaScript no simple que necesita transformación (por ejemplo, componentes JSX, CSS o Vue/Svelte), y se editará con mucha frecuencia. Además, no es necesario cargar todo el código fuente al mismo tiempo (por ejemplo, con división de código basada en rutas).

bundle bases dev server Lbernal - Luis Bernal

 

Native ESM Based dev server Lbernal - Luis Bernal

Actualizaciones lentas

Cuando se edita un archivo en una configuración de compilación basada en un paquete, es ineficiente reconstruir todo el paquete por razones obvias: la velocidad de actualización se degradará linealmente con el tamaño de la aplicación.

En algunos paquetes, el servidor de desarrollo ejecuta el paquete en la memoria, por lo que solo necesita invalidar parte de su gráfico de módulo cuando cambia un archivo, pero aún necesita reconstruir todo el paquete y recargar la página web. Reconstruir el paquete puede ser costoso y recargar la página arruina el estado actual de la aplicación. Esta es la razón por la que algunos paquetes admiten el reemplazo de módulo en caliente (HMR): lo que permite que un módulo se «reemplace en caliente» a sí mismo sin afectar el resto de la página. Esto mejora en gran medida DX; sin embargo, en la práctica hemos descubierto que incluso la velocidad de actualización de HMR se deteriora significativamente a medida que crece el tamaño de la aplicación.

En Vite, HMR se realiza sobre ESM nativo. Cuando se edita un archivo, Vite solo necesita invalidar con precisión la cadena entre el módulo editado y su límite HMR más cercano (la mayoría de las veces solo el módulo en sí), lo que hace que las actualizaciones de HMR sean consistentemente rápidas, independientemente del tamaño de su aplicación.

Vite también aprovecha los encabezados HTTP para acelerar las recargas de páginas completas (nuevamente, permita que el navegador haga más trabajo por nosotros): las solicitudes del módulo de código fuente se hacen condicionales a través 304 Not Modifiedde , y las solicitudes del módulo de dependencia se almacenan en caché Cache-Control: max-age=31536000,immutablepara que no lleguen al servidor nuevamente. una vez en caché.

Por qué agrupar para producción

Aunque el ESM nativo ahora es ampliamente compatible, el envío de ESM desagregado en producción sigue siendo ineficiente (incluso con HTTP/2) debido a los viajes de ida y vuelta de la red adicionales causados ​​por las importaciones anidadas. Para obtener el rendimiento de carga óptimo en producción, aún es mejor agrupar su código con agitación de árboles, carga diferida y división de fragmentos comunes (para un mejor almacenamiento en caché).

¿Por qué no agrupar con esbuild?

Si bien esbuildes extremadamente rápido y ya es un empaquetador muy capaz para bibliotecas, algunas de las características importantes necesarias para empaquetar aplicaciones todavía están en progreso, en particular, la división de código y el manejo de CSS. Por el momento, Rollup es más maduro y flexible en estos aspectos. Dicho esto, no descartaremos la posibilidad de usarlo esbuildpara compilaciones de producción cuando estabilice estas características en el futuro.

Visión general

Vite (palabra francesa para «rápido», pronunciado, como «veet») es una herramienta de compilación que tiene como objetivo proporcionar una experiencia de desarrollo más rápida y ágil para proyectos web modernos. Consta de dos partes principales:/vit/

Vite es obstinado y viene con valores predeterminados sensatos listos para usar, pero también es altamente extensible a través de su API de complemento y API de JavaScript con soporte completo de escritura.

Puede obtener más información sobre la lógica detrás del proyecto en la sección Por qué Vite.

Andamiaje de su primer proyecto Vite

Nota de compatibilidad

Vite requiere Node.js versión 14.18+, 16+. Sin embargo, algunas plantillas requieren una versión superior .js Node para funcionar, actualice si su administrador de paquetes advierte al respecto.

$ npm create vite@latest

$ yarn create vite

$ pnpm create vitE

lbernal.es

viteJs para frontend