Discussion :

[Uther]

Les configurations évoquées dans la FAQ stipulent que JS sera toujours utilisé en complément de WASM. Je pense notamment que la configuration 3 ("[COLOR=#3D3D3E]Mostly HTML/CSS/JavaScript app with a few high-performance WebAssembly modules") sera le cas le plus courant pour l'usage web classique.

Sauf que encore une fois, dans cette FAQ, on parle de JavaScript en tant que langage de programmation, pas dans le cas particulier de la cible de compilation.

Le canvas de la config 2 sera bien joli pour les démos techniques, mais snobber le DOM n'est pas envisageable pour toutes les contraintes SEO/accessibilité/amélioration progressive...

C'est vrai que l'accès direct au DOM n'est pas encore possible avec les implémentations actuelles de WebAssembly, bien qu'on puisse le faire indirectement passant par JS.
Mais il est bel et bien prévu de pouvoir interagir directement avec le DOM a terme.

Alors si JS reste incontournable, pourquoi ça ne serait pas une cible de compilation ?

Le tournevis est indispensable au bricoleur, on peut même essayer de planter des clous avec en tapant avec le dos du manche. Il n’empêche que s'il a un marteau sous la main, le bricoleur utilisera l'outil le plus adapté.
De même, JavaScript est un outil de script indispensable au développeur Web et il est devenu une cible de compilation parce qu'on avait pas d'autre choix à l'époque. Mais le WebAssembly a été construit spécifiquement pour être une cible de compilation efficace. Bien sur rien n’empêche de continuer a compiler en JavaScript mais autant utiliser l'outil fait pour.

Ça l'est déjà actuellement comme expliqué précédemment, et si en plus le WASM rend obligatoire l'usage d'un compilateur, alors il n'y a aucune raison de s'en priver. Parions-même que dans les langages alternatifs, des frameworks viendront gérer à la place du développeur ce mélange de JS/WASM en sortie. Je ne m'avance pas à grand chose en disant cela, puisque c'est déjà ce que font les premiers frameworks expérimentaux là-dessus : https://github.com/aspnet/blazor ; https://github.com/DenisKolodin/yew

Le but principal de la compilation en JavaScript dans les framework que tu donnes en exemple, c'est comme fallback pour les navigateurs qui ne gèrent pas encore le WebAssembly, ou pour les fonctionnalités qui ne sont pas encore gérées par WASM.
Bien évidement que pendant la transition, on continuera a compiler en JavaScript, mais quand on a le choix, le WebAssembly est préférable comme cible de compilation.

[headmax]

Je vais pas faire le pessimiste mais il suffit de voir https://www.w3.org/Consortium/activities#wgs les dates et planning sur les groups de travail pour se rendre compte que ce qui existe actuellement pour le web il leur faudra 2 ans de travail quelques mois implémentations devra suivre pour les éditeurs de navigateurs 3 ou 4 releases pendant ce temps j'en résume que c'est pas pour demain.

[SylvainPV]

Désolé Uther, ce n'est pas ce que disent toutes les personnes que je connais qui travaillent de près ou de loin sur WebAssembly et ce n'est pas non plus ce que font les projets expérimentaux dans le domaine. Il faut voir à quelle échelle de temps tu fais référence comme période de transition, car beaucoup de choses peuvent changer en dix ans. Mais pour ce qui est de l'horizon 2025, je reste sur ma position: d'un point de vue global, WASM sera utilisé de manière sporadique et sur des besoins particuliers, au même titre que les Web Workers ; et JS restera majoritaire, mais derrière des process de build de plus en plus complexes et industrialisés. On a aujourd'hui l'embarras du choix dans les langages alternatifs compilant en JS (ReasonML, Elm, Scala, Kotlin...) et les extensions de JS (TypeScript, JSX...). Je ne vois pas pourquoi la tendance s'inverserait alors que les attentes sont toujours plus élevées et qu'on commence enfin à avoir des stacks matures.

En supposant que WASM atteindrait voire dépasserait ses high level goals, et disposerait de la même variété d'API document et navigateur que JS (ce dont je doute fortement ; on parle de 25 ans de travail ici), ça ne me paraît pas du tout évident qu'il s'impose naturellement comme langage cible, pour les raisons de taille de bundle dont on parlé. Rendez-vous en 2025 pour savoir qui avait raison

[Uther]

Désolé Uther, ce n'est pas ce que disent toutes les personnes que je connais qui travaillent de près ou de loin sur WebAssembly et ce n'est pas non plus ce que font les projets expérimentaux dans le domaine.

Forcément, tant que le DOM ne sera pas implémenté, les outils professionnels actuellement utilisés qui se basant sur le DOM ne vont pas pouvoir s'engager fortement dessus, et les outils déjà complet vont réfléchir avant de faire la transition car ca peut potentielment représenter beaucoup de travail.
Mais quand WASM sera a parité avec JavaScript au niveau des API Web, il n'y aura pas de raison de préférer compiler vers JavaScript plutôt que WebAssembly, qui devrait avoir de meilleures performances et être mieux intégré.

En supposant que WASM atteindrait voire dépasserait ses high level goals, et disposerait de la même variété d'API document et navigateur que JS (ce dont je doute fortement ; on parle de 25 ans de travail ici), ça ne me paraît pas du tout évident qu'il s'impose naturellement comme langage cible, pour les raisons de taille de bundle dont on parlé. Rendez-vous en 2025 pour savoir qui avait raison

Tu te rends compte que il y a 25 ans JavaScript n'existait même pas ? Et il ne s'agit pas de redévelopper les Web API de zéro, juste de permettre à WebAssembly d'accéder à celles qui existent déjà. J'ose quand même espérer que ça ne prendra pas plus de 2 ou 3 ans. Le point difficile c'est l'accès aux objets qui sont gérés par le GC de JavaScript, mais une fois ça résolu, ça devrait aller vite.

[SylvainPV]

23 ans pour être exact, c'est pas comme si ça faisait une différence . Et au rythme où ça va ça en fera 25 quand ils se pencheront dessus. Bref je m'arrête là car on se répète. Bonne soirée

[draeni31]

salut,
si on prend l'exemple d'un getElementById, même si par exemple un input type = number (en html), vous ne pouvez pas récupérer le nombre avec un simple document.getElementById('nombre'); il faut non seulement lui rajouter .value, mais cela ne suffit même pas, il faut encore lui mettre du parseFloat avant ... et ce ne serait pas "fortement typé" ? javascript ne sait pas lire le html tel qu'il est et n'interprete que très mal le DOM, alors oui, il est un peu bébête ce js !