Quelles sont les différences entre WebAssembly et la JVM ?

À la base, la JVM et WebAssembly ont été conçus pour exécuter du code compilé à peu près n'importe où : pour la JVM, cela signifiait des machines avec des systèmes d'exploitation ou des architectures de processeur différents, quelque chose d'inédit pour l'époque, et pour WebAssembly, cela signifiait n'importe quel navigateur Web sur n'importe quel ordinateur, n'importe où, pour le reste du temps.

La JVM, introduite au milieu des années 1990 aux côtés de Java, a évolué vers une plate-forme à part entière offrant un support d'exécution riche : collecte des déchets, bibliothèques standard étendues et outils d'exécution gérée. Cependant, certains pourraient dire que cela donne à la JVM une quantité considérable de gonflement : de grandes empreintes mémoire et des temps de démarrage plus lents. Bien qu'extrêmement puissant, cela rend la JVM moins adaptée aux applications légères.

En revanche, WebAssembly a été conçu pour le Web, spécifiquement pour exécuter du code dans les navigateurs. En conséquence, il a été conçu pour privilégier un environnement d'exécution léger et des temps de démarrage ultra-rapides, mais sans le support d'exécution riche. Cibler uniquement les navigateurs rendrait Wasm moins portable que le bytecode Java, mais aujourd'hui, les environnements d'exécution Wasm autonomes peuvent s'exécuter en dehors du Web, ouvrant de nouvelles portes pour les applications côté serveur, les systèmes embarqués et edge computing. De plus, une prise en charge d’exécution supplémentaire limitée est prévue pour WebAssembly, à savoir la récupération de place, mais il est peu probable que nous voyions toute l’étendue de la prise en charge d’exécution dans WebAssembly offerte par la JVM.

La JVM fonctionne uniquement avec sa famille de langages (Java, Kotlin, Scala et quelques autres), tous intentionnellement conçus pour fonctionner sur la JVM. Bien que l’écosystème Java dispose de bibliothèques et de frameworks étendus, l’interopérabilité ne se produit qu’entre ces langages JVM. Les applications basées sur JVM peuvent faire appel à du code natif, mais pas sans beaucoup d’efforts et de soin.

WebAssembly n'a pas été conçu pour prendre en charge un seul langage de programmation ou pour favoriser un certain style de langage, qu'il soit fonctionnel, ramasse-miettes ou interprété. N’importe quel langage (Rust, JavaScript, Python, C++) peut être compilé pour s’exécuter sur un environnement d’exécution Wasm. Bien que cela ne signifie pas que le code de chacun de ces langages serait capable de communiquer entre eux dès maintenant, grâce à la norme émergente Component Model , les développeurs sont en mesure de prendre plusieurs modules Wasm écrits dans différents langages et de les connecter de manière transparente. Bientôt, pour WebAssembly, la liaison et l’interopérabilité seront une évidence.

À quand remonte la dernière fois où vous avez entendu dire que quelqu’un avait intégré la JVM dans une application pour exécuter des plugins ou une logique personnalisée ? Pas récemment, si jamais, n'est-ce pas ? Bien que la JVM soit puissante, il est notoirement difficile de l'intégrer dans d'autres applications. Certaines intégrations très médiatisées ont eu lieu (comme les applets Java dans les navigateurs), mais elles ont été largement abandonnées en raison de leur lourdeur ou de leur facilité de maintenance.

WebAssembly, en revanche, est conçu pour être intégrable. L'intégration d'un runtime Wasm dans une application est souvent aussi simple que l'intégration d'une nouvelle bibliothèque. Une fois cela fait, votre application peut exécuter du code Wasm : cela peut servir à étendre un moteur de jeu, modifier un algorithme, répondre à un événement ou tout ce que vous pourriez imaginer. Wasm offre une polyvalence en termes d’intégration que la JVM n’est pas équipée pour offrir (ou ne veut pas offrir, d’ailleurs).

C’est sans doute là que WebAssembly brille le plus. La JVM possède son propre modèle de sécurité, mais elle a été conçue en partant du principe que le code exécuté est fiable. WebAssembly rejette fondamentalement cette prémisse : né dans le navigateur, où la visite d'un site Web télécharge nécessairement du code non fiable et l'exécute, Wasm utilise un modèle sandbox strict de refus par défaut. Il n’accorde pas d’accès au code aux ressources système, à la mémoire ou à d’autres fonctionnalités, sauf autorisation explicite. Cette approche minimise intrinsèquement les surfaces d’attaque et rend Wasm idéal pour les environnements où l’exécution de code non fiable est 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 le niveau de sécurité offert par Wasm.

La JVM est un vétéran chevronné du monde de la technologie. Avec des décennies d’histoire à son actif, il est soutenu par une adoption massive, des outils d’entreprise étendus et une communauté si vaste qu’il semble être une force immuable dans le développement de logiciels – nous savons qu’il ne disparaîtra pas de sitôt. Si la longévité et la stabilité éprouvée sont essentielles pour vos cas d'utilisation, la JVM est à la hauteur.

WebAssembly, quant à lui, est toujours le nouveau venu sur le marché. Bien qu'il soit plus jeune et qu'il fête à peine ses 10 ans, l'enthousiasme autour de Wasm grandit à un rythme exponentiel. Bien que moins mature que la JVM aujourd’hui, la trajectoire de WebAssembly laisse présager un avenir prometteur.

WebAssembly et la JVM sont toutes deux des technologies incroyables, chacune excellant d'une manière qui convient à leurs environnements et cas d'utilisation. La JVM s'épanouit dans les flux de travail d'entreprise où les applications complètes et les capacités d'exécution riches sont importantes. D'autre part, l'intégrabilité de Wasm, son runtime léger, sa compatibilité multilingue et sa sécurité inégalée en font un choix convaincant pour les plugins et edge computing.

Alors, lequel choisir ? Si vous développez des applications autonomes avec des besoins d'exécution robustes, la JVM reste un choix pratique et éprouvé. Mais si vous souhaitez une flexibilité entre les langues ou la possibilité de vous connecter facilement à des applications existantes, WebAssembly pourrait bien faire pencher la balance.