Cuando los desarrolladores más perspicaces descubren WebAssembly (o Wasm, para abreviar), suele surgir una pregunta: ¿en qué se diferencia WebAssembly de la máquina virtual de Java (JVM)? Es una pregunta excelente, ya que ambas tecnologías se basan en la misma promesa fundamental: un código de bytes portátil diseñado para «escribir una vez y ejecutar en cualquier lugar». Aunque comparten una base común, sus enfoques y objetivos son muy distintos. Analizar estas diferencias permite entender por qué ambas siguen siendo proyectos independientes e importantes, cada uno con su propio ecosistema.
Diferencias conceptuales
En esencia, tanto la JVM como WebAssembly se diseñaron para ejecutar código compilado prácticamente en cualquier lugar. En el caso de la JVM, esto significaba poder hacerlo en máquinas con distintos sistemas operativos o arquitecturas de CPU, algo sin precedentes en su época; en el de WebAssembly, en cualquier navegador web de cualquier ordenador, en cualquier lugar y para siempre.
La JVM, presentada a mediados de la década de 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, extensas bibliotecas estándar y herramientas para la ejecución gestionada. Sin embargo, algunos podrían decir que esto añade una sobrecarga considerable a la JVM, con un elevado consumo de memoria y tiempos de arranque más lentos. Aunque es extremadamente potente, estas características hacen que la JVM sea menos adecuada para aplicaciones ligeras.
En cambio, WebAssembly se diseñó pensando en la web, concretamente para ejecutar código dentro de los navegadores. Por ello, su arquitectura prioriza un entorno de ejecución ligero y unos tiempos de arranque ultrarrápidos, aunque sin un soporte de ejecución tan completo. Si se limitara 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 funcionar fuera de la web, lo que abre nuevas posibilidades para las aplicaciones del lado del servidor, los sistemas embebidos y la computación en el borde. Además, WebAssembly está incorporando cierto soporte de ejecución adicional, aunque limitado, como la recolección de basura, pero es poco probable que llegue a ofrecer toda la amplitud de soporte de ejecución que proporciona la JVM.
Interoperabilidad
La JVM solo funciona con su familia de lenguajes —Java, Kotlin, Scala y algunos más—, todos ellos diseñados expresamente para ejecutarse sobre la JVM. Aunque el ecosistema de Java cuenta con numerosas bibliotecas y frameworks, la interoperabilidad solo es posible entre estos lenguajes de la JVM. Las aplicaciones basadas en la JVM pueden invocar código nativo, pero hacerlo requiere un gran esfuerzo y mucho cuidado.
WebAssembly no se diseñó para admitir únicamente un lenguaje de programación ni para favorecer un estilo de lenguaje concreto, ya fuera funcional, con recolección de basura o interpretado. Cualquier lenguaje —Rust, JavaScript, Python, C++— podría compilarse para ejecutarse en un entorno de ejecución de Wasm. Aunque eso no significa que el código de cada uno de estos lenguajes pueda comunicarse entre sí actualmente, gracias al estándar emergente Modelo de componentes, los desarrolladores pueden tomar varios módulos Wasm escritos en distintos lenguajes y conectarlos sin problemas. Pronto, en WebAssembly, la vinculación y la interoperabilidad se darán por sentadas.
Integrabilidad
¿Cuándo fue la última vez que oyó que alguien había integrado la JVM en una aplicación para ejecutar complementos o lógica personalizada? No ha sido recientemente, si es que ha ocurrido alguna vez, ¿verdad? Aunque la JVM es potente, es bien sabido que resulta muy difícil integrarla en otras aplicaciones. Ha habido algunos casos destacados de integración (como los applets de Java en los navegadores), pero en gran medida han desaparecido debido a su aparatosidad o a las dificultades de mantenimiento.
WebAssembly, en cambio, está diseñado para poder integrarse fácilmente. Integrar un entorno de ejecución de Wasm en una aplicación suele ser tan sencillo como añadir una nueva biblioteca. Una vez hecho esto, la aplicación puede ejecutar código Wasm, ya sea para ampliar un motor de videojuegos, modificar un algoritmo, responder a un evento o hacer cualquier otra cosa que puedas imaginar. Wasm ofrece una versatilidad de integración que la JVM no está preparada para proporcionar (ni pretende hacerlo, dicho sea de paso).
Seguridad
Podría decirse que este es el aspecto en el que más destaca WebAssembly. La JVM tiene su propio modelo de seguridad, pero se diseñó partiendo de la premisa de que el código que se ejecuta es de confianza. WebAssembly rechaza de plano esa premisa: nacido en el navegador, donde visitar un sitio web implica necesariamente descargar y ejecutar código que no es de confianza, Wasm emplea un estricto modelo de aislamiento que deniega el acceso de forma predeterminada. No permite que el código acceda a los recursos del sistema, a la memoria ni a otras funciones, salvo que se autorice expresamente. Este enfoque reduce de forma inherente las superficies de ataque y hace que Wasm sea ideal para entornos en los que la ejecución de código que no es de confianza supone un riesgo.
El modelo de seguridad de la JVM es funcional, pero sencillamente no se diseñó para ofrecer el nivel de seguridad que proporciona Wasm.
Madurez y comunidad
La JVM es toda una veterana en el mundo de la tecnología. Con décadas de historia a sus espaldas, cuenta con una enorme adopción, un amplio conjunto de herramientas empresariales y una comunidad tan extensa que parece una fuerza inamovible en el desarrollo de software; sabemos que no va a desaparecer a corto plazo. Si la longevidad y una estabilidad demostrada son fundamentales para tus casos de uso, la JVM cumple con creces.
WebAssembly, por su parte, sigue siendo el recién llegado. A pesar de su juventud y de estar a punto de cumplir diez años, el entusiasmo en torno a Wasm crece a un ritmo exponencial. Aunque actualmente es menos maduro que la JVM, la trayectoria de WebAssembly apunta a un futuro prometedor.
Conclusión
Tanto WebAssembly como la JVM son tecnologías increíbles, y cada una destaca en aspectos que se adaptan a sus respectivos entornos y casos de uso. La JVM sobresale en los flujos de trabajo empresariales, donde son importantes las aplicaciones completas y las amplias capacidades del entorno de ejecución. Por otro lado, la facilidad de integración de Wasm, su entorno de ejecución ligero, su compatibilidad entre lenguajes y su seguridad sin parangón lo convierten en una opción muy atractiva para complementos y computación en el borde.
Entonces, ¿cuál deberías elegir? Si estás desarrollando aplicaciones independientes que requieren un entorno de ejecución sólido, la JVM sigue siendo una opción práctica y de eficacia probada. Pero si buscas flexibilidad entre distintos lenguajes o la posibilidad de integrarte fácilmente en aplicaciones existentes, WebAssembly podría inclinar la balanza.
Sobre el autor
Artículos relacionados del blog
Proteger los endpoints de las API dificulta la seguridad de las API
Descubre las complejidades de la seguridad de las API, los retos a los que se enfrentan las organizaciones, la evolución de los ataques contra endpoints de API y la necesidad de políticas de seguridad adaptadas.
¿Qué es el sesgo de la IA y por qué es importante para TI?
Descubre los fundamentos del aprendizaje de la IA. Aprende cómo pueden surgir sesgos en la IA y qué riesgos plantean para las TI y la transformación digital.
Redefiniendo la ciberseguridad en el extremo de la nube distribuida con IA y telemetría en tiempo real
La transformación digital y la adopción de tecnologías en la nube están provocando cambios en las arquitecturas de las aplicaciones. Estos cambios introducen nuevas superficies de ataque, que son el objetivo de métodos de ataque avanzados, altamente organizados y con motivaciones económicas. Mediante el uso del framework Morpheus de NVIDIA, F5 está investigando técnicas para detectar estas amenazas avanzadas con telemetría en tiempo real y análisis basados en IA.
El papel de la nube en las aplicaciones nativas del edge
No debería sorprender que, al igual que la aparición de la nube dio lugar a las aplicaciones nativas de la nube, el edge esté impulsando un conjunto de aplicaciones nativas del edge. Sin embargo, estas aplicaciones no residirán únicamente en el edge. Al mismo tiempo, están surgiendo nuevos patrones arquitectónicos que aprovechan las aplicaciones alojadas en la nube y en el centro de datos.
La creciente diversidad de ubicaciones y usuarios está impulsando a las empresas hacia el edge
En el contexto del ámbito de las aplicaciones, el término «usuario» siempre se ha referido a la entidad que interactúa con una aplicación. Del mismo modo que los cambios en las arquitecturas de las aplicaciones impulsan cambios en las tecnologías que permiten ofrecerlas y protegerlas, los cambios en la definición de usuario han provocado cambios en los lugares donde se despliegan las aplicaciones.
El edge está impulsando un renacimiento de las infraestructuras
A medida que las organizaciones aumentan la generación de datos y tratan de extraer valor empresarial de ellos, sin duda recurrirán a la analítica y la automatización basadas en la IA y el aprendizaje automático. Precisamente este tipo de cargas de trabajo son las que más se beneficiarían de una infraestructura optimizada y, sin embargo, hoy en día son las que menos probabilidades tienen de poder aprovecharla.