ACTU
Wasmer : A fond dans le natif mais pas trop
par CBL,
email @CBL_Factor
Le JavaScript a fait des progrès fulgurants ces dix dernières années. Du côté exécution, les interpréteurs modernes comme V8 de Google font tourner le code JS à une vitesse folle. Du côté syntaxe, JS suit un peu le même chemin que le C++ à savoir qu'après des années d'immobilisme, le langage reçoit des mises à jour régulières. On peut enfin coder des vraies classes avec héritage et constructeurs (et pas les pseudo-classes appeleés prototypes). Du côté fonctionnalités, l'introduction des web workers permet d'utiliser plusieurs threads.
Mais le plus gros changement est qu'il n'est plus nécessaire d'écrire en JavaScript pour faire du JavaScript. On peut écrire dans toute une pelleté de langages (Typescript, Haxe, CoffeeScript...) capables de "compiler" en code JavaScript compréhensible par les navigateurs. Emscripten est allé encore plus loin. Au début, il permettait de "compiler" du code C++ en code JavaScript afin d'exécuter une application native sur le web. Puis asm.js est arrivé et a permis d'exécuter les applications compilées de cette manière à des vitesses proches du natif.
Tout cela a fini par être standardisé dans ce qui s'appelle WebAssembly, qui permet d'exécuter du code pseudo-natif dans un navigateur. Si le code en question fait des appels à OpenGL, les appels en question sont transcrits en appels webGL durant la compilation. C'est grâce à WebAssembly que vous pouvez exporter vos projets Unity pour le web ou que vous pouvez jouer à toutes les consoles rétro dans un navigateur. Une appli WebAssembly peut aussi communiquer avec du code JS. Par exemple ammo.js, la version WebAssembly du moteur physique Bullet, peut être utilisée par les moteurs 3D JavaScript comme PlayCanvas.
En 2010, Ryan Dahl s'est dit que c'était du gâchis que V8 soit enfermé dans un navigateur. Il a donc créé Node.js, une version de V8 capable d'exécuter du code JS en ligne de commande et donc le principal but était de faire tourner des serveurs web. Wasmer part un peu du même principe et vient de passer en 1.0. Ses développeurs se sont dits que WebAssembly était un invention bien trop belle pour rester enfermée dans un navigateur. Wasmer permet donc d'exécuter une appli WebAssembly en dehors d'un navigateur. Comme pour Node.js, il vous suffit de télécharger l'exécutable Wasmer et de le lancer en passant votre appli WebAssembly en argument.
Comme Wasmer existe pour architectures x86 et ARM et pour Windows, Linux et Darwin, la même application WebAssembly peut tourner sur Windows, Android, iOS, macOS et Linux sans nécessiter d'être recompilée à chaque fois. Et là vous allez me dire : "c'est sympa ton truc mais ça existe depuis un bail et ça s'appelle Java". Oui mais non. Wasmer diffère de Java sur de nombreux points:
Ce qui est amusant est qu'en parallèle, de plus en plus d'applications de bureau sont en fait des applications web emballées avec Chromium (la version libre de Chrome). C'est le cas de Steam mais aussi de Spotify, de Discord, de Visual Studio Code, de Microsoft Teams et de GitHub Desktop. On murmure même que la prochaine version d'Outlook suivra ce chemin. Si cela rend les applications assez lourdes en matière de consommation de mémoire, le processus de build et de mise à jour est nettement simplifié vu qu'il n'y a rien à compiler. Cela permet aussi de les porter sur macOS et Linux sans le moindre effort. Accesoirement, cela rend la connexion à des services web nettement plus facile sans compter les petits bonus offerts par un navigateur web comme le rendu accéléré par le GPU, un lecteur audio/vidéo intégré et les communications audio/vidéo temps réel via webRTC.
Mais le plus gros changement est qu'il n'est plus nécessaire d'écrire en JavaScript pour faire du JavaScript. On peut écrire dans toute une pelleté de langages (Typescript, Haxe, CoffeeScript...) capables de "compiler" en code JavaScript compréhensible par les navigateurs. Emscripten est allé encore plus loin. Au début, il permettait de "compiler" du code C++ en code JavaScript afin d'exécuter une application native sur le web. Puis asm.js est arrivé et a permis d'exécuter les applications compilées de cette manière à des vitesses proches du natif.
Tout cela a fini par être standardisé dans ce qui s'appelle WebAssembly, qui permet d'exécuter du code pseudo-natif dans un navigateur. Si le code en question fait des appels à OpenGL, les appels en question sont transcrits en appels webGL durant la compilation. C'est grâce à WebAssembly que vous pouvez exporter vos projets Unity pour le web ou que vous pouvez jouer à toutes les consoles rétro dans un navigateur. Une appli WebAssembly peut aussi communiquer avec du code JS. Par exemple ammo.js, la version WebAssembly du moteur physique Bullet, peut être utilisée par les moteurs 3D JavaScript comme PlayCanvas.
En 2010, Ryan Dahl s'est dit que c'était du gâchis que V8 soit enfermé dans un navigateur. Il a donc créé Node.js, une version de V8 capable d'exécuter du code JS en ligne de commande et donc le principal but était de faire tourner des serveurs web. Wasmer part un peu du même principe et vient de passer en 1.0. Ses développeurs se sont dits que WebAssembly était un invention bien trop belle pour rester enfermée dans un navigateur. Wasmer permet donc d'exécuter une appli WebAssembly en dehors d'un navigateur. Comme pour Node.js, il vous suffit de télécharger l'exécutable Wasmer et de le lancer en passant votre appli WebAssembly en argument.
Comme Wasmer existe pour architectures x86 et ARM et pour Windows, Linux et Darwin, la même application WebAssembly peut tourner sur Windows, Android, iOS, macOS et Linux sans nécessiter d'être recompilée à chaque fois. Et là vous allez me dire : "c'est sympa ton truc mais ça existe depuis un bail et ça s'appelle Java". Oui mais non. Wasmer diffère de Java sur de nombreux points:
- langages de programmation : pour écrire une appli Java, il faut coder en Java ou en Kotlin. Pour WebAssembly, le choix du langage est bien plus vaste : C/C++, Rust, C#, F#, Kotlin, Swift, Go, D, Pascal...
- intégration : en plus d'exister en tant que programme standalone, Wasmer peut être intégré en tant que bibliothèque dans tous les langages majeurs
- rapidité : on nous promet des performances proches du natif donc on attend de voir. Les machines virtuelles Java sont toujours des brouettes à tel point que les applis Android sont désormais compilées en natif à l'installation.
- sécurité : par défaut, Wasmer exécute les pseudo-binaires WebAssembly dans un bac à sable sans aucun accès à l'OS. C'était aussi une promesse de Java donc là encore on attend de voir. Mais Wasmer est développé en Rust ce qui nous met en confiance
- légalité : Wasmer est libre (licence MIT qui est la plus permissive) alors que certaines parties de Java restent la propriété d'Oracle ce qui a donné lieu à un procès contre Google dont l'issue risque de changer à jamais ce qui est possible de faire avec une API
- zéro plugin : les pseudo-binaires WebAssembly tourne sur un navigateur sans utiliser de plugin contrairement aux pseudo-binaires Java
Ce qui est amusant est qu'en parallèle, de plus en plus d'applications de bureau sont en fait des applications web emballées avec Chromium (la version libre de Chrome). C'est le cas de Steam mais aussi de Spotify, de Discord, de Visual Studio Code, de Microsoft Teams et de GitHub Desktop. On murmure même que la prochaine version d'Outlook suivra ce chemin. Si cela rend les applications assez lourdes en matière de consommation de mémoire, le processus de build et de mise à jour est nettement simplifié vu qu'il n'y a rien à compiler. Cela permet aussi de les porter sur macOS et Linux sans le moindre effort. Accesoirement, cela rend la connexion à des services web nettement plus facile sans compter les petits bonus offerts par un navigateur web comme le rendu accéléré par le GPU, un lecteur audio/vidéo intégré et les communications audio/vidéo temps réel via webRTC.