Au départ, en 1995, JavaScript a été présenté comme un langage léger pour les scripts assez simples. De plus, il a été pensé de telle façon qu’il soit facilement utilisable, même par les développeurs novices, pour des choses relativement simples, comme s’assurer que vous avez rempli un formulaire correctement lorsque vous le soumettez par exemple.Plus tard, en 2008, a été lancé ce qui a été désigné comme étant la guerre des performances ; les navigateurs ont commencé à ajouter la compilation à la volée (JIT, une technique visant à améliorer la performance de systèmes bytecode compilés par la traduction de bytecode en code machine natif au moment de l'exécution). Tandis que le JavaScript s’exécutait, le JIT pouvait voir des modèles et faire en sorte que le code s’exécute plus rapidement en fonction de ces modèles. C’est ce qui a contribué à l’amélioration des performances de JavaScript qui a alors commencé à être utilisé pour plus de choses qu’il n’était censé gérer au départ, comme la programmation côté serveur avec Node.js.
Pourtant, malgré ces améliorations, il arrive que les performances soient imprévisibles. Aussi, pour accélérer les choses, le JIT a ajouté quelques éléments à l'exécution, parmi lesquels :
- l’optimisation et la désoptimisation ;
- de la mémoire utilisée pour les informations de compatibilité et de récupération du moniteur pour les cas où des récupérations se produisent ;
- de la mémoire utilisée pour stocker les versions de base et optimisées d'une fonction.
Autant d’éléments qui font qu’il arrive que le navigateur ne peut pas exécuter une application aussi rapidement qu’en natif. C’est alors qu’intervient WebAssembly dont l’un des objectifs est de permettre aux applications complexes de fonctionner de façon optimale sur navigateur – telles que les jeux vidéo immersifs en 3D, le design informatisé, l’édition d’image et de vidéo et la visualisation scientifique.
WASI, l'interface système WebAssembly
Mozilla a annoncé le début d'un nouvel effort de normalisation avec WASI, l'interface système de WebAssembly.
Pourquoi ? La fondation explique que les développeurs commencent à pousser WebAssembly au-delà du navigateur, car il fournit un moyen rapide, évolutif et sécurisé d’exécuter le même code sur toutes les machines.
Mais nous n’avons pas encore de base solide sur laquelle évoluer. Le code en dehors d'un navigateur nécessite un moyen de communiquer avec le système: une interface système. Et la plateforme WebAssembly ne l’a pas encore.
WebAssembly est un langage d'assemblage pour une machine conceptuelle et non physique. C'est pourquoi il peut être utilisé dans différentes architectures de machines.
Tout comme WebAssembly est un langage d'assemblage pour une machine conceptuelle, WebAssembly a besoin d'une interface système pour un système d'exploitation conceptuel, et non d'un système d'exploitation unique. De cette façon, il peut être exécuté sur tous les systèmes d'exploitation.
C’est ce que WASI est : une interface système pour la plateforme WebAssembly.
Mozilla assure que son objectif est de créer une interface système qui sera un véritable compagnon de WebAssembly et qui résistera à l'épreuve du temps. Cela signifie respecter les principes clés de WebAssembly - la portabilité et la sécurité.
Vous pouvez voir WASI en action dans cette vidéo :
Comment WebAssembly s'exécute-t-il en dehors du navigateur aujourd'hui ?
Emscripten était le premier outil de production de WebAssembly. Il émule une interface système d’exploitation particulière, POSIX, sur le Web. Cela signifie que le développeur peut utiliser des fonctions de la bibliothèque standard C (libc).
Pour ce faire, Emscripten a créé sa propre implémentation de libc. Cette implémentation a été scindée en deux parties: elle a été compilée dans le module WebAssembly et l'autre partie a été implémentée dans le code de laison JS. Celui-ci appelle ensuite le navigateur, qui parle ensuite au système d'exploitation.
La plupart des premiers codes de WebAssembly ont été compilés avec Emscripten. Aussi, lorsque les utilisateurs ont commencé à vouloir exécuter WebAssembly sans navigateur, ils ont commencé par faire exécuter le code compilé par Emscripten.
Ainsi, ces environnements d'exécution ont dû créer leurs propres implémentations pour toutes ces...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.