Dans le
dernier article sur WebAssembly, j'ai fait la déclaration suivante:
Certains comparent WebAssembly avec des applets Java. Dans un certain sens, ils ont raison, mais d'un autre côté, ils se trompent grandement. D'une manière ou d'une autre, j'écrirai un article sur les différences, mais pour l'instant, parlons des similitudes. D'une certaine manière, WebAssembly est une manière différente d'accomplir ce à quoi la JVM était destinée: c'est une machine virtuelle ordinaire pour les logiciels multiplateformes.
Beaucoup de gens ont manifesté leur intérêt pour ce sujet, alors examinons-le de plus près! Dans cet article, nous comparons WebAssembly avec trois technologies: Flash, applets Java et un
peu avec PNaCL. L'article se concentre également sur son utilisation sur le
Web , bien que nous ayons précédemment examiné l'utilisation d'options pour utiliser WebAssembly hors ligne. Mais nous parlerons d'une
telle comparaison plus tard. Enfin, cet article est similaire à manger des tapas [collation espagnole de nombreux ingrédients différents - env. par.], voici un tas de petites sections. Il me semble que c'est un peu court, mais en même temps j'essaye de bloguer, et si je continue à le développer, ça prendra une éternité, donc je suis désolé.
Je pense qu'une comparaison avec les applets Flash et Java est assez
naturelle lorsque vous rencontrez cette description de WebAssembly:
WebAssembly (Wasm pour faire court) est un format d'instructions binaires pour une machine virtuelle empilée. Wasm a été développé comme une version portable de compilation de langages de haut niveau tels que C, C ++ et Rust, qui vous permet de déployer des applications client et serveur sur Internet.
C'est un peu comme la technologie passée. Il est logique de comparer la façon dont ils sont connectés et de suggérer de petites différences entre eux. Mais WebAssembly est considérablement différent pour plusieurs raisons.
Wasm battu
La première raison pour laquelle WebAssembly est différent est qu'il a fini par réussir, contrairement aux technologies précédentes. Je veux dire la victoire dans un sens spécifique. Si vous comparez le nombre d'applications Flash et le nombre d'applications WebAssembly, Wasm est susceptible de perdre. Les adhérents à WebAssembly devront travailler dur pour distribuer cette plateforme.
Quand je parle de la victoire de WebAssembly, je veux dire qu'il fait désormais partie de la plateforme web. Flash, les applets Java et PNaCL fonctionnaient via des plugins. Dans un sens, ils étaient en
dehors de l'écosystème Web. Ils n'ont jamais été inclus dans la norme, ce qui est très important.
En un sens, une telle explication suffit. Mais simplement signaler un fait ne signifie pas expliquer ses
causes . Le reste de cet article tentera de comprendre
pourquoi cela s'est produit: pourquoi WebAssembly a réussi ce que d'autres technologies ne pouvaient pas faire. Ici, de
nombreuses raisons sont liées les unes aux autres, mais j'essaie de les diviser raisonnablement en différents points.
D'autres technologies ne cadraient pas avec la plateforme
Vous vous en souvenez?
Ou est-ce?
Et ça?
Une applet basée sur ces technologies n'est pas vraiment une
application Web . Vous avez une page Web avec un morceau découpé et votre applet a fonctionné dans ce cadre. Vous perdez tous les avantages des autres technologies web: ni HTML, ni CSS, ni la possibilité de s'intégrer au web. Ces plateformes n'interagissent pas avec le reste de la plateforme dans le navigateur. Eh bien,
techniquement, c'est possible , mais dans la pratique, ces technologies ont été utilisées différemment.
Comment le Web prend-il en charge un écosystème qui ne s'intègre pas avec lui? Cela n'arrivera jamais. Et les utilisateurs l'ont finalement résolument rejeté. En plus des jeux, les utilisateurs
détestaient Flash et les applets Java étaient lourdes et lentes. Ces technologies ne sont pas ancrées dans la plate-forme Web.
WebAssembly, en revanche, est beaucoup plus proche de JavaScript. En fait, Wasm ne vous enlève pas une partie de l'écran. Il ne crée pas son propre petit monde fermé. Maintenant, en utilisant JavaScript, et
à l'avenir seul , il est capable d'interagir avec l'environnement. Il s'intègre juste dedans.
Autres technologies détenues par des entreprises
Java appartenait à Sun Microsystems, Flash appartenait à Adobe. Pourquoi est-ce important?
L'influence des entreprises sur Internet est un sujet complexe.
En général, le Web fonctionne sur un modèle de pseudo-consensus. Java et Flash, en revanche, étaient contrôlés par leurs sociétés respectives. Ils ont une forte motivation à faire du profit, pas à améliorer Internet. Et cela a conduit en partie à la situation susmentionnée: ces entreprises ne se soucient pas de s'intégrer correctement avec le reste de la plate-forme. Pourquoi en ont-ils besoin? Il est préférable pour les entreprises de bloquer leur plateforme et d'abandonner complètement le reste d'Internet. La motivation est complètement biaisée.
WebAssembly est une initiative conjointe de Mozilla, Google, Apple, Microsoft et autres. Il ne fait pas la promotion de la plate-forme spécifique d'une personne, mais représente plutôt les intérêts communs d'un large éventail de parties prenantes, à la fois d'entreprise et individuelles.
WebAssembly a suivi le processus Web
L'affiliation d'entreprise signifie
également que ces technologies n'ont jamais suivi le processus que nous utilisons pour normaliser le Web. Le processus d'adoption des normes Web est bien établi, mais ces technologies étaient trop importantes et fonctionnaient un peu différemment. En revanche, WebAssembly a suivi la procédure standard adoptée pour les technologies Web.
Asm.js a d'abord été créé pour prouver que nous pouvons faire des choses impressionnantes avec le Web. Son exécution s'est avérée être de haute qualité et a démontré les capacités de la technologie, bien qu'il n'y ait rien de fantastique là-dedans. Le principal atout de
asm.js était qu'il ne s'agissait que de code JavaScript: il est entièrement compatible avec l'écosystème existant. "Ne brisez pas Internet" est une règle très, très importante pour les développeurs de navigateurs.
WebAssembly était une version améliorée de
asm.js Après avoir trouvé un consensus autour de
asm.js tout le monde s'est réuni pour faire de WebAssembly une réalité. Étant donné qu'il ne s'agit pas uniquement de JavaScript, il aurait dû suivre l'ensemble du processus d'implémentation dans les navigateurs, et il l'a réussi. Il s'agit désormais de la spécification W3C, qui
est conforme aux standards du Web, mais ne les contredit pas.
Conséquence: les autres technologies étaient trop volumineuses et instables
Une autre raison pour laquelle Wasm a réussi: c'est minuscule. Wasm adopte l'approche d'autres technologies Web: commencer petit et grandir sur cette base. Gardez la compatibilité descendante. Les technologies passées n'ont pas non plus suivi cette convention sociale particulière. Un runtime spécifique a été chargé pour les applets Flash et Java, la compatibilité n'était donc pas requise. PNaCl est construit sur le code IR LLVM complètement instable. Ils allaient en faire un sous-ensemble stable, mais si LLVM changeait, il y aurait une divergence, ce qui n'est pas très bon.
Ces technologies sont également trop lourdes pour espérer une stabilisation. Pouvez-vous imaginer que quatre fabricants de navigateurs définissent entièrement les spécifications JVM et acceptent ensuite cette sémantique pour toujours? Pour tout ActionScript, qui est en soi une version similaire mais différente d'ECMAScript? Pour tout LLVM-IR?
Les grandes technologies présentent un risque inacceptable pour la situation. Il s'agit d'un accord tout ou rien, et voici un pari sûr "rien". WebAssembly, en revanche, ne fait presque rien. Il s'agit principalement de mathématiques et d'un appel JavaScript. Autrement dit, il est
beaucoup plus facile de s'entendre ici.
Corollaire: d'autres technologies nécessitent une machine virtuelle entièrement séparée
Dans cet article, je n'ai pas mentionné Dart, mais il convient également ici. La phrase «Disons simplement mettre la JVM dans chaque navigateur», le problème principal est que le navigateur a
déjà un runtime JavaScript. Un seul runtime est assez difficile à maintenir, sans parler de deux. Et comment les intégrez-vous?
WebAssembly, quant à lui, est conçu comme une petite extension des machines virtuelles JavaScript existantes. Bien que vous
puissiez implémenter votre propre machine virtuelle WebAssembly - cela se fait souvent avec WebAssembly hors ligne, mais pour les navigateurs, les coûts de maintenance sont beaucoup, beaucoup plus bas.
D'autres technologies sont trop spécifiques.
WebAssembly est fondamentalement indépendant de la langue. Les applets Flash et Java ont été principalement conçues pour exécuter ActionScript et Java. Ils sont profondément attachés à leur sémantique relative. Même PNaCl en souffre dans une certaine mesure: LLVM est vraiment adapté aux langages de type C, mais pas tout à fait dans la même mesure.
Voulons-nous vraiment choisir une langue pour l'ensemble d'Internet? Nous avons déjà JavaScript. Avez-vous déjà imaginé une troisième langue? Quatrièmement? Une approche indépendante est bien meilleure à long terme.
Wasm a une approche stricte de la sécurité
Les applets Java et Flash ont été un véritable
cauchemar pour la sécurité. Même si des efforts ont été faits pour les protéger, des problèmes se posent en réalité constamment.
D'autre part, WebAssembly a de nouveau reçu des bonus de la machine virtuelle JavaScript: tous les efforts pour isoler son bac à sable s'appliquent également à Wasm. Ici, certaines fonctions de l'assembleur habituel sont manquantes, ce qui peut entraîner des vulnérabilités, telles que la destruction de la pile. Wasm fonctionne en toute sécurité avec la mémoire, ce qui est très important!
De plus, WebAssembly a été initialement conçu avec l'idée de
validation à l'esprit : il est entièrement typé et les programmes peuvent être vérifiés sans exécuter de code. Les spécifications comprennent des instructions sur la façon d'effectuer une telle validation. C'est très utile!
Conclusion
Je veux dire ce qui suit à propos de cet article: il est écrit du point de vue du
développeur . Mais les développeurs sont importants car ils contrôlent le Web. La technologie doit être cohérente avec leurs objectifs - c'est aussi important que la commodité pour les utilisateurs finaux. Dans un prochain article, je vais essayer d'analyser les problèmes du point de vue des utilisateurs. Faut écrire beaucoup!
Pour résumer:
- D'autres technologies n'ont pas été intégrées à la plate-forme Web, ce qui a été entravé par des intérêts commerciaux.
- D'autres technologies exigeaient trop: beaucoup ont dû sacrifier dans la mise en œuvre.
- Wasm a une très bonne isolation et validation du sandbox, ce que d'autres n'avaient tout simplement pas.