Lanzamiento de Wasmer 5.0

Nuevo backend experimental

• Se agregan compatibilidad con V8, Wasmi y WAMR
• Ahora es posible integrar fácilmente en Wasmer cualquier intérprete o runtime que sea compatible con la especificación Wasm-C-API
• La integración con V8 ofrece una excelente experiencia de depuración mediante el depurador de V8 y Chrome Devtools
• Usar V8 como backend también significa compatibilidad nativa con excepciones de WebAssembly y recolección de basura

Soporte para iOS (disponible mediante bindings de WAMR, Wasmi y V8)

• Wasmer lleva WebAssembly a dispositivos iOS mediante un nuevo modo de intérprete
• Aprovechando las capacidades de V8, Wasmi y WebAssembly Micro Runtime (WAMR), los desarrolladores ahora pueden ejecutar módulos WebAssembly sin fricciones en iOS
• No se requieren cambios en la base de código, lo que permite crear aplicaciones de alto rendimiento en el ecosistema de Apple

Adelgazamiento de la base de código

• Para el lanzamiento de Wasmer 5.0, el enfoque estuvo en hacer la base de código de Wasmer lo más ligera posible
• Algunas dependencias usadas por Wasmer llevaban mucho tiempo sin mantenimiento o estaban duplicadas por crates más nuevos y seguros
• Como los bindings de Emscripten casi no se usaron durante los últimos 2 años, se dejó de darles soporte y, junto con la limpieza de dependencias, se eliminaron 20 mil líneas de código puras de la base de código de Wasmer

Mejora de rendimiento

• La deserialización de módulos ahora es hasta un 50% más rápida (es decir, al llamar a Module::deserialize o al ejecutar un módulo mediante wasmer run)
• Estas mejoras aprovechan una actualización importante de rkyv, la librería de deserialización de copia cero utilizada para deserializar módulos

Compiladores actualizados: Cranelift y LLVM 18

• Gracias a la integración más reciente de Cranelift, la velocidad de ejecución mejoró de forma significativa, haciendo que los módulos WebAssembly corran más rápido que nunca
• Wasmer 5.0 ahora incluye la versión más reciente de LLVM (18), lo que permite a los desarrolladores acceder a las optimizaciones más nuevas de la toolchain
• La actualización de LLVM mejora la compatibilidad y el rendimiento, proporcionando una base sólida para compilar y ejecutar módulos WebAssembly complejos
• Wasmer 5.0 también llega con soporte experimental para LoongAarch64
• Al hacer benchmark de coremark con las versiones más recientes de los compiladores, LLVM y Cranelift son alrededor de un 8% más rápidos en Wasmer v5.0 frente a v4.4.0

Opinión de GN⁺

• El lanzamiento de Wasmer 5.0 parece ser un gran hito para el ecosistema de WebAssembly. En particular, el soporte para iOS y la oferta de varias opciones de backend podrían ampliar de forma importante el alcance de WebAssembly hasta las aplicaciones móviles
• Al dar soporte como backend a distintos runtimes como V8, Wasmi y WAMR, los desarrolladores ahora pueden elegir el runtime que mejor se adapte a sus necesidades. Esto parece contribuir de forma significativa a aumentar la flexibilidad y compatibilidad de WebAssembly
• También vale la pena destacar el esfuerzo de optimización del rendimiento mediante el adelgazamiento de la base de código y la adopción de compiladores actualizados. Esto muestra que Wasmer no solo se limita a agregar funciones, sino que también trabaja en la mejora continua de la calidad
• Por otro lado, la descontinuación del soporte para bindings de Emscripten es una parte lamentable, pero parece una decisión razonable dado que su necesidad ha disminuido con la aparición de nuevos estándares como WASI y WASIX
• En conjunto, Wasmer 5.0 es una release que muestra claramente la evolución de WebAssembly, y se proyecta que Wasmer seguirá siendo uno de los principales proyectos que lideran el ecosistema de WebAssembly. Aun así, parece necesario un esfuerzo continuo para mejorar la estabilidad y madurez de las funciones que todavía están en etapa experimental

[GN⁺]

Opiniones de Hacker News

• Los gráficos de rendimiento se ven confusos y como si estuvieran malditos. En algunos casos están mostrados en escala logarítmica y, a veces, es difícil entender qué intentan decir. Por ejemplo, el gráfico de "Argon 2" muestra casi todas las barras con la misma longitud, pero cada barra individual tiene números distintos en milisegundos.
• Usar V8 como backend permite soporte para manejo de excepciones de WebAssembly y recolección de basura. Espero ver más noticias relacionadas con esto. Me pregunto si wasm-gc permite compartir datos/cadenas del host entre distintos módulos dentro del mismo runtime, o si está limitado a un solo módulo.
• En la landing page de Wasmer es difícil entender qué hace. Dice que ejecuta todo en todas partes, pero no queda claro qué hace realmente. Parece un producto orientado a desarrolladores, pero tiene más palabras de moda que explicaciones técnicas.
• Estoy satisfecho con Wasmtime y ando hackeando con el modelo de componentes de WASM y un sistema de plugins basado en WASI. Ha sido divertido trabajar en eso.
• Aún no he encontrado un buen caso para usar WASM en mis proyectos. Es una situación parecida a no saber cómo aprovechar una Raspberry Pi. No me queda claro por qué elegiría WASM para un proyecto asíncrono en Rust.
• Ojalá existiera una solución que no requiriera los encabezados Cross-Origin Isolated. Todavía sigo usando una versión anterior.
• Me pregunto si WASM podría funcionar como una alternativa que consuma menos recursos que una app de Electron. WASM no tiene acceso al DOM, pero me pregunto si eso podría añadirse mediante extensiones.
• No entiendo qué problema resuelve esta solución. ¿No tienen ya todos los runtimes de JavaScript un motor de WASM integrado?
• Me pregunto si esta solución permitiría evaluar código de Node.js de forma segura dentro de un sandbox.
• Los gráficos de rendimiento son difíciles de leer. Se usan tanto comas como puntos como separadores de miles, y la precisión se redondea de forma arbitraria a 1, 2 o 3 dígitos.