¿Cuáles son las diferencias entre WebAssembly y la JVM?

En esencia, tanto la JVM como WebAssembly fueron diseñados para ejecutar código compilado prácticamente en cualquier lugar: para la JVM, esto significaba máquinas con diferentes sistemas operativos o arquitecturas de CPU, algo sin precedentes para su época, y para WebAssembly, esto significaba cualquier navegador web en cualquier computadora en cualquier lugar, por el resto del tiempo.

La JVM, introducida a mediados de los años 1990 junto con Java, evolucionó hasta convertirse en una plataforma completa que ofrece un amplio soporte en tiempo de ejecución: recolección de basura, amplias bibliotecas estándar y herramientas para ejecución administrada. Sin embargo, algunos podrían decir que esto genera una cantidad considerable de hinchazón en la JVM: grandes consumos de memoria y tiempos de inicio más lentos. Si bien es extremadamente potente, esto hace que la JVM sea menos adecuada para aplicações livianas.

Por el contrario, WebAssembly fue diseñado con la web en mente, específicamente para ejecutar código dentro de navegadores. Como resultado, fue diseñado para priorizar un tiempo de ejecución liviano y tiempos de inicio ultrarrápidos, pero sin el rico soporte de tiempo de ejecución. Si solo se orientara a los navegadores, Wasm sería menos portable que el bytecode de Java, pero hoy en día, los entornos de ejecución independientes de Wasm pueden ejecutarse fuera de la web, lo que abre nuevas puertas para aplicações del lado del servidor, sistemas integrados y edge computing. Además, llegará a WebAssembly algún soporte de tiempo de ejecución adicional limitado, concretamente, recolección de elementos no utilizados, pero es poco probable que veamos toda la amplitud del soporte de tiempo de ejecución en WebAssembly que ofrece la JVM.

La JVM solo funciona con su familia de lenguajes (Java, Kotlin, Scala y algunos más), todos ellos diseñados intencionalmente para ejecutarse sobre la JVM. Si bien el ecosistema Java cuenta con amplias bibliotecas y marcos, la interoperabilidad solo ocurre entre estos lenguajes JVM. Las aplicações basadas en JVM pueden recurrir al código nativo, pero no sin gran esfuerzo y cuidado.

WebAssembly no fue diseñado para soportar solo un lenguaje de programación o para favorecer un cierto estilo de lenguaje, ya sea funcional, de recolección de basura o interpretado. Cualquier lenguaje (Rust, JavaScript, Python, C++) podría compilarse para ejecutarse en un entorno de ejecución Wasm. Si bien eso no significa que el código de cada uno de estos lenguajes pueda comunicarse entre sí en este momento, a través del estándar emergente de Modelo de componentes , los desarrolladores pueden tomar múltiples módulos Wasm escritos en diferentes lenguajes y conectarlos sin problemas. Pronto, para WebAssembly, la vinculación y la interoperabilidad serán un hecho.

¿Cuándo fue la última vez que escuchaste que alguien incorporó la JVM en una aplicação para ejecutar complementos o lógica personalizada? ¿No fue hace poco, si es que alguna vez lo fue? Si bien la JVM es potente, es notoriamente difícil integrarla en otras aplicações. Se han realizado algunas integraciones de alto perfil (como subprogramas Java en navegadores), pero en gran medida han desaparecido debido a su torpeza o facilidad de mantenimiento.

WebAssembly, por otro lado, está diseñado para ser integrable. Incorporar un entorno de ejecución de Wasm en una aplicação suele ser tan fácil como incorporar una nueva biblioteca. Una vez hecho esto, su aplicação puede ejecutar código Wasm; esto podría ser para ampliar un motor de juego, modificar un algoritmo, responder a un evento o cualquier otra cosa que pueda imaginar. Wasm proporciona una versatilidad en cuanto a capacidad de integración que la JVM no está equipada para ofrecer (o no quiere ofrecer, de hecho).

Podría decirse que aquí es donde WebAssembly brilla más. La JVM tiene su propio modelo de seguridad, pero fue diseñada bajo el supuesto de que el código que se ejecuta es confiable. WebAssembly rechaza fundamentalmente esa premisa (nacida en el navegador, donde visitar un sitio web necesariamente descarga código no confiable y lo ejecuta), Wasm emplea un modelo de entorno aislado estricto de denegación por defecto. No otorga acceso al código a los recursos del sistema, a la memoria ni a otras funcionalidades a menos que esté autorizado explícitamente. Este enfoque minimiza inherentemente las superficies de ataque y hace que Wasm sea ideal para entornos donde la ejecución de código no confiable es una preocupación.

El modelo de seguridad de la JVM es funcional, pero no fue diseñado para el nivel de seguridad que ofrece Wasm.

La JVM es un veterano experimentado en el mundo de la tecnología. Con décadas de historia en su haber, está respaldado por una gran adopción, amplias herramientas empresariales y una comunidad tan grande que se siente como una fuerza inamovible en el desarrollo de software; sabemos que no desaparecerá pronto. Si la longevidad y la estabilidad comprobada son clave para sus casos de uso, la JVM cumple con sus expectativas.

WebAssembly, por su parte, sigue siendo el nuevo en el sector. A pesar de ser más joven y estar a punto de cumplir su décimo aniversario, el entusiasmo en torno a Wasm está creciendo a un ritmo exponencial. Aunque menos maduro que el JVM actual, la trayectoria de WebAssembly sugiere un futuro brillante.

Tanto WebAssembly como JVM son tecnologías increíbles, cada una de las cuales se destaca en formas que se adaptan a sus entornos y casos de uso. La JVM prospera en flujos de trabajo empresariales donde las aplicações completas y las ricas capacidades de ejecución son importantes. Por otro lado, la capacidad de integración de Wasm, su entorno de ejecución liviano, su compatibilidad entre lenguajes y su seguridad incomparable lo convierten en una opción atractiva para complementos y edge computing.

Entonces, ¿cuál deberías elegir? Si está desarrollando aplicações independientes con necesidades de tiempo de ejecución sólidas, la JVM sigue siendo una opción práctica y probada en el tiempo. Pero si desea flexibilidad entre idiomas o la capacidad de conectarse a aplicaciones existentes con facilidad, WebAssembly podría inclinar la balanza.