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.

Lire la suite sur le site : Wasmer : A fond dans le natif mais pas trop.

On peut enfin coder des vraies classes avec héritages

Hérésie ! Au bûcher !

Le problème avec WebAsm c'est qu'on reçoit un binaire a exécuter sans aucun moyen de l'inspecter/modifier. C'est un problème pour le browser car ça permet de tuer les adblocks, ajouter des DRMs, du tracking, etc. Coté server c'est un peu pareil, les dépendances Wasmer (wapm) sont des binaires et il sera difficile de s'assurer qu'il n'y ait pas de backdoor au autres payloads malfaisantes. De plus ces binaire n'ont pas besoin d'être signés...

C'est l'avantage du JS, qui même quand il est transpilé et offusqué reste relativement lisible une fois reformaté. Pareil en Java ou les décompilateurs donnent du code très similaire aux sources d'origine.

On dirait que WebAssembly se démocratise juste à temps pour remplacer flash \o/

CBL tes articles techniques sont toujours aussi intéressants !

Dans la theorie on a plein de chose a gagner dans la pratique les site

fennec a écrit :
Le problème avec WebAsm c'est qu'on reçoit un binaire a exécuter sans aucun moyen de l'inspecter/modifier.

Tu vas pouvoir miner du bitcoin pour quelqu'un d'autre que toi sans meme t'en apercevoir (plus facilement qu'en javascript).
Il y a un an j'avais lu un article disant que la majeur partie des sites en WebAssembly avait des applications malveillantes. ca promet.

Le WebAssembly j'y crois absolument pas pour le web (mais peut-etre que l'ecosysteme permettra de faire de bonnes applications desktop).

Java dans le web est mort parce qu'il y avait mille version de la machine virtuelle, parce que c'était lourd et parce qu'il y avait des problemes de sécurités.
Pareil pour ActiveX.
Pareil pour Flash (moins lourd que les deux autres), mais il a survecu longtemps parce que les outils de developpement était vraiment au top.

La seule chose qui change pour WebAssembly c'est que la machine virtuelle sera dans le navigateur et non pas un plugin bancal.
Ca ira certainement vite, mais pour la sécurité j'ai vraiment hate de voir le carnage.

Rdv dans 10 ans.

Muchacho a écrit :
Dans la theorie on a plein de chose a gagner dans la pratique les site

fennec a écrit :
Le problème avec WebAsm c'est qu'on reçoit un binaire a exécuter sans aucun moyen de l'inspecter/modifier.

Tu vas pouvoir miner du bitcoin pour quelqu'un d'autre que toi sans meme t'en apercevoir (plus facilement qu'en javascript).
Il y a un an j'avais lu un article disant que la majeur partie des sites en WebAssembly avait des applications malveillantes. ca promet.

Le WebAssembly j'y crois absolument pas pour le web (mais peut-etre que l'ecosysteme permettra de faire de bonnes applications desktop).

Java dans le web est mort parce qu'il y avait mille version de la machine virtuelle, parce que c'était lourd et parce qu'il y avait des problemes de sécurités.
Pareil pour ActiveX.
Pareil pour Flash (moins lourd que les deux autres), mais il a survecu longtemps parce que les outils de developpement était vraiment au top.

La seule chose qui change pour WebAssembly c'est que la machine virtuelle sera dans le navigateur et non pas un plugin bancal.
Ca ira certainement vite, mais pour la sécurité j'ai vraiment hate de voir le carnage.

Rdv dans 10 ans.

D'ailleurs est-ce qu'il y a un moyen de savoir si un site fait tourner du WebAssembly ou c'est totalement transparent? Parce que dans ce dernier cas j'imagine bien des sites faire tourner une appli WebAssembly cachée sur un site standard, et ça ça fait peur.

Samax a écrit :

Muchacho a écrit :
Dans la theorie on a plein de chose a gagner dans la pratique les site

fennec a écrit :
Le problème avec WebAsm c'est qu'on reçoit un binaire a exécuter sans aucun moyen de l'inspecter/modifier.

Tu vas pouvoir miner du bitcoin pour quelqu'un d'autre que toi sans meme t'en apercevoir (plus facilement qu'en javascript).
Il y a un an j'avais lu un article disant que la majeur partie des sites en WebAssembly avait des applications malveillantes. ca promet.

Le WebAssembly j'y crois absolument pas pour le web (mais peut-etre que l'ecosysteme permettra de faire de bonnes applications desktop).

Java dans le web est mort parce qu'il y avait mille version de la machine virtuelle, parce que c'était lourd et parce qu'il y avait des problemes de sécurités.
Pareil pour ActiveX.
Pareil pour Flash (moins lourd que les deux autres), mais il a survecu longtemps parce que les outils de developpement était vraiment au top.

La seule chose qui change pour WebAssembly c'est que la machine virtuelle sera dans le navigateur et non pas un plugin bancal.
Ca ira certainement vite, mais pour la sécurité j'ai vraiment hate de voir le carnage.

Rdv dans 10 ans.

D'ailleurs est-ce qu'il y a un moyen de savoir si un site fait tourner du WebAssembly ou c'est totalement transparent? Parce que dans ce dernier cas j'imagine bien des sites faire tourner une appli WebAssembly cachée sur un site standard, et ça ça fait peur.

Les cryptominers sont très répandus.

Badou a écrit :

On peut enfin coder des vraies classes avec héritages

Hérésie ! Au bûcher !

Tout à fait,

Au fait, au risque de passer pour un relou pédant, il n'y a pas de notion de classes en js, juste des objects avec des prototypes: c'est juste un sucre syntaxique introduit en es6 mais tout reste basé sur les prototype d'object.

L'intérêt était double: simplifier le codage/améliorer la lisibilité du code (en es5, il y a 15 manières différentes de déclarer des prototypes) et d'ouvrir le javascript aux dév d'autres langages objet type Java.

Après promis, je vais éviter le débat les classes c'est le mal (moi j'aime bien la simplification introduite par les mtos clés class/inherit :D) pendant de l'antidéluvien windows vs linux pour le js :D

Pour un exemple de virage avec WebAssembly depuis un core c++ vers du JS j'ai vu cette vidéo, en plus c'est sympa ça reste dans le domaine jeux vidéo ludique puisque c'est sur un moteur de jeu.
A savoir que la base de code à été migré récemment vers TypeScript il me semble.

Samax a écrit :

D'ailleurs est-ce qu'il y a un moyen de savoir si un site fait tourner du WebAssembly ou c'est totalement transparent? Parce que dans ce dernier cas j'imagine bien des sites faire tourner une appli WebAssembly cachée sur un site standard, et ça ça fait peur.

C'est totallement transparent. Certains minaient des bitcoin grace a des extensions en Javascript, le seul moyen de le remarquer était de savoir si ton CPU tournait a plein regime en ayant que ton navigateur ouvert.

A une lointaine époque le javascript était lui aussi optionnel parce qu'il avait du code malicieux qui ouvrait des popups. Quand un site était crée il devait fonctionner avec et sans javascript parce qu'il y a avait beaucoup d'utilisateur qui le desactivait.


Dans mon commentaire précédent j'ai oublié de mentionner que les sites en WebAssembly only risquent tres fort de peser énormément, Java/Flash se reposait sur un plugin, mais le plugin distribuait une bibliotheque standard (pour les interactions souris/claviers, affichage 2D etc), pour WebAssembly a moins qu'il y ait aussi une bibliotheque standard tout ce code la sera dupliquer de maniere inutile.

Un exemple un peu concret: ce framework, Uno, qui permet de créer une application multiplatform (Windows, Linux, navigateur, etc), montre une démo de calculatrice qui tourne sous navigateur, le tout fait 10MB compressé, 60MB decompressé. Et le temps de chargement est loin d'etre transparent.
Je ne sais pas si c'est juste tres tres mal optimisé mais c'est vraiment pas encourageant.

Samax a écrit :
D'ailleurs est-ce qu'il y a un moyen de savoir si un site fait tourner du WebAssembly ou c'est totalement transparent? Parce que dans ce dernier cas j'imagine bien des sites faire tourner une appli WebAssembly cachée sur un site standard, et ça ça fait peur.

Non c'est transparent, regarde par exemple ces demos:
https://magnum.graphics/showcase/

J'aurais bien aimé un contrôle qui te demande si tu veux bien lancer le Webassembly, mais c'est probablement "by design"...

edit: grillé par Muchacho :)

fennec a écrit :
Le problème avec WebAsm c'est qu'on reçoit un binaire a exécuter sans aucun moyen de l'inspecter/modifier. C'est un problème pour le browser car ça permet de tuer les adblocks, ajouter des DRMs, du tracking, etc. Coté server c'est un peu pareil, les dépendances Wasmer (wapm) sont des binaires et il sera difficile de s'assurer qu'il n'y ait pas de backdoor au autres payloads malfaisantes. De plus ces binaire n'ont pas besoin d'être signés...

La lisibilité du Js c'est superficiel. Si tu fais assez d'effort pour l'offusqué ca sera ni plus ni moins dur que faire de la retro ingénierie sur d'autres langages.

Muchacho a écrit :
Dans mon commentaire précédent j'ai oublié de mentionner que les sites en WebAssembly only risquent tres fort de peser énormément, Java/Flash se reposait sur un plugin, mais le plugin distribuait une bibliotheque standard (pour les interactions souris/claviers, affichage 2D etc), pour WebAssembly a moins qu'il y ait aussi une bibliotheque standard tout ce code la sera dupliquer de maniere inutile.

Un exemple un peu concret: ce framework, Uno, qui permet de créer une application multiplatform (Windows, Linux, navigateur, etc), montre une démo de calculatrice qui tourne sous navigateur, le tout fait 10MB compressé, 60MB decompressé. Et le temps de chargement est loin d'etre transparent.
Je ne sais pas si c'est juste tres tres mal optimisé mais c'est vraiment pas encourageant.

Il faut comparer ce qui est comparable. Alors oui WebAssembly ne fournit pas de bibliothèque standard mais on peut faire de l'interop avec Js. Donc en soit ça ne change pas grand chose. Sauf qu'il est vrai que la notion de bibliothèque standard en Js est assez faible. Ensuite Uno est un framework C#. Aujourd'hui il me semble que la compilation AoT (Ahead of Time) n'est pas disponible pour le C#. Donc aujourd'hui au lieu d'avoir du code natif en C# on a du C# émulé par le CLR qui lui même est jitté par le module qui éxécute le WASM. Autrement dit, on a 2 niveaux d'indirections pour éxécutér du code machine ce qui empêche des optimisations et rend le tout assez lent. Et dans le cas d'un langage qui nécessite une VM (ou runtime volumineux) car pas natif de base (en gros tout sauf C/C++, Rust et Swift) on se retrouve à devoir fournir une VM pour le runtime. C'est la que l'article de CBL est un peu trompeur (sans doute pour pas trop compliqué les choses) mais entre du C/C++ compilé pour WASM et du Java/C# qui tourne en WASM il y a un mode d'écart en volume et en performance.

Muchacho a écrit :
Le WebAssembly j'y crois absolument pas pour le web (mais peut-etre que l'ecosysteme permettra de faire de bonnes applications desktop).

Rdv dans 10 ans.

Quand on voit l'usine à gaz qu'est NPM, je pense que WebAssembly à une carte à jouer. L'écosystème Javascript à toujours été merdique et WASM permet de s'en passer.

Muchacho a écrit :
Un exemple un peu concret: ce framework, Uno, qui permet de créer une application multiplatform (Windows, Linux, navigateur, etc), montre une démo de calculatrice qui tourne sous navigateur, le tout fait 10MB compressé, 60MB decompressé. Et le temps de chargement est loin d'etre transparent.
Je ne sais pas si c'est juste tres tres mal optimisé mais c'est vraiment pas encourageant.

Mais comment ça se fait qu'on puisse inspecter les éléments etc si c'est du C# ? Je pige pas trop.
Parce que là on dirait que c'est fait à l'ancienne avec des divs pour chaque bouton de la calculette etc :
https://i.imgur.com/BHm67lB.png

Blade_Runner a écrit :

Muchacho a écrit :
Un exemple un peu concret: ce framework, Uno, qui permet de créer une application multiplatform (Windows, Linux, navigateur, etc), montre une démo de calculatrice qui tourne sous navigateur, le tout fait 10MB compressé, 60MB decompressé. Et le temps de chargement est loin d'etre transparent.
Je ne sais pas si c'est juste tres tres mal optimisé mais c'est vraiment pas encourageant.

Mais comment ça se fait qu'on puisse inspecter les éléments etc si c'est du C# ? Je pige pas trop.
Parce que là on dirait que c'est fait à l'ancienne avec des divs pour chaque bouton de la calculette etc :
https://i.imgur.com/BHm67lB.png

Ca change rien. Tu utilises le Dom tout pareil. En gros tu passes de Html + Css + Js à Html + Css + Wasm.

Muchacho a écrit :
Un exemple un peu concret: ce framework, Uno, qui permet de créer une application multiplatform (Windows, Linux, navigateur, etc), montre une démo de calculatrice qui tourne sous navigateur, le tout fait 10MB compressé, 60MB decompressé. Et le temps de chargement est loin d'etre transparent.Je ne sais pas si c'est juste tres tres mal optimisé mais c'est vraiment pas encourageant.

C'est mal optimisé mais c'est pas de la faute de WASM. La même calculatrice sur Windows ne pèse que 27 Ko en natif. Mais elle repose sur tout un tas de DLLs comprises dans Windows. Du coup quand la version WASM est compilé, ces libraries dynamiques se retrouvent embarquées en statique ce qui ajoute énormément au poids de l'appli.

codec-abc a écrit :
Aujourd'hui il me semble que la compilation AoT (Ahead of Time) n'est pas disponible pour le C#

Ah si justement. Tu peux faire du AoT depuis .NET 1.0
Unity fait aussi de la compilation AoT quand tu exportes ton projet en convertissant le code en C++. C'est pour cela que l'export WebAssembly de Unity fonctionne aussi bien.

CBL a écrit :

codec-abc a écrit :
Aujourd'hui il me semble que la compilation AoT (Ahead of Time) n'est pas disponible pour le C#

Ah si justement. Tu peux faire du AoT depuis .NET 1.0
Unity fait aussi de la compilation AoT quand tu exportes ton projet en convertissant le code en C++. C'est pour cela que l'export WebAssembly de Unity fonctionne aussi bien.

Pour Unity c'est différent, le code est transpilé en C++ et compilé avec un compilo C++. Pour le Wasm, il semble bien que la plupart des implémentations (sinon toutes ?) utilisent Mono en mode interprété comme en témoigne cette issue github. Autrement, pour le natif je me suis jamais trop renseigné mais hormis pour contrainte technique (Apple qui empêche de générer du code au runtime) il y a pas vraiment de raison de faire de l'AoT vu que le gain est assez minime.

En 2018 (après ce message GitHub), Unity a abandonné Mono au profit de IL2CPP et donc de compilation AoT. Bon par contre leur compilo ne supporte pas le multi-threads...