Design: Webasm peut remplacer Javascript dans le navigateur ?

Je ne suis pas assez familier avec c#, mais en fait, je pense que wasm ne peut pas prendre complètement en charge le javascript.

Tout d'abord, si vous avez essayé, vous constaterez que javascript est beaucoup plus rapide que wasm dans certaines opérations de niveau inférieur, telles que "+,-,*,/" et d'autres opérations liées aux mathématiques en raison de la légère surcharge lors de l'appel à partir de JavaScript dans WebAssembly et inversement. #1120

Deuxièmement, pour les développeurs Web, ils connaissaient déjà le javascript et sa grammaire, il est inutile et difficile pour eux de créer des applications Web avec un autre langage de développement non Web.

Enfin, avec l'aide de " Binary AST ", les performances des applications Web actuelles seront portées à un nouveau niveau sans aucune révision sur ces applications.

PS :
Peu importe C# ou Java, si vous souhaitez rendre ce langage de programmation beaucoup plus convivial pour les développeurs, l'efficacité de ce langage sera limitée en raison de certaines fonctionnalités "faciles à utiliser" telles que "type faible" et de toute autre fonctionnalité, vice versa.

@Becavalier Peut-être que oui si vous essayez d'appeler une fonction wasm à partir de la surcharge de contexte JS, mais le runtime ne communique pas avec Javascript tant qu'il n'est pas exclusivement requis. _etc.._ Toute l'exécution qui se passe dans le contexte wasm est assez rapide. Le délai apparaît lorsque le pont JS est introduit, comme dans le cas de #1120, vous essayez d'imprimer l'horodatage des performances dans le contexte Javascript pour une fonction exécutée dans le contexte wasm, ce qui constitue un délai supplémentaire.

Des frameworks populaires comme Angular2/4 qui est une refonte complète adoptant Typescript, Android dans Kotlin ou iOS dans Swift, quand il y a un grand nom derrière certains frameworks ou le monde entier essaie d'adopter le changement.

Le fait est donc qu'il est possible que JS soit mis à l'écart ou même supprimé de l'image en faisant abstraction des ponts API et en portant les runtimes sur le navigateur. Webassembly a ouvert la porte aux compilateurs d'autres langages pour concurrencer Javascript sur navigateur.

Au départ, nous avions adopté des technologies qui rendaient notre code JS plus efficace pour s'exécuter sur des machines virtuelles telles que V8 et autres, mais vous pouvez désormais écrire et compiler dans un code assembleur qui peut dépasser le code JS.

Vous pouvez maintenant vous attendre à ce que des compilateurs pour le Web remplacent les transpileurs tels que TypeScript, CoffeeScript, etc.

Développeurs Javascript, croisez les doigts . Peut s'attendre à un grand mouvement dans les années à venir.

PS : j'adore Javascript et C-Lang

Webassembly a ouvert la porte aux compilateurs d'autres langages pour concurrencer Javascript sur navigateur.

Oui en effet, c'est l'un des buts de WebAssembly.

Voici une citation de la FAQ WebAssembly :

Alors que WebAssembly permettra, au fil du temps, de compiler de nombreux langages sur le Web, JavaScript a un élan incroyable et restera le seul langage dynamique privilégié (comme décrit ci-dessus) du Web. De plus, il est prévu que JavaScript et WebAssembly soient utilisés ensemble dans un certain nombre de configurations :

• Des applications C++ complètes et compilées qui exploitent JavaScript pour coller les choses ensemble.

Gardez à l'esprit que d'autres langages sont compilés en JavaScript depuis des années et qu'ils continueront à le faire avec ou sans WebAssembly.

Vous pouvez déjà compiler C#, F#, C++, OCaml, Elm, PureScript, Haskell, Java, Python, Ruby, Perl, etc. en JavaScript.

Vous pouvez compiler le bytecode .NET en JavaScript , vous pouvez compiler le bytecode OCaml en JavaScript , et GWT existe depuis 11 ans et a été utilisé dans de grands projets.

Ces projets existent depuis de nombreuses années. Ce n'est pas vraiment nouveau.

JavaScript est déjà en concurrence avec d'autres langages. WebAssembly rend les autres langages plus efficaces, c'est tout.

Au départ, nous avions adopté des technologies qui rendaient notre code JS plus efficace pour s'exécuter sur des machines virtuelles telles que V8 et autres, mais vous pouvez désormais écrire et compiler dans un code assembleur qui peut dépasser le code JS.

Oui, car les machines virtuelles JavaScript ne peuvent

Le fait est donc qu'il est possible que JS soit mis à l'écart ou même supprimé de l'image en faisant abstraction des ponts API et en portant les runtimes sur le navigateur.

Non, les gens continueront à utiliser JavaScript.

Pendant de nombreuses années, sur le bureau, il y a eu de nombreux langages parmi lesquels choisir : Python, Perl, Ruby, PHP, Haskell, JavaScript (Node.js), OCaml, C++, Java, etc.

Les gens utilisent de nombreux langages, y compris JavaScript. JavaScript ne va nulle part.

Même dans un monde hypothétique ( très improbable) où JavaScript n'est pas un langage de première classe, les gens peuvent toujours compiler JavaScript vers WebAssembly.

Vous pouvez maintenant vous attendre à ce que des compilateurs pour le Web remplacent les transpileurs tels que TypeScript, CoffeeScript, etc.

C'est peu probable, il y a encore de bonnes raisons pour que les gens utilisent TypeScript et JavaScript.

Bien sûr, il y aura des alternatives à TypeScript, et certaines personnes utiliseront ces alternatives, mais il est peu probable que TypeScript disparaisse.

Je dis cela parce qu'il existe déjà de bonnes alternatives à TypeScript depuis des années (comme Haxe ) mais elles n'ont jamais remplacé TypeScript.

Le 4 septembre 2017 à 03h42, Pauan [email protected] a écrit :
>

JavaScript est déjà en concurrence avec d'autres langages. WebAssembly fait juste
d'autres langages plus efficaces, c'est tout.

Ce dernier n'est pas tout à fait correct. Un autre objectif de Wasm est d'activer des fonctionnalités
qui ne sont pas pris en charge par JavaScript, et ne le seront potentiellement jamais. Pour
par exemple, la concurrence, les appels de queue ou les exceptions avec reprise sont tous sur le
carte routière.

@rossberg-chromium En effet vous avez raison, j'avais oublié ce détail. Merci de clarifier.

@Pauan Merci pour les détails. Bien que certains de vos points soient valables et logiques, je ne suis pas d'accord avec tout.

C# côté client semble prometteur et un exemple de tueur pour éviter complètement Javascript au stade du développement. c'est-à-dire que je peux utiliser C# pour écrire une application Web entièrement fonctionnelle sans que j'écrive de code Javascript. Ce genre de framework basé sur l'attitude a une chance probable de mettre en sourdine l'héritage Javascript au moins dans une certaine mesure.

Vous pouvez déjà compiler C#, F#, C++, OCaml, Elm, PureScript, Haskell, Java, Python, Ruby, Perl, etc. en JavaScript.

Oui, le Javascript était en image. Mais maintenant, avec WASM/Webasm, mon motif de compilation en Javascript a changé. On peut directement compiler vers wasm et écrire une couche de masque d'API ou des ponts en Javascript chaque fois que nécessaire, de sorte que la base de développeurs n'a pas besoin de connaître Javascript pour développer une application Web avec Webapp, je veux dire une application Web pure et non ASP.net, des frameworks JSP.

Gardez à l'esprit que d'autres langages sont compilés en JavaScript depuis des années et qu'ils continueront à le faire avec ou sans WebAssembly.

Vous pouvez déjà compiler C#, F#, C++, OCaml, Elm, PureScript, Haskell, Java, Python, Ruby, Perl, etc. en JavaScript.

Alors que de nombreux langages peuvent déjà compiler vers JavaScript, la compilation vers Webasm éviterait-elle les pénalités importantes de charge et de performances d'exécution pour le faire ? Et les problèmes de performances si vous compiliez une VM complète en langage C vers Webasm pour le faire de cette façon ?

Si l'utilisation d'autres langages entraîne des problèmes de performances inévitables, ou de nombreux endroits qui violent les spécifications de ces langages (pour des raisons de performances), il s'agit au mieux d'un remplacement partiel de JavaScript et, en général, je les ai vus plus utilisés pour le portage de code hérité que le nouveau code pour "remplacer JavaScript" (à l'exception de CoffeeScript, TypeScript, etc. qui sont conçus pour être correctement compilés en JS).

Ces problèmes peuvent-ils être résolus ? par exemple avec un nouveau compilateur Ruby -> Webasm, et obtenir des performances comparables à celles du navigateur JavaScript actuel ?

Pour utiliser JavaScript et Ruby (avec Opal) comme exemple (comme quelque chose que j'ai essayé et fondamentalement abandonné précédemment):

En JavaScript avec un opérateur + , il permet de convertir les nombres en chaîne, par exemple

5 + " example" === "5 example"

Ruby a un typage beaucoup plus fort, et ce n'est pas autorisé :

5 + " example"
#TypeError: String can't be coerced into Integer

Opal doit donc créer son propre avantage et des méthodes assez complexes pour de nombreux types de noyaux

function $rb_plus(lhs, rhs) {
  return (typeof(lhs) === 'number' && typeof(rhs) === 'number') ? lhs + rhs : lhs['$+'](rhs);
}
String.prototype['$+'] = function (r){var t=this,n=arguments.length;return 1!==n&&e.ac(n,1,this,"+"),r=ke.get("Opal").$coerce_to(r,ke.get("String"),"to_str"),t+r.$to_s()}

De même pour de nombreuses opérations de base.

# Ruby: if a || b
if ((($a = ((($b = a) !== false && $b !== nil && $b != null) ? $b : b)) !== nil && $a != null && (!$a.$$is_boolean || $a == true))) {

Peut-être qu'en théorie, un JIT pourrait optimiser cela complètement, mais ne pensez pas qu'ils sont proches (pas de micro-test de référence, mais pour un prototype d'application/page entier, j'ai fait la version Ruby était nettement plus lente) et des conversions comme celle-ci semblent simplement faire le optimiseurs la vie plus difficile?

Et même dans ce cas, certaines choses sont erronées ou ne sont pas prises en charge (bien que Webasm ait des entiers natifs, c'est donc un début, espérons-le, si vous compilez vers Webasm plutôt que JS):

1 / 2 == 0.5 # Should be 0, Ruby has integer division

str = "Hello"
str << " World" # Opal: String#<< not supported. Mutable String methods are not supported in Opal.
puts str # "Hello World"

@nirus

Je peux utiliser C# pour écrire une application Web entièrement fonctionnelle sans que j'écrive de code Javascript.

Oui, et je suis d'accord, c'est très cool (je travaille sur un langage que je prévois de compiler en WebAssembly), mais mon point est que vous pouvez déjà le faire, même sans WebAssembly.

On peut directement compiler vers wasm et écrire une couche de masque d'API ou des ponts en Javascript chaque fois que nécessaire, de sorte que la base de développeurs n'a pas besoin de connaître Javascript pour développer une application Web avec Webapp, je veux dire une application Web pure et non ASP.net, des frameworks JSP.

En effet, et c'est déjà possible depuis de nombreuses années maintenant. Vous n'avez pas besoin d'attendre WebAssembly, vous pouvez commencer dès maintenant : asm.js existe depuis plusieurs années.

@wnewbery

Alors que de nombreux langages peuvent déjà compiler vers JavaScript, la compilation vers Webasm éviterait-elle les pénalités importantes de charge et de performances d'exécution pour le faire ? Et les problèmes de performances si vous compiliez une VM complète en langage C vers Webasm pour le faire de cette façon ?

Cela peut aider les temps d'analyse, mais il est peu probable que cela améliore les performances d'exécution.

Je précise quelque chose : asm.js existe depuis plusieurs années. Il vous permet de compiler un programme en JavaScript, et ce programme s'exécutera à des vitesses presque natives. En d'autres termes, vous pouvez exécuter un programme à la même vitesse qu'il s'exécute sur le bureau.

Il a donc déjà été possible de prendre un langage, de compiler sa machine virtuelle, son environnement d'exécution et son ramasse-miettes en asm.js, et vous pouvez ensuite exécuter le langage de votre choix dans le navigateur, presque à la même vitesse que sur le bureau. Cela est déjà possible depuis un bon moment maintenant.

Cependant, la compilation de la machine virtuelle, de l'environnement d'exécution et du ramasse-miettes signifie que la taille du fichier sera assez importante (plusieurs mégaoctets).

Et il est difficile de communiquer avec les API JS (comme le DOM).

Mais certaines personnes l'ont quand même fait et ont créé des choses comme

Il s'exécute plus rapidement que CPython (oui, vraiment ! L'interpréteur PyPy qui a été compilé en JavaScript et s'exécute dans un navigateur s'exécute plus rapidement que CPython natif sur le bureau !)

Mais la taille du fichier est assez mauvaise (5 mégaoctets compressés, 15 mégaoctets bruts).

Vous pourriez donc compiler la VM + le ramasse-miettes + le runtime de Ruby en asm.js, et ce serait très rapide, mais cela poserait ces problèmes. Au lieu de cela, les gens créent des choses comme Opal.

WebAssembly est la prochaine évolution d'asm.js. Pour le moment, tout ce que vous pouvez faire avec WebAssembly, vous pouvez également le faire avec asm.js.

Alors oui il est possible de compiler votre langage + VM + runtime + ramasse-miettes en WebAssembly, et il fonctionnera à une vitesse quasi native.

Mais bien sûr, il a les mêmes inconvénients que asm.js : une très grande taille de fichier et il est difficile de communiquer avec les API JS.

Il existe sept différences entre WebAssembly et asm.js :

1. WebAssembly est un peu plus rapide (5%) que asm.js en général.

2. WebAssembly est nettement (~ 400 %) plus rapide que asm.js si vous utilisez des entiers 64 bits.

3. WebAssembly peut être analysé beaucoup plus rapidement. Cela n'améliore pas la vitesse d' exécution de votre programme, mais cela signifie que le temps de chargement initial est plus rapide avec WebAssembly.

4. La taille du fichier WebAssembly est inférieure à la taille du fichier asm.js (environ 10 à 20 % plus petite).

5. WebAssembly pourrait à l'avenir bénéficier de fonctionnalités impressionnantes qu'asm.js n'a pas (threads, concurrence, exceptions à coût zéro, etc.).

6. WebAssembly pourrait à l'avenir accéder au ramasse-miettes de JavaScript (ce qui signifie que vous n'aurez plus besoin de compiler le ramasse-miettes de votre langage vers WebAssembly, ce qui signifie des fichiers de plus petite taille).

7. WebAssembly aura à l'avenir la possibilité d'utiliser facilement les API JS (comme le DOM).

Mais même à l'avenir, il sera toujours nécessaire de compiler le runtime VM + de votre langage dans WebAssembly, donc la taille du fichier sera toujours un problème.

Si la compilation de la VM + runtime + ramasse-miettes de votre langage dans asm.js n'est pas acceptable pour vous, cela ne le sera probablement toujours pas, même avec WebAssembly.

Et si la compilation de la VM + runtime + ramasse-miettes de votre langage est acceptable pour vous, vous pouvez déjà le faire dès maintenant avec asm.js (et ensuite passer facilement à WebAssembly plus tard).

Ces problèmes peuvent-ils être résolus ? par exemple avec un nouveau compilateur Ruby -> Webasm, et obtenir des performances comparables à celles du navigateur JavaScript actuel ?

Le but de WebAssembly est d'exécuter des programmes à des vitesses natives. En d'autres termes, les exécuter à la même vitesse qu'ils s'exécutent sur le bureau.

Donc, si vous compilez Ruby en WebAssembly, il s'exécutera à la même vitesse que Ruby s'exécute sur le bureau.

Ruby est un langage assez lent. Les langages lents et les programmes lents seront toujours lents, même lorsqu'ils sont compilés avec WebAssembly.

1 / 2 == 0.5 # Should be 0, Ruby has integer division

C'est un bogue dans Opal qui peut être corrigé en changeant simplement la définition de la fonction $rb_divide .

str << " World" # Opal: String#<< not supported. Mutable String methods are not supported in Opal.

Cela peut être corrigé en faisant compiler les chaînes Opal dans des tableaux JavaScript (qui sont mutables).

@Pauan

WebAssembly pourrait à l'avenir bénéficier de fonctionnalités impressionnantes qu'asm.js n'a pas (threads, concurrence, exceptions à coût zéro, etc.).

Le thread est une fonctionnalité très importante pour de nombreux langages, bibliothèques, frameworks.Sans thread, de nombreuses applications créées par c++, c#, java qui reposent sur le multithread ne peuvent pas simplement se transformer en webapp car cela peut provoquer un comportement étrange (sans parler d'une autre bonne chose comme SIMD soutenir _dans le futur(?)_). En bref, je pense que asm.js n'est pas assez bon, ni les performances ni la capacité de portage, si c'est aussi bon, il devrait y avoir plus de bibliothèques "portées" sur asm.js il y a longtemps.

comme tout le monde l'a dit, javascript ne disparaîtra pas simplement parce qu'il est si populaire et pour la prise en charge héritée, la plupart des navigateurs prendront toujours en charge l'exécution de javascript en natif, mais je pense qu'à l'avenir, quiconque créera de nouveaux sites Web avec javascript le compilera en wasm pour tous ces gains de performances

@unmellow , pour démystifier à nouveau ce mythe : il n'y aurait pas de gains de performances magiques en compilant JS en Wasm, bien au contraire. Si vous voulez de meilleures performances que celles que les moteurs JS sont capables de fournir, vous devez choisir un meilleur langage.

ouais désolé j'ai oublié je voulais dire que ça serait plus rapide
edit: quelque chose qui pourrait arriver est que le navigateur ne met pas à jour ses moteurs javascript pour prendre en charge
les nouvelles versions de javascript sense pouvaient compiler sur wasm sans aucune perte de performances

Je ne suis pas vraiment à l'aise pour lancer un ticket vieux d'un an, mais, pour le plaisir de la discussion et juste un petit coup de gueule.

Je peux voir que beaucoup de gens sont sceptiques à l'idée de remplacer Javascript par WASM, mais une chose est que WASM n'est pas vraiment une question de performance. Ce que les gens oublient le plus souvent, c'est que Javascript n'est pas le langage qu'ils veulent (ou voulaient). Je veux dire, au moins, le Javascript barebone n'est pas ce que les gens veulent. De plus en plus de gens utilisent des transpileurs, qui sont essentiellement des compilateurs pour des langages tiers. C'est simplement que les gens ont renoncé à se fier aux normes et se sont tournés vers des solutions utilisateur (?).

Mais la transpilation est, par nature, beaucoup plus difficile que la compilation. Le problème mathématique du mappage d'une langue à une autre n'est pas toujours limité à la portée locale. Certaines informations contextuelles doivent être transférées de l'autre côté, et le faire correctement est un problème difficile. C'est pourquoi les transpileurs non-Javascript ne sont pas largement adoptés (ou pourquoi il ne faut pas s'y fier).

En outre, il y a un problème avec les efforts dupliqués. Les transpileurs sont des compilateurs et les bundlers sont des linkers. Nous avons tous ces outils depuis des lustres. Modules, arborescence, fractionnement de code, chargement dynamique/paresseux, gestion des actifs, etc. Rien n'est vraiment nouveau, mais les gens ont besoin de nouveaux outils pour disposer de ces fonctionnalités uniquement pour le Web, ce qui n'est pas convivial pour les solutions non Web.

Ce n'est pas comme si WASM allait tout changer en un jour. Javascript dispose actuellement d'un écosystème bien construit, contrairement aux autres langages. Je vais prendre du temps avant que Javascript n'aille vraiment quelque part, mais cela se produira clairement à long terme.

Javascript se dirige, ce que je considère être, dans une direction terrible, alors je me réjouis d'un remplaçant de WASM. Je pense que bien qu'il y ait eu des améliorations significatives, une grande partie de la communauté et de la direction a été induite en erreur au cours des dernières années. Je serais plus que ravi d'avoir un langage approprié pour... pas nécessairement pour prendre sa place, mais pour être un concurrent direct, donc je n'ai pas eu à écrire cette nouvelle saveur odieuse de JS et ses "frameworks" qui se sont manifestés.

@spencerudnick Jamais écrit d'assembly pour des gains de performances que vous ne pouvez pas obtenir de C ?