Lorsque des développeurs avisés découvrent WebAssembly (ou Wasm en abrégé), une question revient souvent : en quoi WebAssembly diffère-t-il de la machine virtuelle Java (JVM) ? C’est une excellente question : ces deux technologies reposent sur la même promesse fondamentale, à savoir un bytecode portable conçu pour « écrire une fois, exécuter partout ». Bien qu’elles partagent un socle commun, leurs approches et leurs objectifs diffèrent considérablement. L’examen de ces différences permet de comprendre pourquoi elles demeurent deux projets distincts et importants, chacun doté de son propre écosystème.
Différences conceptuelles
Fondamentalement, la JVM et WebAssembly ont tous deux été conçus pour exécuter du code compilé pratiquement partout : pour la JVM, cela signifiait sur des machines dotées de systèmes d’exploitation ou d’architectures de processeur différents, ce qui était sans précédent à l’époque ; pour WebAssembly, cela signifiait dans n’importe quel navigateur web, sur n’importe quel ordinateur, où qu’il se trouve, et ce pour toujours.
La JVM, apparue au milieu des années 1990 en même temps que Java, est devenue une plateforme à part entière offrant une prise en charge complète de l’exécution : ramasse-miettes, vastes bibliothèques standard et outils d’exécution gérée. Cependant, certains pourraient estimer que cela alourdit considérablement la JVM, avec une empreinte mémoire importante et des temps de démarrage plus longs. Malgré sa très grande puissance, la JVM est donc moins adaptée aux applications légères.
À l’inverse, WebAssembly a été conçu pour le Web, plus précisément pour exécuter du code dans les navigateurs. Son architecture privilégie donc un environnement d’exécution léger et des démarrages ultrarapides, mais sans prise en charge avancée à l’exécution. Le fait de cibler uniquement les navigateurs rendrait Wasm moins portable que le bytecode Java, mais aujourd’hui, des environnements d’exécution Wasm autonomes peuvent fonctionner en dehors du Web, ouvrant ainsi de nouvelles perspectives pour les applications côté serveur, les systèmes embarqués et l’edge computing. Par ailleurs, WebAssembly bénéficiera bientôt de quelques fonctionnalités supplémentaires à l’exécution, notamment le ramasse-miettes, mais il est peu probable qu’il offre un jour une prise en charge aussi complète que celle de la JVM.
Interopérabilité
La JVM ne fonctionne qu’avec sa famille de langages — Java, Kotlin, Scala et quelques autres —, tous spécifiquement conçus pour s’exécuter sur la JVM. Bien que l’écosystème Java dispose de bibliothèques et de frameworks très complets, l’interopérabilité se limite à ces langages de la JVM. Les applications basées sur la JVM peuvent faire appel à du code natif, mais cela exige beaucoup d’efforts et de précautions.
WebAssembly n’a pas été conçu pour ne prendre en charge qu’un seul langage de programmation ni pour privilégier un certain type de langage, qu’il soit fonctionnel, doté d’un ramasse-miettes ou interprété. N’importe quel langage — Rust, JavaScript, Python, C++ — peut être compilé pour s’exécuter dans un environnement d’exécution Wasm. Même si cela ne signifie pas que le code de chacun de ces langages peut dès aujourd’hui communiquer avec celui des autres, grâce à la nouvelle norme Component Model, les développeurs peuvent combiner de manière transparente plusieurs modules Wasm écrits dans différents langages. Bientôt, avec WebAssembly, l’édition de liens et l’interopérabilité iront de soi.
Intégrabilité
À quand remonte la dernière fois que vous avez entendu dire que quelqu’un avait intégré la JVM à une application pour exécuter des plug-ins ou une logique personnalisée ? Cela ne date pas d’hier, si tant est que ce soit déjà arrivé, n’est-ce pas ? Bien que la JVM soit puissante, elle est notoirement difficile à intégrer à d’autres applications. Certaines intégrations très médiatisées ont bien vu le jour (comme les applets Java dans les navigateurs), mais elles ont en grande partie disparu en raison de leur lourdeur ou de leur difficulté de maintenance.
WebAssembly, en revanche, est conçu pour être intégré. Intégrer un environnement d’exécution Wasm dans une application est souvent aussi simple que d’ajouter une nouvelle bibliothèque. Une fois cette étape terminée, votre application peut exécuter du code Wasm, que ce soit pour étendre un moteur de jeu, modifier un algorithme, réagir à un événement ou réaliser tout ce que vous pouvez imaginer. Wasm offre en matière d’intégration une polyvalence que la JVM n’est pas en mesure de proposer (et qu’elle ne cherche d’ailleurs pas à offrir).
Sécurité
C’est sans doute sur ce point que WebAssembly se distingue le plus. La JVM possède son propre modèle de sécurité, mais celui-ci a été conçu en partant du principe que le code exécuté est digne de confiance. WebAssembly rejette fondamentalement ce postulat : né dans le navigateur, où la consultation d’un site web implique nécessairement le téléchargement et l’exécution de code non fiable, Wasm applique un modèle de bac à sable strict qui refuse tout accès par défaut. Il n’autorise le code à accéder aux ressources système, à la mémoire ou à d’autres fonctionnalités que si cet accès est explicitement accordé. Cette approche réduit intrinsèquement les surfaces d’attaque et rend Wasm idéal pour les environnements où l’exécution de code non fiable constitue une préoccupation.
Le modèle de sécurité de la JVM est fonctionnel, mais il n’a tout simplement pas été conçu pour offrir le niveau de sécurité proposé par Wasm.
Maturité et communauté
La JVM est une technologie éprouvée dans le monde de l’informatique. Forte de plusieurs décennies d’existence, elle bénéficie d’une adoption massive, d’un vaste éventail d’outils destinés aux entreprises et d’une communauté si importante qu’elle semble être une force inébranlable dans le développement logiciel — nous savons qu’elle n’est pas près de disparaître. Si la pérennité et une stabilité éprouvée sont essentielles pour vos cas d’usage, la JVM répondra à vos attentes.
WebAssembly, quant à lui, fait encore figure de petit nouveau. Bien que plus jeune et sur le point de fêter ses 10 ans, Wasm suscite un enthousiasme qui croît de manière exponentielle. Même s’il est aujourd’hui moins mature que la JVM, la trajectoire de WebAssembly laisse présager un avenir prometteur.
Conclusion
WebAssembly et la JVM sont deux technologies remarquables, chacune excellant dans des domaines adaptés à son environnement et à ses cas d’usage. La JVM s’épanouit dans les processus d’entreprise où les applications complètes et les fonctionnalités d’exécution avancées sont essentielles. De son côté, Wasm constitue un choix particulièrement intéressant pour les plugins et l’edge computing grâce à sa facilité d’intégration, à son environnement d’exécution léger, à sa compatibilité entre les langages et à sa sécurité inégalée.
Alors, lequel choisir ? Si vous développez des applications autonomes nécessitant un environnement d’exécution robuste, la JVM reste un choix pratique qui a fait ses preuves. Mais si vous recherchez une grande flexibilité entre les langages ou la possibilité de vous intégrer facilement à des applications existantes, WebAssembly pourrait bien faire pencher la balance.
À propos de l’auteur
Articles de blog associés
Pourquoi devriez-vous vous intéresser à WebAssembly ?
WebAssembly (Wasm) est un jeu d’instructions binaires portable, rapide et sécurisé, qui permet d’exécuter des applications hautes performances sur n’importe quelle plateforme.
Trois choses à savoir sur les applications d’IA
Les applications d’IA sont des applications modernes, mais elles présentent certaines particularités. Découvrez les points essentiels à connaître sur les applications basées sur l’IA.
État des lieux de la stratégie applicative 2022 : il est temps de moderniser les opérations
Il est devenu évident que, pour maintenir la dynamique de leur transformation numérique, les organisations doivent recentrer leurs efforts sur les fonctions métier. Si les expériences destinées aux clients restent prioritaires, il est également indispensable de permettre la numérisation de fonctions telles que les services juridiques, les ressources humaines et la finance. Les DSI prennent donc les commandes, tandis que la transformation numérique passe de la modernisation des applications à celle des opérations.
Clouds multiples ou multicloud : faciliter la transition
La gestion et la sécurisation des charges de travail deviennent complexes à mesure que les entreprises adoptent une stratégie de cloud connecté. Découvrez comment F5 répond au besoin d’une nouvelle approche de la mise en réseau multicloud.
L’expérience client dépend de la visibilité
Une enquête menée par Dimensional Research auprès de plus de 3 000 utilisateurs d’applications mobiles a confirmé ce que beaucoup d’entre nous pensent des attentes actuelles des clients.
Transformation numérique et explosion du portefeuille d’applications
La transformation numérique stimule la croissance des portefeuilles d’applications et modifie la manière dont celles-ci sont développées, déployées, intégrées et, en définitive, utilisées.