Le futur proche de WebAssembly
Des développements sont en cours et apparaissent dans les navigateurs.
La tendance pour accélérer l'implémentation de nouvelles fonctions dans le langage est par la réutilisation du code. Par exemple, au lieu de doter le runtime d'un garbage collector, on utilise celui de JavaScript ou autre système hôte. Cela implique que les objets concernés soient aussi créés dans le système hôte et utilisés directement par wasm. Les types primaires comme le nombre entier ou réel ne sont pas concernés, les types évolués telles que chaînes de caractères, structures et objet sont traités de cette façon.
Le travail de développement du langage est réalisé en quatre phases: Proposition de fonctionnalité, proposition de spécification quand elle est adoptée, implémentation et standardisation.
4 - Standardisation
Dans cette phare, les fonctionnalités sont parfaitement définies et souvent déjà implémentée dans un navigateur. Il ne s'agit plus que de définir une spécification pour tous les autres.
a) Import/export d'objets mutables globaux
Alors que wasm ne peut partager des entités globales avec JavaScript que si elle sont constantes, on pourra maintenant partager aussi des variables entre différents modules.
b) Instructions d'extension de nombre signés
De nouvelles instructions permettent de changer la taille d'un nombre, par exemple passer d'en entier sur 8 bits à un entier sur 32 bits, en conservant le signe.
3) Implémentation
Un navigateur au moins a implémenté ces nouvelles fonctionnalités.
a) Retour de plusieurs valeurs
Actuellement une fonction ne peut retourner qu'une seule valeur. Les langages qui sont compilés en wasm et qui supportent les retours multiples devaient trouver une astuce. Maintenant cela sera compilé directement.
C'est implémenté en 2021.
b) Un nouveau type: référence
Ce qui manque crucialement à wasm, ce sont les types string, structure, objet. Les compilateurs doivent les stocker en mémoire comme suite d'octets et ajouter un runtime pour y accéder!
WebAssembly n'ajoute pas ces nouveaux types, mais il va permettre de les utiliser en les déclarant dans le système hôte, généralement JavaScript, avec le type anyref. Anyref contient une référence à un objet fourni par le système, à défaut de permettre de le créer en wasm.
Cela est déjà implémenté dans Firefox.
2) Spécification proposée
Il s'agit ici de ce qui a été accepté et dont on doit encore définir comment cela sera implémenté.
Conversion BigInt
Alors que JavaScript est en train de se doter de nombres entier de tailles variées, en complément du type float standard et unique, wasm dispose déjà de cela. Il s'agit de pemettre d'utiliser en JS les entiers de wasm et inversement.
1) Fonctionnalités proposées
En théorie il ne s'agit que de propositions et elle pourraient encore être refusées, mais il y a une telle demande pour ces fonctionnalités qu'elles peuvent être considérées comme acquises.
Ici la liste est plus longue, il faudra sans doute un peu de temps avant que tout cela ne soit implémenté.
a) Garbage collector
Une fonction longtemps attendue, proposée sous une forme inattendue. Wasm n'aura pas de garbage collector, mais utilisera celui de JavaScript (ou autre système hôte). Cela simplifie bien les choses car gérer la même mémoire avec deux GC concurrents aurait posé problème. L'inconvénient est que cela ne peut opérer sur des variables de wasm: elles doivent être implémentées en JavaScript et accessibles directement par wasm, avec le type interne anyref.
b) Integration des modules ECMAScript
De même que JavaScript peut importer des modules externes avec la commande import, wasm pourra utiliser aussi une commande import.
c) Exceptions
Pour permettre aux langages qui supportent les exceptions, de compiler directement en wasm, on propose une structure try catch, et en outre un système d'interruptions.
d) Threads
Ils ne seront pas implémentés mais il s'agit plutôt d'un mécanisme pour que les WebWorkers de JS puissent partager la mémoire (au lieu de communiquer par postMessage).
C'est encore un cas où l'on utilise le code interne de JS au lieu d'ajouter un code propre à wasm.
e) Annotations
Les annotations ajoutées au format textuel de wasm réprésenteront les méta-données ajoutées par les compilateurs au code binaire.
f) Opérations sur mémoire
De nouvelles instructions pour lire et écrire directement dans la mémoire, plus rapides.
g) SIMD
Les SIMD sont des instructions de microprocesseurs sur 128 bits pour des traitements plus rapides. Le code wasm va calquer ces instructions.
Implémenté en 2021 sauf dans Safari.
h) Appel en retour (tail call)
Une nouvelle instruction, return_call, rend les fonctions récursives plus économiques en mémoire.
i) Accès au DOM
En créant un nouveau type de liaison avec JavaScript, on va disposer d'un accès plus direct au DOM (Document Object Modèle), donc au contenu d'une page Web.
Conclusion
Toutes ces nouvelles possibilités vont permettre aux compilateurs de créer un code plus simple, sans "polyfills", ces astuces de conversion qui alourdissent et ralentissent les programmes. En même temps, les SIMD et threads vont aussi accélérer le traitement, donc rendre WebAssembly encore plus performant.
