Design: Wird es einen JS -> WASM-Compiler geben?

Browser werden neben wasm weiterhin über eine native JavaScript-VM verfügen. Es gibt keinen Grund, JS nach wasm zu kompilieren, da Sie auch eine ganze Javascript-VM einbinden müssten. Der resultierende Code wäre riesig und langsamer als die nativ bereitgestellte JS-VM.

Es gibt einen Task-Post-MVP zum Hinzufügen von Dingen wie dem Hinzufügen des Zugriffs auf den GC über wasm-Code, damit Skriptsprachen für wasm implementiert werden können.

JS → wasm wird erst dann wirklich Sinn machen, wenn wasm GC unterstützt und höchstwahrscheinlich auch die JIT-Kompilierung, was noch eine ganze Weile auf sich warten lässt. Dies wäre im Grunde gleichbedeutend mit der Implementierung der JS-Engine in wasm! Ich habe das kürzlich erwähnt und @BrendanEich hat mir vorgeworfen, von horse_js übernommen worden zu sein.

Um es klar zu sagen, das Ziel von wasm besteht nicht darin, JavaScript zu _ersetzen_, sondern es zu ergänzen. JS → wasm zu unterstützen ist daher derzeit nicht wirklich ein Ziel, aber die Features, die wir implementieren wollen, werden es möglich machen. Ich bin mir jedoch nicht sicher, ob es aus der Perspektive eines Entwicklers so nützlich sein wird. Möglicherweise erhalten Sie eine Größenreduzierung, aber das war es auch schon. Aus Sicht eines Browsers kann es aus reiner Sicherheitssicht interessant sein, die JS-Engine in wasm implementiert zu haben.

@jfbastien Ich habe dich um 2 Sekunden geschlagen ;)

Aber deine Antwort ist besser. Ich freue mich auf GC und JIT in wasm. Ich liebe es, meine eigenen Sprachen zu erstellen und sie im Web zu betreiben.

Und wie sieht es mit der Unterstützung von Varianten wie asm.js oder TypeScript/ES7 aus? Diese
Varianten von Javascript versprechen ein gewisses Maß an Typgarantien.

Ich könnte mir vorstellen, dass JIT weniger benötigt wird, aber GC immer noch sehr stark
für diese Sprachen benötigt. Hätte ein {typed Flavor JS} -> WASM machen
ist das noch machbar?

W: http://bguiz.com

Am 24. Juni 2015 um 09:44 Uhr schrieb Tim Caswell [email protected] :

@jfbastien https://github.com/jfbastien du hast mich um 2 Sekunden geschlagen :P

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/WebAssembly/design/issues/219#issuecomment -114675456.

Ja, ein asm.js -> wasm-Übersetzer hat hohe Priorität, und Luke hat es bereits getan
Arbeit an einem Kompressor, der als guter Ausgangspunkt dienen könnte.

Am Mittwoch, 24. Juni 2015 um 01:59 Uhr, Brendan Graetz [email protected]
schrieb:

Und wie sieht es mit der Unterstützung von Varianten wie asm.js oder TypeScript/ES7 aus? Diese
Varianten von Javascript versprechen ein gewisses Maß an Typgarantien.

Ich könnte mir vorstellen, dass JIT weniger benötigt wird, aber GC immer noch sehr stark
für diese Sprachen benötigt. Hätte ein {typed Flavor JS} -> WASM machen
ist das noch machbar?

W: http://bguiz.com

Am 24. Juni 2015 um 09:44 Uhr schrieb Tim Caswell [email protected] :

@jfbastien https://github.com/jfbastien du hast mich um 2 Sekunden geschlagen :P

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
< https://github.com/WebAssembly/design/issues/219#issuecomment -114675456
.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/WebAssembly/design/issues/219#issuecomment -114677789.

Wir haben mit dem TypeScript-Team über diese Möglichkeit gesprochen und sie haben Interesse gezeigt, aber es scheint, als ob es derzeit Fortschritte beim Hinzufügen typisierter Objekte zu JS gibt.

@bguiz : Die JS-Engine ist die Wasm-Engine und wird weiterhin die sich entwickelnde JS-Standardsprache unterstützen. Keine Sorge (ich war mir nicht sicher, ob Sie dachten, das könnte weggehen. Nicht in irgendeiner Zukunft, die ich vorhersehen kann). OTOH wie andere anmerken, braucht wasm Zeit, um GC, JIT-Unterstützung und andere dynamische Sprachfunktionen zu entwickeln, um ein erstklassiges Ziel für JS zu sein. Selbst wenn es diese Dinge weiterentwickelt, bezweifle ich, dass JS/wasm-Engines ihre JS-Syntax und -Integrationen zugunsten heruntergeladener JS-in-wasm-VMs fallen lassen werden. Wir werden sehen!

/Sein

Wir planen auch , Emscripten um einen asm.js-to-WebAssembly-Übersetzer hinzuzufügen.

Was normales JS betrifft, so haben andere meiner Meinung nach die obige Frage beantwortet.

Der ganze Sinn von JS ist einfach zu codieren und kann erstaunliche Dinge tun: dhteumeuleu oder codepen.io/ge1doot, aber Sie können die Quelle sehen und es ist leicht zu hacken.

"wasm" ist nur eine Möglichkeit mehr Spiele und andere Apps für Google, Apple und Co zu verkaufen. Die einzige "Evolution" ist, dass Sie mit "no install" direkt vom Server des großen Bruders aus besser gesteuert werden können ... Ich bin nur überrascht, dass sie sich noch nicht fürchten, sich gegenseitig zu fressen ...

Mit Codeanalyse oder Codeannotationen ist es möglich, ECMAScript zu WebAssembly zu kompilieren. Das hört sich für das WebAssembly-Team nicht nach Priorität an, aber es klingt nach einer großartigen Idee für einen unabhängigen Versuch.

Ich habe gerade angefangen, mit einer Spielzeug-Programmiersprache zu experimentieren, die relevant sein könnte: https://github.com/evanw/thinscript. Es verwendet eine Syntax im TypeScript-Stil und wird zu WebAssembly kompiliert. Ich dachte, ich sollte es erwähnen, weil es eine interessante Fallstudie sein könnte. Außerdem war ich angenehm überrascht, wie einfach WebAssembly zu generieren war. Schöne Arbeit an alle!

Ich würde die Leute jedoch davor warnen, im Allgemeinen sehr dünne Wrapper auf dem Wasm zu verwenden. Als ein Beispiel, wenn ich den Thinscript-Code durchblättere, sehe ich, dass es eine while Anweisung gibt, die auf loop { if (!condition) break; } abgesenkt wird, was if (condition) loop { ...; br_if condition } mehreren Wasm-Engines weniger effizient ist als

Für mich ist das, was wasm zu mehr als nur einem aufgeheizten JS macht, die Möglichkeit einer anderen Philosophie: Da wasm ein Compilerziel ist, können Compiler Optimierungen durchführen, bevor sie den Code an Clients senden, sodass wir clientseitige VMs einfacher halten können und Schneller. Wenn jedoch dünne Wrapper um wasm populär werden, besteht die Gefahr, dass clientseitige Implementierungen schließlich umfangreicher und komplexer werden müssen, um die Optimierungen durchzuführen, die nicht durchgeführt werden.

Ja, ich stimme zu. Eines der Dinge, die ich an WebAssembly am meisten mag, ist seine Einfachheit. Ich plane, Compiler-Optimierungen hinzuzufügen und Benchmarks durchzuführen, sobald die Sprache vollständiger ist. Ich erwarte zum Beispiel, dass Inlining einer der größeren Gewinne ist, und ich würde nicht erwarten, dass WebAssembly das für mich tut. Ich plane auch, mit einem Maschinencode-Ziel zu experimentieren, und ich werde die gleichen Optimierungen für beide Ziele verwenden.

Klingt sehr cool! Mich würde interessieren, wohin das führt.

Ich stelle mir vor, dass JS->WASM für Server attraktiver ist als für Clients. Als sehr grober Überblick über die Architektur, die ich im Sinn habe...

JavaScript -> WebAssembly -> Tracing Interpreter -> LLVM IR -> Machine Code

Bei dieser Konzeption wäre eine klare Zuordnung von WASM zu LLVM IR für die Garbage Collection sehr wünschenswert. Die Beförderung von IEEE-Doubles zu Integers könnte als LLVM-Pass erfolgen. Das Konzept getrennter JITs für warmen und heißen Code könnte in Form von LLVM-Passmanagern implementiert werden.

Nur ein paar Gedanken, bitte löschen Sie dies, wenn es falsch ist!

Cross-Environment-Kompatibilität ist ein ernstes Problem im JS-Ökosystem. Babel versucht, dieses Problem zu lösen, indem es auf eine weitere übernommene Version von ES umsteigt, und ich denke, wir können alle sagen, dass es ziemlich erfolgreich ist.

Hier gibt es aber immer noch ein Problem. Wenn Sie beispielsweise Ihren ES 2016-Code aus Kompatibilitätsgründen auf ES5 transpilieren und Ihr Code in einer Umgebung mit (teilweiser oder vollständiger) ES 2016-Unterstützung ausgeführt wird, verpassen Sie die Vorteile der ES 2016-Unterstützung in Ihrer Umgebung .

Wenn jeder seinen Code auf ES5 transpiliert, was ist dann der Vorteil der ES 2016-Unterstützung in einer Umgebung überhaupt?

Ein neues Projekt namens "babel-preset-env" versucht, dieses Problem zu bekämpfen, indem es Umgebungen nach ihren Versionen anvisiert. Die Idee dahinter ist, dass (1) Sie es auffordern, bestimmte Versionen oder "neueste X-Versionen" von Browsern anzusprechen, (2) es den kleinsten gemeinsamen Nenner von Funktionen bestimmt und (3) nur notwendige Transpilationen ermöglicht. Das hilft, kann das Problem aber leider nicht lösen.

Wir haben immer noch das Risiko, dass sich ein großer Anbieter nicht verhält und die gleichen Probleme verursacht, die Microsoft seit Jahren mit dem Internet Explorer verursacht hat. Das gesamte Ökosystem liegt in den Händen einiger weniger Anbieter, die entscheiden, was und wann implementiert werden soll. Dies ist weder kostenlos noch offen.

Die einzige Lösung ist ein neues Kompilierungsziel für JavaScript, das performant ist und viel weniger Wartung (hoffentlich keine) benötigt als eine JS-Engine. Wenn Umgebungen (Browser, Node.js usw.) beginnen, ein solches Ziel zu unterstützen, sollte die Implementierung neuer ES-Funktionen in die Verantwortung der Compiler und nicht der Engine-Hersteller fallen.

JS -> WASM wäre interessant, um geistiges Eigentum durch Code-Verschleierung zu schützen, wenn es um On-Premise-Installationen von beispielsweise Electron-Apps auf Kundenservern geht. Es ist kaum zu glauben, aber wahr, es gibt viele kleine Institutionen in Deutschland mit sehr wenig oder gar keiner Internetverbindung, was Installationen vor Ort erfordert, aber Ihren gesamten Code im Klartext zu geben, kann für Softwareunternehmen beängstigend sein.

@Simran-B Wasm hat als Designprinzip die Unterstützung eines vertrauten Textformats. Insbesondere verfügt es über ein strukturiertes Kontrollflussdesign für eine schnelle Analyse und ist für Single-Use-Definitionen optimiert, die in Stapelreihenfolge verwendet werden, also für lesbare Ausdrücke optimiert. Es handelt sich also nicht um ein Ziel der „Code-Verschleierung“, aber Entwickler können darüber hinaus ihre eigene „Code-Verschleierung“ ausgeben, sollten sich jedoch bewusst sein, dass dies voraussichtlich mit Kosten in Form einer verringerten Codierungseffizienz und einer verringerten Leistung verbunden ist.

Hallo zusammen, ich habe WebAssembly gerade erst kürzlich entdeckt, aber wenn ich an den JS -> wasm-Compiler dachte, stellte ich mir so etwas wie die Ahead-of-Time-Kompilierung von Angular2 vor, nur viel optimierter (ich denke an Maschinencode anstelle von Javascript) ... Wird das jemals möglich sein? Lohnt es sich?

BEARBEITEN
Ich denke auch, wird es jemals eine Möglichkeit für den Browser geben, ein Flag an den Client zu senden, dass er wasm unterstützt, und dann können wir eine vorkompilierte App anstelle einer Javascript-Datei bereitstellen?

Richard

@ Richard87 Sie können sich Webassembly als einen plattformunabhängigen Befehlssatz mit eigenen spezialisierten Codierungs- und Aufrufkonventionen vorstellen. Es gibt nichts, was sagt, dass Sie nicht eine Teilmenge von Javascript beschreiben können, die sehr einfach zu transpilieren wäre, um in der Welt der Webassembly zu funktionieren, aber dies durchzusetzen wäre wahrscheinlich schwierig. Der Funktionsumfang und die Implementierungsfläche in Javascript wachsen ständig, und die Anpassung vorhandener Bibliotheken und Frameworks an diese Untermenge wäre wahrscheinlich schwierig, insbesondere angesichts des derzeitigen Mangels an Garbage Collection in der Webassembly, und Sie würden im Wesentlichen die Vorteile von vorhandenem Javascript verlieren Code.

Mit dem Hinzufügen von Garbage-Collection-Primitiven in der Webassembly würde sich die Teilmenge von Javascript, die ohne das Schreiben einer großen alten virtuellen Maschine transpiliert werden könnte, erweitern, aber meiner Meinung nach wäre es immer noch nicht optimal, verglichen mit dem bloßen Transpilieren von einer geeigneteren Sprache, da Ihr Aufwand für Javascript nur unwesentlich geringer wäre, würde der wichtige Aufwand für Webanwendungen (das Netzwerk!) Abgesehen davon, dass es etwas verwendet, das "Javascript" ähnelt (dies ist eigentlich ein ähnliches Boot, in dem Unity mit UnityScript ist, außer dass sie es etwas angepasst haben, um sich besser in ihre Subsysteme und Aufrufkonventionen im Allgemeinen zu integrieren, neben anderen Launen).

Ich denke, es ist für einige von uns, die sich mit Browser und Webgl beschäftigen, extrem wichtig, beim Spielen schneller zu sein. Ich beabsichtige, ein kommerzielles Qualitätsspiel in webgl zu bringen, aber die aktuelle Technologie produziert so viel Müll, dass Frames überspringen.
Browser-Gaming mit JS-Game-Engines ist fast gescheitert und Unity hebt ab. Ich denke, C++ => Wasm ist ein unangemessener Vorteil für diese großen Unity-ähnlichen Framework-Hersteller, die ihren Code nach WASM kompilieren könnten.
Aber was ist mit Leuten, die JS von Hand mit Three JS oder Babylon schreiben.. Keine JS/Asm.js => Wasm-Toolchain zu haben, würde bedeuten, dass große Anwendungen in Js tot wären und die Leute C++ und Codegenerierungs-Backends verwenden würden, um Wasm zu produzieren. Genauer gesagt in Spielen und so.
Kein JS => Wasm-Backend zu haben, unfair gegenüber JS-Entwicklern. EMCC weist auch einen großen Heap zu, wenn es ausgeführt wird, und die Geschwindigkeiten sind daher offensichtlich, aber Js-Entwickler, die guten js-Code schreiben, konnten aufgrund der Komplexität des Schreibens eines solchen Codes immer noch nicht so viel Leistung erzielen. Es sollte einen Mechanismus geben, um die meisten Dinge wiederzuverwenden, und die Möglichkeit, gc früher oder nach Belieben aufzurufen. Das Überspringen von Frames, wenn der GC ausgeführt wird, führt dazu, dass Webgl Frames überspringt, ist ein großes Problem und muss behoben werden. Es sollte einen Mechanismus geben, um JS-Code besser von Hand abzustimmen als Code-Generatoren. wie handgeschriebene Assembly produziert immer noch viel kleineren und hochgradig ausgerichteten Code. Das sollte im Web-Assembly möglich sein.

@metacritical C++ kann in WASM kompilieren, weil viele Leute viel Arbeit in den Prozess stecken. Das gleiche könnte für JavaScript passieren, aber soweit ich weiß, versucht das derzeit niemand. Dafür gibt es wenig Grund: Die Leistung wird unverändert bleiben.

Das Problem Ihrer Engine ist die Garbage Collection. Dieses Problem verschwindet nicht, wenn Sie einen Garbage-Collection-Algorithmus erstellen, der linearen Speicher und WASM-Code verwendet... schließlich müssen Sie das Programm stoppen, um zu sehen, welche Objekte noch am Leben sind, und diejenigen löschen, die es nicht sind. Die Lösung besteht darin, keine Garbage-Objekte zu erstellen, um zu verhindern, dass der GC jemals ausgeführt werden muss. Um dies zu erreichen, brauchen Sie kein WASM, Sie müssen Ihren Motor überarbeiten.

Ultra-reines Javascript, das Arrays wiederverwendet und wenig Müll produziert, ist extrem schwer zu schreiben. Ich denke auch, dass Plain Js nicht in WASM kompiliert werden kann. Asm.js oder Typescript wären aufgrund der Verfügbarkeit von Typannotationen bzw. Typen darin einfacher in WASM zu kompilieren.

@metakritisch Schwierig, aber nicht unmöglich. Selbst in den C++-Engines dreht sich ein Großteil des Codes um die Verwaltung der Objektlebensdauer. Obwohl unkonventionell, gibt es keinen Grund, warum Sie dasselbe in JavaScript nicht tun können.

Plain JS _könnte_ in WASM kompiliert werden, aber der Compiler müsste eine Menge Hilfscode hinzufügen, um die höheren Funktionen von JavaScript wie Garbage Collection, Reflektion, Eigenschaften usw. zu aktivieren. Im Grunde alles, was Sie mit der integrierten JS-Engine des Browsers kostenlos erhalten. TypeScript hilft nicht viel.

Im Vergleich dazu wäre ASM.JS einfach in WASM zu konvertieren. Die strikte Teilmenge der von ASM.JS erlaubten JS-Features wird auch von WASM zu 100 % abgedeckt. Wenn eine große Menge Code in ASM.JS geschrieben wäre, wäre dies ein lohnender Aufwand, aber soweit ich weiß, werden alle wichtigen ASM.JS-Dateien aus C++-Quellcode erzeugt, der bereits direkt auf WASM abzielen kann.

Im Vergleich dazu wäre ASM.JS einfach in WASM zu konvertieren.

Richtig, und eigentlich kompilieren wir C++ heute hauptsächlich in wasm, indem Asm2wasm von Binaryen in wasm kompilieren .

@kripken Wenn man sich die asm.js-Spezifikationen

Wäre die Weiterentwicklung von JS, dh einer streng typisierten Sprache, nicht ein guter Kandidat für JS -> WASM?
Ich denke, TC39 hat einen Vorschlag für ein getipptes Objekt. Vielleicht könnten mehr andere Features es möglich machen.

@aruns07 Je weniger JavaScript-Funktionen Sie den

@Kardax @aruns07 Die Leute lieben den Komfort einer dynamischen Sprache. Starke Typen brauchen wir manchmal nicht immer.

jfbastien hat am 24.06.2015 . kommentiert
JS → wasm wird erst dann wirklich Sinn machen, wenn wasm GC unterstützt und höchstwahrscheinlich auch die JIT-Kompilierung, was noch eine ganze Weile auf sich warten lässt. Dies wäre im Grunde gleichbedeutend mit der Implementierung der JS-Engine in wasm!

Laut folgendem Link:
https://lists.w3.org/Archives/Public/public-webassembly/2017Feb/0002.html
WebAssembly-Konsens und Ende der Browservorschau

Jetzt, 2 Jahre nach Ihrer ersten Antwort, wird WebAssembly heute von den wichtigsten Webbrowsern unterstützt.
Es ist also nicht gleichbedeutend mit der Implementierung der JS-Engine in wasm.
Die Vorteile von js -> wasm sind nicht nur die GC-Unterstützung, sondern auch die kleinere Codegröße und die schnellere Ausführung, insbesondere im Bereich der Hybridanwendungsentwicklung wie Ionic2, das normalerweise eine JS-Datei mit etwa 10 MB erzeugt, die die Ladezeit der Anwendung über 5 . erhöht Sekunden (jeder 2MB-Parse von JS = 1 Sekunde)

@jfbastien Also

Im Rahmen meiner Masterarbeit versuche ich einen Transpiler aus einer Teilmenge von JavaScript nach WebAssembly zu schreiben. Zunächst wird es auf TypeScript beschränkt sein, aber andere typisierte Varianten wie Flow könnten in Zukunft unterstützt werden.

Das Ziel besteht jedoch nicht darin, die vollständige JavaScript-Sprache zu implementieren, da ich in diesem Fall mit den gleichen Problemen konfrontiert wäre, mit denen die JIT-Implementierungen heute konfrontiert sind, und daher ist keine Beschleunigung zu erwarten (sicherer wäre meine Implementierung 100-mal langsamer! ). Es wird eine Untermenge sein, wie sie von SoundScript definiert wurde

Mein Ziel ist es vielmehr, bestimmte Teile einer Anwendung zu WebAssembly kompilieren zu lassen, ohne dass der Entwickler seine gewohnte Entwicklungsumgebung verlassen oder eine andere Programmiersprache verwenden muss. Daher ist es eher dazu gedacht, leistungskritische Teile einer Anwendung zu beschleunigen und nicht als Allzweck-Transpiler, der jede vorhandene JavaScript-Anwendung akzeptiert.

Ich bin ziemlich gespannt, was meine Ergebnisse sein werden, da ich die Vor- und Nachteile eines solchen Ansatzes sehe. Lassen Sie es mich wissen, wenn Sie Eingaben haben.

@Mohsen7s meine Antwort bleibt korrekt: Die MVP-Version von WebAssembly unterstützt keine

Dies ist inhärent mit unserem "Minimal Viable Product"-Ansatz: Liefern Sie zuerst etwas, das für einige Anwendungsfälle funktioniert, und fügen Sie dann Funktionen hinzu, um andere Anwendungsfälle zu erfüllen. Eine ähnliche Diskussion zu MVP und fehlenden "zukünftigen Funktionen" finden Sie im folgenden Thread: https://github.com/WebAssembly/design/issues/992#issuecomment -281735235

Abgesehen von technischen Diskussionen darüber, was derzeit umgesetzt werden kann und was nicht, bin ich erstaunt, dass JS -> WASM sowohl philosophisch als auch aus Marketingsicht nicht das Ziel Nummer 1 ist - ich sehe nicht, wie Sie jemals kommen werden Entwickler-Buy-in, bis dies der Fall ist. Wenn all diese Front-/Back-End-/Full-Stack-Entwickler mit JS-Kenntnissen, die in jeder Branche arbeiten können, stattdessen ihre Zeit damit verbringen wollten, C++ zu lernen, das in einer wesentlich kleineren Teilmenge von Branchen verwendet wird, hätten sie es bereits getan also - ich weiß, ich spreche als eins. Ich kann nicht anders, als das Gefühl zu haben, dass diese ganze Diskussion eine Art Echokammer ist und dass diejenigen, die das Fehlen eines Compilers verteidigen, ihre Zeit besser damit verbringen sollten, mit Leuten auf der Kohlenfront zu sprechen und sie zu fragen, was sie wirklich wollen.

@BossLevel

Abgesehen von technischen Diskussionen darüber, was derzeit umgesetzt werden kann und was nicht, bin ich erstaunt, dass JS -> WASM sowohl philosophisch als auch aus Marketingsicht nicht das Ziel Nummer 1 ist - ich sehe nicht, wie Sie jemals kommen werden Entwickler-Buy-in, bis dies der Fall ist. Wenn all diese Front-/Back-End-/Full-Stack-Entwickler mit JS-Kenntnissen, die in jeder Branche arbeiten können, stattdessen ihre Zeit damit verbringen wollten, C++ zu lernen, das in einer wesentlich kleineren Teilmenge von Branchen verwendet wird, hätten sie es bereits getan also - ich weiß, ich spreche als eins.

Browser können JavaScript bereits effizient ausführen. Browser können die beabsichtigten Anwendungsfälle nicht so effizient ausführen. Um das Ganze abzurunden, hat WebAssembly Nicht-Web-Aspirationen.

Diese Diskussion sowie https://github.com/WebAssembly/design/issues/992#issuecomment -281735235 veranschaulichen die Vielfalt der Ziele, die verschiedene Menschen haben. Keiner ist falsch! MVP muss einfach priorisieren, wer zuerst bedient wird.

Ich kann nicht anders, als das Gefühl zu haben, dass diese ganze Diskussion eine Art Echokammer ist und dass diejenigen, die das Fehlen eines Compilers verteidigen, ihre Zeit besser damit verbringen sollten, mit Leuten auf der Kohlenfront zu sprechen und sie zu fragen, was sie wirklich wollen.

Das war der springende Punkt bei der Bildung einer W3C-Community-Gruppe. Wir denken, dass es gelungen ist, wie wir von vielen interessierten Entwicklern gehört haben. Einige sind nicht an MVP interessiert, aber an zukünftigen Funktionen .

@jfbastien

Browser können JavaScript bereits effizient ausführen.

Ha, ich versuche seit 2008, ein Massively Multiplayer HTML5-Spiel zu schreiben, das auf einem durchschnittlichen Mobiltelefon mit anständigen FPS laufen kann, und ich bin immer noch nicht am Ziel! Und da ich sehr gut belohnt werde, wenn ich einen Vertrag abschließe, um die Rechnungen zu bezahlen, bin ich mir ziemlich sicher, dass mein mangelnder Fortschritt nicht auf die Qualität meines Codes zurückzuführen ist.

Das war der springende Punkt bei der Bildung einer W3C-Community-Gruppe

Ha noch einmal - wie viele reale Entwickler kennen Sie, die einer Community-Gruppe beitreten? Die Entwickler, die das tun, sind in der Regel Evangelisten usw.

Und es tut mir leid, ich möchte wirklich niemanden auf dieser Seite/Beteiligten/am W3C herabsetzen. Wie Sie sagen, ist dies eine Diskussion, und das ist mein Standpunkt von vorn.

Entschuldigung, dass ich darauf zurückkomme wie ein Hund, der sich um einen Knochen Sorgen macht, aber während meiner Abwesenheit dachte ich an eine bessere Möglichkeit, meinen Standpunkt zu vertreten. Stellen Sie in Ihrem nächsten Newsletter/Community-Event oder in welcher Form auch immer Sie Feedback einholen, diese Frage an Webentwickler (Ihre Kunden):

Um die browserbasierte Leistung auf die nächste Stufe zu heben, müssen Sie eine andere Sprache lernen. wäre das akzeptabel?

Denn das ist im Grunde die Frage, die schon (meiner Meinung nach schädlich) von einigen auf dieser Seite beantwortet wurde.

Und schließlich (versprochen ;-) ) @jfbastien , wenn:

Um das Ganze abzurunden, hat WebAssembly Nicht-Web-Aspirationen.

Warum heißt es "WebAssembly"?

@BossLevel Ich glaube, ich

Ha, ich versuche seit 2008, ein Massively Multiplayer HTML5-Spiel zu schreiben, das auf einem durchschnittlichen Mobiltelefon mit anständigen FPS laufen kann, und ich bin immer noch nicht am Ziel! Und da ich sehr gut belohnt werde, wenn ich einen Vertrag abschließe, um die Rechnungen zu bezahlen, bin ich mir ziemlich sicher, dass mein mangelnder Fortschritt nicht auf die Qualität meines Codes zurückzuführen ist.

Ich wollte nicht sagen, dass das Schreiben von schnellem JavaScript einfach ist. Was ich sagen wollte ist: WebAssembly macht die Optimierung von JavaScript nicht einfacher. Es ermöglicht Browsern vielmehr, ein Format zu verwenden, das besser geeignet ist, eine zuverlässige Leistung zu erzielen. Es ermöglicht TC39 auch, sich auf die Verbesserung von JavaScript selbst zu konzentrieren, nicht nur JavaScript als Kompilierungsziel.

Ha noch einmal - wie viele reale Entwickler kennen Sie, die einer Community-Gruppe beitreten? Die Entwickler, die das tun, sind in der Regel Evangelisten usw.

Und es tut mir leid, ich möchte wirklich niemanden auf dieser Seite/Beteiligten/am W3C herabsetzen. Wie Sie sagen, ist dies eine Diskussion, und das ist mein Standpunkt von vorn.

Ihr Standpunkt ist in der Tat gültig, und ich denke, es ist klar, dass ich von Ihrer Position aus etwas sage, das kaum zu glauben ist. Wir sollten das besser kommunizieren (oder hey, vielleicht irre ich mich :wink:).

Um die browserbasierte Leistung auf die nächste Stufe zu heben, müssen Sie eine andere Sprache lernen. wäre das akzeptabel?

Denn das ist im Grunde die Frage, die schon (meiner Meinung nach schädlich) von einigen auf dieser Seite beantwortet wurde.

Ich verstehe Ihre Besorgnis, aber ich hoffe, es ist keine, die sich als wahr herausstellen wird. Auch hier kann ich falsch liegen. Aus meiner Sicht bringt WebAssembly neue Entwickler auf diese Plattform, Entwickler, die in der Vergangenheit schlechte Erfahrungen mit dem Web gemacht oder Horrorgeschichten gehört haben. Im Gegenzug hilft es JavaScript-Entwicklern, die "herkömmlichen" Code verwenden möchten (manche nennen es "Legacy"), diesen Code zu verwenden: Wir möchten, dass WebAssembly von JavaScript aus leicht zu verwenden ist. Um dies zu erreichen, muss es so einfach sein wie die Verwendung von npm (was... nicht immer einfach ist!).

Ich bin ziemlich zuversichtlich, dass sich dies aufgrund des Feedbacks herausstellen wird, das wir auf Twitter, Hacker News, Reddit und verschiedenen Konferenzen erhalten haben. Auch hier liege ich vielleicht falsch und höre Echokammern. Zumindest hatte ich auf Konferenzen vielversprechende Diskussionen mit Leuten mit C++- und JavaScript-Hintergrund.

Gleichzeitig versucht TC39 wirklich, JavaScript zu verbessern. Ich glaube, das hat es in den letzten Jahren vor allem mit ES6 gegeben.

Aber Ihr Punkt bleibt: Vielleicht möchten Entwickler sowohl mit JavaScript als auch mit "WebAssembly-freundlichen" Sprachen wie C++ oder Rust vertraut sein. Ich weiß nicht, in welche Richtung die Dinge gehen werden.

Warum heißt es "WebAssembly"?

Ha! Das ist eine wunderbare Frage. Ich habe einen Vortrag mit dem Titel "WebAssembly: Weder Web noch Assembly". Ich muss es öffentlich machen, damit ich ausdrücken kann, was ich von dem Namen halte :grin:

Also werde ich dich daran hängen lassen.

Ich lese hier zwei Wünsche:

1. Eine binäre Darstellung von Standard-JavaScript für schnelle Ladezeiten.
2. Etwas, um die Leistungslücke zwischen nativ kompiliertem C++ und Standard-JavaScript zu schließen.

Punkt 2 ist Gegenstand laufender Forschung und massiver Investitionen vieler Unternehmen. Wenn Sie sich die Leistungsmessungen von JavaScript-Engines in den letzten 15 Jahren ansehen, funktioniert es auch ... die Lücke wird kleiner.

Punkt 1 wird meines Wissens von niemandem bearbeitet. Es ist enorm kompliziert und wird immer schwieriger, da JavaScript sich in rasantem Tempo weiterentwickelt. WebAssembly ist sehr streng und relativ unkompliziert, und die Entwicklung hat noch Jahre gedauert.

@jfbastien - vielen Dank für deine überlegte und

Also ein paar veranschaulichende Punkte, in keiner bestimmten Reihenfolge:

1) Ein gutes Beispiel für diese gesamte Diskussion und meine Sicht auf die Richtung, die Sie einschlagen sollten, liegt bei NodeJS - einer JS-API / einem Front-End zu einem C++-Back-End - Sie erhalten die Benutzerfreundlichkeit / Vertrautheit usw einerseits und die Geschwindigkeit andererseits.
2) Ich bleibe bei Node, damals im Jahr 2008, als ich mich auf meine persönliche Odyssee begab ;-) Ich habe mir ursprünglich sowohl PHP als auch Java für das Backend angesehen (ich kam nach einem Jahrzehnt auf der dunklen Seite des IT-Managements wieder in die Entwicklung zurück und Verkauf ;-) !) aber schnell rabattiert aus dem einfachen Grund, dass ich nur eine Sprache lernen wollte, und zwar gut! Eine persönliche Geschichte, die ich kenne, aber ich bezweifle, dass ich der einzige Entwickler bin, der so denkt, insbesondere diejenigen, die für sich selbst arbeiten und nicht für einen Firmengroschen, während sie die Sprache lernen.
3) Ich habe die Zahlen absichtlich nicht gegoogelt, bevor ich meinen nächsten Punkt vortrage (ich bin mir sogar nicht sicher, ob ich es überhaupt könnte), aber ich bin bereit zu wetten, dass die ASM-Inanspruchnahme gering war. Ich weiß, dass ich sehr aufgeregt war, als ich die erste Demo sah, aber als ich erfuhr, dass es keinen Compiler gab, verwarf ich sie sofort. Einen Webentwickler zu bitten, der Teil der größten Entwickler-Community der Welt (JS) mit einer Vielzahl von APIs, Bibliotheken, Ressourcen, Tutorials, Frameworks usw indem Sie ihnen keine Mittel zur Verfügung stellen, um möglicherweise diesen ersten Schritt zu machen (zB einen Compiler), übersehen Sie einen offensichtlichen Trick Ihrerseits. Ich würde sogar so weit gehen zu wetten, dass die Entwicklung in Shading Sprache (GLSL) mehr Wachstum verzeichnet hat als ASM, jetzt, da Sie a) es direkt in ausgezeichnete Frameworks wie Pixi.js und Three.js schreiben und b) damit spielen können direkt auf Seiten wie ShaderToy .
4) Die Spieleindustrie/Spiele im Allgemeinen. Ich kann hier aus Erfahrung sprechen, da ich a) seit 9 Jahren (noch unveröffentlichte!) Spiele schreibe und b) 2 Jahre im Vorstand von TIGA (dem Handelsverband der britischen Spieleentwickler) gedient habe. Vertrauen Sie mir, ich denke, die Anzahl der Spieleentwickler, die ins Web migrieren wollten, könnte wahrscheinlich an einer Hand abgezählt werden - Spieleentwickler sind bereits in der Branche tätig, die sie lieben, und haben trotzdem einen Lohneinbußen / lange Arbeitszeiten, also diese sollte nicht die Zielgruppe von WA sein. Ja, ihre Arbeitgeber sind immer auf der Suche nach neuen Medien, auf die sie ihre Spiele portieren können, aber machen wir uns nichts vor, abgesehen von Mobilgeräten (wo nativer Code leider die Nase vorn hat und was ich von WASM beheben möchte), ist das Web immer noch sehr beliebt schlechtes Verhältnis zu PC/Konsole sowohl in Bezug auf Leistung als auch Monetarisierung.
5) Umgekehrt, während die Schlafzimmer-Coder/Indie-Szene nicht auf dem Höhepunkt ist wie vor ein paar Jahren, gibt es eine große Anzahl von Webentwicklern, die Lust haben, in ihrer Freizeit ein Webspiel zu entwickeln. Und obwohl ich nicht offen in die Politik abbiegen möchte und ich die Unity-Leute in keiner Weise klopfe (ich habe mit einigen von ihnen zu tun gehabt und es ist ein großartiges Produkt), denke ich persönlich, dass Sie sich um die Interessen kümmern sollten der vielen kleinen Kerle, nicht des einen großen Kerls (es macht sowohl philosophisch als auch kommerziell Sinn).

Ich freue mich sehr auf deinen Vortrag @jfbastien :)

@RyanLamansky - Ich denke, Sie machen einen vernünftigen Unterschied. In Gedenken an:

Punkt 1 wird meines Wissens von niemandem bearbeitet. Es ist enorm kompliziert und wird immer schwieriger, da JavaScript sich in rasantem Tempo weiterentwickelt.

Auf einer ganz persönlichen Ebene, als jemand, der seit 2008 8 Stunden am Tag an JS schreibt, würde ich sehr gerne sehen, wie die Entwicklung von JS für eine Weile aufhört und alle anderen aufholen lassen! Ich habe immer nach dem Prinzip gearbeitet, für den kleinsten gemeinsamen Nenner zu entwickeln, dh wenn es keine 100%ige Unterstützung hat, passiert es nicht (IE6/7/8/9 beiseite ;-) ). Und so befinden wir uns in der lächerlichen Position, uns auf trendige ES6-Muster und vermeintliche Anwendungsfälle zu konzentrieren, wenn wir nicht einmal 100% Browser-Unterstützung für ES5 auf Desktops und Mobilgeräten haben. Die Sprache funktioniert eindeutig so, wie sie ist (trotz zugegebener Schwächen), wie ihr Marktanteil zeigt. Wie wäre es also, wenn wir als Entwicklergemeinschaft die nächsten Jahre damit verbringen, effizienten, optimalen Code mit dem zu schreiben, was wir haben, anstatt noch einmal das Rad mit neuem Hipster-Code neu erfinden (sorry, ich begebe mich auf schimpfendes Territorium ;-) )?

Ich denke, es ist wahrscheinlich an der Zeit, dass ich meinen Mantel bekomme ;-)

@RyanLamansky Ich habe den Eindruck gewonnen, dass WebAssembly nur ein neues Ziel für Ihren Bundle-Build-Prozess ist und plötzlich alles schneller geht. Das ist offensichtlich nicht der Fall. WebAssembly hat einen sehr spezifischen Anwendungsfall und wird dem typischen Webentwickler mit einer großen JS-Codebasis voller Geschäftslogik wahrscheinlich nicht viel zu bieten haben.

Wie Sie jedoch feststellen, gibt es einige Lücken im JS-basierten Entwicklungslebenszyklus für typischere geschäftsorientierte Webanwendungen:
1) Große JS-Bundles haben einen erheblichen Parsing-Overhead und bieten in der Regel eine unzureichende Verschleierung.
2) Im Standard-JS-Code fehlen die Typanmerkungen (und möglicherweise andere Hinweise), die erforderlich sind, um JIT-/Native-Code-Optimierungen vorzunehmen.

Dies deutet darauf hin, dass eine mögliche Lösung eine richtig typisierte und kommentierte Version von JS ist, die dem Entwickler deterministischere und transparentere Optimierungspfade bietet, und eine vorab geparste Binärversion dieser Version der Sprache.

Die Kommentare und die Dokumente sagen, dass WASM neben JS läuft und die gleiche JS-Engine von Browsern verwendet (optimiert). https://developer.mozilla.org/en-US/docs/WebAssembly

Ich verstehe diese Frage nicht wirklich.

Es tut mir leid, eine dumme Frage zu stellen und einen dummen Kommentar abzugeben: Bedeutet die Frage und der Kommentar des Webassembly-Teams, dass Webassembly is FASTER than Javascript? I do not see performance comparison for WebAssembly Code and similar Javascript Code? ich nur subjektive Gedanken sehe? Kann das jemand erklären? Wenn Webasembly schneller ist als Javascript, warum dann nicht einen Transpiler bereitstellen? Wenn Javascript nicht möglich ist, warum dann nicht ES7/TS-Code? Warum ist das so geheim?

@ganeshkbhat Die erste Veröffentlichung von WASM ist kaum mehr als eine kompakte binäre Codierung von asm.js, einer sehr strengen Teilmenge von JavaScript. Es läuft nicht schneller als asm.js, außer wenn 64-Bit-Integer verwendet werden, da diese in asm.js emuliert werden müssen.

Es gibt Vorschläge, WASM Funktionen hinzuzufügen, die es in Bezug auf die Fähigkeiten von JavaScript näher bringen würden (Garbage Collection, DOM-Integration, Threads), aber es gibt keine Pläne, den vollständigen JavaScript-Funktionssatz hinzuzufügen. Es ist also wahrscheinlich, dass ein JS->WASM-Transpiler nie existieren wird. Stattdessen werden neue Anwendungen und Bibliotheken entwickelt, die so konzipiert sind, dass sie innerhalb der Grenzen von WASM arbeiten. Heute sind das C und C++, wo die Sprachbeschränkungen gut mit WASM und asm.js übereinstimmen.

Es gibt kein Geheimnis und keine Magie. Wasm ist "schneller als JavaScript", weil es eine viel einfachere Sprache ist, die viel näher an der Hardware ist. JavaScript ist eine komplizierte Sprache, die während der Ausführung viele kostspielige Dinge tun muss. Es würde nicht auf magische Weise schneller werden, wenn es über Wasm anstatt direkt in nativen Code kompiliert würde.

@ganeshkbhat derzeit ist es nicht möglich, Objekte innerhalb von asm.js / webassembly zuzuweisen. In asm.js und Webassembly verwenden alle JavaScript-Operationen einen großen Typdarray, um dort Werte zu speichern und zu laden. Das Erstellen von JavaScript-Objekten (zB var obj = {a: 1, b: 'test'} ) und Arrays (zB var a = []; ) ist innerhalb von Webassembly nicht möglich, da es noch keine Objektunterstützung gibt. Dies ist eine Designentscheidung des Minimal Viable Product, die getroffen wurde, um so schnell wie möglich Webassembly-Unterstützung in allen gängigen Browsern zu erhalten.

In einer zukünftigen Version ist GC-Unterstützung für Webassembly geplant. Wir ( LeaningTech.com- Entwickler) arbeiten an einem Vorschlag für die Objektunterstützung in der Webassembly, aber es wird einige Zeit dauern, bis er als Spezifikation und Implementierung in allen gängigen Browsern landet. Bis dahin ist es nicht möglich, JavaScript (und CoffeeScript, TypeScript usw.) in Webassembly zu transpilieren. Wenn der Vorschlag angenommen wird, sollte es möglich sein, eine größere Teilmenge von JavaScript zu transpilieren, es werden jedoch nicht alle derzeit verfügbaren Funktionen unterstützt.

Sicher. Freuen Sie sich auf besseren Support für JS hier. Ich habe definitiv das Gefühl, dass es unterstützt werden kann. Das Schreiben eines Transpilers ist möglicherweise für typunterstützende Sprachen erforderlich.

Nach dem, was ich über Webassembly gelesen habe, zielt es hauptsächlich auf Webbrowser ab und in diesem Bereich klingt es nicht sehr attraktiv, js -> Webassembly-Compiler zu haben. Aber ich kann mir vorstellen, Webassembly in Nicht-Browser-Umgebungen auszuführen. Dies ist nicht ganz richtig, da in auch in nodejs ausgeführt werden kann, aber ich sehe das wahre Potenzial in nodejs-Umgebungen in so etwas wie vertx - polyglot, das das Ausführen von Modulen ermöglicht, die in jeder Sprache geschrieben wurden und in Webassembly kompiliert werden können. Ich kann mir vorstellen, dass es extrem schwierig wird, so etwas zu realisieren. Es erfordert viele Funktionen wie GC, vielleicht sogar eine Art VM, um implementiert zu werden, aber nichts ist unmöglich. Denken Sie daran, dass viele Leute auch gegenüber asm.js skeptisch waren und sehen Sie es sich heute an.

Für alle, die sich (wie ich) für das Kompilieren von js -> webassembly begeistern, könnte es in Zukunft einen indirekten und sehr holprigen Weg durch js -> c -> webassembly mit dem Projekt ts2c transpiler geben.

@mauron85 Nicht-Browser- und Nicht-JavaScript-Laufzeitumgebungen sind definitiv eine Überlegung des Designs, es ist nur so, dass heute nur die JS-API existiert.

Ich für meinen Teil experimentiere mit einem .NET JIT-System und sehe außer der Zeit keine wirklichen Hindernisse, und ich bin sicher, es gibt auch andere, die WASM in ihre Lieblingsplattformen integrieren möchten. Ich bin mir sicher, dass es in einigen Jahren qualitativ hochwertige Nicht-JavaScript-Laufzeiten für WebAssembly geben wird, die einzige offene Frage ist, inwieweit sie vom WebAssembly-Team offiziell unterstützt werden.

IMO ein Vorteil der JavaScript -> WebAssembly Kompilierungsmöglichkeit besteht darin, dass die Entwickler/Betreuer der Javascript-Bibliotheken und -Tools ihre APIs wahrscheinlich in zwei Formaten veröffentlichen könnten:

1. in JS (wie es jetzt ist), die Benutzer für Browser und Knoten verwenden können
2. WASM als kompilierte Bibliothek, die möglicherweise effizienter ist.

Und das, ohne jemals ihren bestehenden JS-Code in C/C++ umschreiben zu müssen, wenn sie die Leistungsvorteile von WASM in ihren JS-Bibliotheken freisetzen möchten.
Die Bibliotheksentwickler wären also weiterhin in der Lage, in Javascript zu entwickeln und zu warten und zwei Ausgaben für zwei verschiedene Ziele sowohl in JS als auch in WASM zu erzeugen.

Und die Verwendung der kompilierten WASM-Versionsbibliothek wäre für die Benutzer definitiv effizienter, da sie nur die exponierte API aus der Bibliothek verwenden müssen und es ihnen offensichtlich egal ist, ob sie in WASM geschrieben ist oder nicht. Aber die Leistung würde sicherlich verbessert werden.

WASM als kompilierte Bibliothek, die möglicherweise effizienter ist

Wieso den? Warum sollte ein Blob von Javascript-Webassembly transpiliert werden (Worst-Case-Szenario, einschließlich eines Großteils der Laufzeit für eine Javascript-Engine in dieser Binärdatei; Best-Case-Szenario, einschließlich einer Schicht, die auf dem zukünftigen integrierten wasm GC aufgebaut ist, was sowieso seinen eigenen Overhead verursacht? ) schneller laufen als dieses Javascript, das auf einen Jit geworfen wird, der dem... Ausführen von Javascript gewidmet ist?

Okay, du meinst, das wäre mit mehr Overhead noch langsamer?

Vielleicht habe ich etwas nicht richtig verstanden. Wie ist C/C++/Rust -> WebAssembly kompiliertes Zeug wirklich effizient und selbst wenn es in Zukunft eine JS -> WASM Unterstützung geben würde, die Overhead verursachen würde? Liegt das nur daran, dass JS eine dynamische Sprache ist und C, C++ und Rust nicht? Oder liegt es daran, dass JS von Natur aus keine vollständig kompilierte Sprache ist, diese anderen Sprachen jedoch?

Ich denke, es ist unwahrscheinlich, dass die Kompilierung von JS zu WASM die anhaltende Leistung steigern würde; es kann jedoch aufgrund der binären Codierung, die immer noch nützlich ist, die Codegröße und die Parsing-Zeit verbessern.

Ich denke, wir können einfach eine binäre Kodierung für JS definieren und den linearen Speicher usw. vorerst ignorieren. Dies ist einfach und mehrfach befüllbar.

@kabirbaidhya Das Hauptproblem mit JS -> WASM besteht derzeit darin, dass Sie darin keinen effizienten Garbage Collector erstellen können, da es keine Möglichkeit gibt, den Stack zu analysieren, um zu sehen, welche Objekte am Leben sind. Dies bedeutet, dass Sie eine Kopie aller Objektreferenzen im linearen Speicher (dem Heap) ablegen und synchron halten müssen, was die Leistung erheblich beeinträchtigt. Außerdem fehlt Shared Memory Multithreading, sodass eine Garbage Collection im Hintergrund nicht möglich ist. Zukünftige Versionen von WASM werden in der Lage sein, die Garbage-Collection-Engine des Host-Browsers anzuzapfen, wodurch dieses Problem beseitigt wird.

Das andere große Hindernis für JS -> WASM ist die Tatsache, dass fast alle Objekte vollständig dynamisch sind. WASM erwartet von Natur aus, dass alles rein statisch ist, sodass komplexe Mapping-Schichten, Emulation und dynamische Codegenerierung erforderlich wären, um die Standard-JS-Leistung zu erreichen. Glücklicherweise hilft TypeScript dabei, sodass eine strikte Teilmenge von TypeScript bis zu einem gewissen Grad auf WASM abzielen kann. Ich weiß, dass es mindestens eine Person gibt, die versucht, dies zu bauen.

C/C++ funktioniert gut mit der ersten WASM-Version, da die Einschränkungen von WASM eng mit den Einschränkungen der nativen Hardware übereinstimmen, auf die C/C++ ausgerichtet ist.

FWIW gibt es ein tolles Slidedeck darüber, wie V8 JavaScript-Arithmetik handhabt: https://docs.google.com/presentation/d/1wZVIqJMODGFYggueQySdiA3tUYuHNMcyp_PndgXsO1Y/edit

tl;dr Dies ist nur _ein_ Beispiel, bei dem die Realität viel schwieriger ist als es scheint und in der Praxis nicht sehr aussagekräftig ist, da die native VM eine bessere und schnellere Arbeit leisten kann (und wahrscheinlich auch tun wird), da sie wirklich nativ ist und Zugriff darauf hat Ressourcen und APIs werden es nie werden – und (wahrscheinlich) am wichtigsten, jahrelange Iteration.

Das soll nicht heißen, dass sich eine _Teilmenge_ von JS/TypeScript nicht erfolgreich verbreiten könnte, wie ThinScript , TurboScript usw. Sie werden JS-Programmierern auf den ersten Blick sehr bekannt vorkommen.

Ich denke immer noch, dass dies gute Fragen sind, und ich stelle sie weiter. Es ist wichtig, dass wir alle die Anwendungsfälle und die Zukunft von WebAssembly verstehen – ebenso wie die Nicht-Ziele.

Am 6. April 2017 um 00:36 Uhr schrieb Ryan Lamansky [email protected] :

Die andere große Barriere für JS -> WASM ist die Tatsache, dass fast alle Objekte
sind voll dynamisch. WASM erwartet von Natur aus, dass alles rein ist
statische, also komplexe Mapping-Layer, Emulation und dynamische Codegenerierung
erforderlich wäre, um sich der Standard-JS-Leistung zu nähern. Glücklicherweise,
TypeScript hilft dabei, so dass eine strikte Teilmenge von TypeScript möglicherweise in der Lage ist
bis zu einem gewissen Grad auf WASM abzielen. Ich weiß, es gibt mindestens eine Person, die es versucht
bauen diese.

Leider bezweifle ich, dass TypeScript in dieser Hinsicht hilft. Umfassen
Das Vermächtnis von JS, sein Typsystem ist so tief und grundlegend unsolide, dass
es gibt keine interessante "strenge" Untermenge. Zum Beispiel würde eine solche Untermenge
müssen alle TS-Vorstellungen von Subtyping ausschließen, was es hübsch machen würde
viel nutzlos in seiner Domäne.

Es gab schöne Forschungsarbeiten, wie zB zu SafeTypeScript, aber nicht
nur sind sie stärker eingeschränkt, sie erfordern auch erhebliche Mengen an
kostspielige zusätzliche Laufzeitbuchhaltung und -prüfungen, die den Zweck verfehlen
die Diskussion (und effektiv eine andere Sprache als JS/TS).

Vielleicht bekomme ich etwas nicht, aber eine der Ideen von WebAssembly besteht darin, den AST direkt zu laden, um die Parse-Zeit von js zu vermeiden, oder?

Wenn wir also ein Tool haben, das js in dieses ast-Format kompiliert und an den Browser übergibt, wird es dann nicht davon profitieren, die Zeit zum Parsen zu vermeiden?

@agnivade , es ist ein AST für eine völlig andere, viel

Wenn Sie JS offline nach Wasm kompilieren würden, müssten Sie auf der Clientseite nicht parsen (nur decodieren). Gleichzeitig würde die Codegröße aufgrund der Komplexität von JS drastisch zunehmen, wahrscheinlich um den Faktor 5 oder mehr, was viel höhere Kosten bedeutet. (Und das ist noch nicht einmal berücksichtigt, dass Sie wahrscheinlich auch eine komplette Implementierung eines JS-VM-Laufzeitsystems in Wasm einbinden müssten, was leicht Megabytes an Code ist.)

Darüber hinaus können Sie ohne eine Darstellung der Quellen die meisten dynamischen Optimierungen nicht implementieren, die entscheidend sind, um JS auch nur annähernd schnell zu erhalten. Diese Optimierungen beruhen darauf, den ursprünglichen Quellcode neu zu kompilieren und ihn basierend auf Profiling-Informationen zu spezialisieren. Ein bereits kompilierter Wasm-AST ermöglicht dies nicht, Sie benötigen einen AST des ursprünglichen Quellprogramms.

@rossberg-chrom - Vielen Dank. Das klärt vieles auf! Ein Zweifel jedoch -

Und das ist noch nicht einmal berücksichtigt, dass Sie wahrscheinlich auch eine komplette Implementierung eines JS-VM-Laufzeitsystems in Wasm einbinden müssten, was leicht Megabytes an Code ist

Warum benötigen Sie das VM-Laufzeitsystem? Ist der Browser selbst nicht die VM-Laufzeit? Ich möchte nur, dass der Code im AST-Format vorliegt, damit der Browser sofort mit der Ausführung beginnen kann. Ich verstehe, dass die Nettogröße zunehmen wird, weil die Sprache selbst komplex ist und wir keine dynamischen Optimierungen implementieren können. Aber warum müssen wir die VM-Laufzeit selbst bündeln, wenn wir den Browser dafür haben?

@agnivade , ohne dynamische Optimierungen wird JavaScript langsam sein, und ich meine _wirklich_ langsam, wie 100x langsamer, vielleicht noch schlimmer.

Mit "Laufzeit" meine ich nicht Browser-Zeug wie das DOM, sondern die bloße JS-Sprachunterstützung, dh Dinge wie Garbage Collector, Objektdarstellungen, Primitiven und Basisbibliotheken usw. Das ist ziemlich groß für JavaScript, und Sie würden brauchen eine Neuimplementierung von allem in Wasm.

Und natürlich benötigen Sie auch eine Schnittstellenschicht zum DOM.

Ok, ich glaube, ich verstehe die Dinge jetzt ein bisschen besser. Ich dachte, dass die

Garbage Collector, Objektdarstellungen, Primitiven und Basisbibliotheken usw.

kann über den Browser selbst verwendet werden. Und ich kann den Browser einfach den AST laden lassen und seine übliche Arbeit erledigen. Aber jetzt ist mir klar, dass alles in WASM selbst verpackt werden muss.

Ein universeller Bytecode für die Skriptsprache wäre jedoch interessant! Ein Kompilierungsziel, das darauf ausgerichtet ist, Programme, die in dynamisch typisierten, Müll gesammelten Sprachen geschrieben wurden, effizient zu transportieren und auszuführen, mit all den bizarren Randfällen der gängigen (Javascript, Ruby, Python, Lua), die in (in einigen Fällen) speziellen Opcodes und Strukturen usw

@distransient , also willst du den kombinatorischen Wahnsinn aller Skriptsprachen? Ich bin optimistisch, dass es der Menschheit möglich sein wird, die technischen Ressourcen zu sammeln, um dies bis 2050 effizient zu spezifizieren und umzusetzen. :) :)

Diejenigen, die daran interessiert sind, TypeScript mit LLVM in WebAssembly zu kompilieren. Schauen Sie sich dieses Reichweitenprojekt an. https://github.com/MichaReiser/speedy.js
Diese Diskussion scheint kein Ende zu nehmen...

@rossberg-chromium Ich sagte es wäre "interessant", nicht einfach oder hübsch 😉

Ein universeller Skriptsprachen-Bytecode wäre interessant...

Während sich WASM schrittweise weiterentwickelt, um schließlich Dinge wie Python zu unterstützen, könnten wir viel früher erstklassige Unterstützung für die Entwicklung von Skriptsprachen für das Web erhalten, als WASM sie bereitstellen kann, wenn wir das Problem gleichzeitig vom anderen Ende aus angehen würden.

Es sollte für JavaScript-Engines relativ einfach sein, ihre Fähigkeit zur Ausführung von JavaScript-ASTs offenzulegen, und die von ihnen akzeptierten ASTs könnten standardisiert werden (auch wenn sie sofort intern in ein nicht standardmäßiges Zwischenformat konvertiert werden).

Wir könnten einfach ein AST-Format (wie estree ) und ein Serialisierungsformat (wie JSON) kombinieren, um ein neues Dateiformat mit einer neuen Erweiterung zu erstellen. Wenn Browser das Format in Skript-Tags usw. unterstützten, würden Sprachen wie TypeScript und CoffeeScript einfach kompilieren, um Bäume zu analysieren, und der Browser würde es von dort übernehmen. Transpilierte Sprachen müssten keine Codegenerierung durchführen, und auch Quellzuordnungen wären nicht mehr erforderlich, da die lexikalischen Informationen auf der tatsächlichen Quelle basieren würden.

Sobald die grundlegende Unterstützung eingerichtet war, könnte sich der Standard schrittweise weiterentwickeln, um WASM in der Mitte zu erfüllen, indem im Grunde einfach neue Knotentypen hinzugefügt werden. Es gibt einfache Dinge, mit denen man beginnen kann, wie explizite add und concat Knoten oder vielleicht das Hinzufügen neuer Datentypen wie DEC64.

Wenn WASM auf die Unterstützung von Skriptsprachen aufbaut, würde die AST-Ausführung durch das Hinzufügen von Dingen wie GC nach unten verschoben und die JavaScript-Semantik um Funktionen aus anderen höheren Sprachen erweitert, sodass ein breiterer Satz von Skriptsprachen zu einer Art abstraktem JavaScript kompiliert werden könnte.

Am 25. Mai 2017 um 02:57 Uhr schrieb Carl Smith [email protected] :
>

Es gibt einige Probleme, die angegangen werden müssten, aber das wäre es
relativ einfach für JavaScript-Engines, um ihre interne Unterstützung verfügbar zu machen
für die Ausführung von JavaScript-ASTs, und die von ihnen akzeptierten ASTs sollten . sein
standardisiert (auch wenn die AST sofort in Nicht-Standard umgewandelt wird,
Zwischenformate intern).

Nur für eine viel breitere Definition von "relativ einfach" als Sie wahrscheinlich
im Gedächtnis haben... ;)

Im Vergleich zu WASM ist es einfach.

@bguiz Zum Beispiel:

• Sie können JS nicht nativ in ASM übersetzen, da es eine andere Architektur hat.
• Sie können DOM nicht von ASM aus manipulieren, da Sie keinen Zugriff auf seine Ressourcen auf CPU-Grundebene haben.

Die Google V8-Engine kompiliert das JavaScript bereits direkt in nativen Maschinencode, indem sie die gesamte Laufzeitaufgabe kompiliert, bevor sie ausgeführt wird.

Es wäre also völlig unnötig, eine alternative WASM-Pipeline von der Clientseite aus zu haben.

Auf der anderen Seite wurde WASM mit einer Mandelbrot-Demo präsentiert, dann enthält es in erster Linie die Unity "Tanks" -Demo, aber ich bezweifle sehr, dass das Zeichnen von Pixeln mit ASM->CPU (sogar mit SSE-Doppelgenauigkeit) jemals schneller sein könnte als WebGL->GPU, denn wie diese Community sagt, ist die GPU nicht im Umfang. Na und?

@ivanherczeg Woah! Wo sagt diese Community, dass die GPU nicht in der Spezifikation ist?

@SephReed

Wir haben bereits Spannungen aufgrund von Fahrradschuppenunterschieden zwischen Arm und x86. Ich denke, dass das Hinzufügen eines weiteren Satzes von Hardwarezielen zu mehr Spannungen führen würde: Mehr Operationen müssten entweder aufgrund von Emulationskosten langsam sein, um eine einheitliche Semantik für alle Ziele zu erhalten, oder mehr Operationen müssten undefiniertes Verhalten aufweisen, damit alle schnell ausgeführt werden können. Ich denke, das macht es unrentabel, die GPU zu diesem Zeitpunkt (oder jemals) in Betracht zu ziehen.

-Fil

https://github.com/WebAssembly/design/issues/273#issuecomment -123094583

Die C#-Laufzeit wurde auf wasm portiert und war ein voll funktionsfähiger Prototyp, der JS vollständig ersetzte. Das bedeutet also, dass Sie in Zukunft damit rechnen können, dass Laufzeiten, die JS in Browsern ersetzen und clientseitige Webanwendungen in Java, C# oder sogar C++ schreiben, mit der Aussage "Code wird fast nativ schneller ausgeführt werden" , "Kompilierter Code ist schneller als VM" schreiben. oder irgendetwas ohne die Hilfe von JavaScript.

Bitte sehen Sie sich dieses Video an, was ich zu sagen versuche.

WebASM wurde eingeführt, um JS zu ergänzen, nicht vollständig zu übernehmen und die First-Class-Sprache zu ersetzen.

In naher Zukunft können Sie Webseiten erwarten, die von einem nativ kompilierten Server bereitgestellt werden

https://github.com/ballercat/walt

@Steakeye Sehr schön :) Ich werde spielen - vielen Dank fürs Hervorheben :)

Sie können JS mit NectarJS zu WebAssembly kompilieren. Demo: http://nectar-lang.com/ Wählen Sie aus dem Dropdown-Menü WebAssembly

Interessant, die NectarJS-Demo verwendet emscripten, das sieht man in der Ausgabe von asm.js. Es scheint, dass es JS statisch in etwas kompiliert - wahrscheinlich C oder LLVM IR - und das dann über Emscripten ausführt.

Die wasm-Ausgabe verwendet auch emscripten (kann bei der Überprüfung der Binärdatei gesehen werden), aber sie scheint eine alte Version zu verwenden, da sie 0xd-wasm-Binärdateien ausgibt, die in modernen VMs nicht ausgeführt werden. Es sendet Ihnen auch nur das Wasm, nicht das JS, also ist es sowieso nicht lauffähig. Auf jeden Fall ist es sehr gut möglich, dass es dasselbe wie für asm.js tut, nur emscripten mit eingeschaltetem Flag für die wasm-Ausgabe ausführen.

Die Demo hat eine Grenze von 300 Byte für die Eingabe, daher ist es schwierig, sie mit einem realen Programm zu füttern, um ein Gefühl dafür zu bekommen, wie leistungsfähig ihre Analyse ist, was bei einem statischen Ansatz wie diesem die eigentliche Frage ist. Generell lässt die wissenschaftliche Forschung zu diesem Thema Skepsis erkennen.

Ihre kompilierten Demos für Windows stürzen bei mir einfach ab 🤕

Ich stimme der Skepsis von @kripken hier zu. Ich glaube, dass beliebiges JS nicht vernünftig in WebAssembly konvertiert werden kann. Jedes Tool, das behauptet, dies zu erreichen, arbeitet wahrscheinlich an einer handhabbaren Teilmenge der JS-Sprache oder gibt die Ausführungsleistung auf.

JS ist eine extrem dynamische Sprache. Unvorhersehbare Laufzeitoperationen können die Semantik des Codes erheblich und global verändern. Dies bedeutet, dass ein Ahead-Of-Time-Compiler (oder Offline-Compiler) nur das Schlimmste annehmen und sehr ineffizienten generischen Code generieren kann, der alle möglichen Fälle verarbeiten kann. Nehmen Sie als Beispiel den folgenden JS-Code:

var a = {prop1: 1};
func(a);

könnte (in Pseudo-Wasm) dazu umgewandelt werden

i32.const 42
call $CreateJSValFromStrTable ;; Returns prop1
i32.const 1
call $CreateJSValFromInt
call $CreateJSObj1 ;; Consume a JS string and a JS value to make an object
call $_func

Nun, dies ist weit entfernt von dem, was wir vernünftigerweise als "kompilieren" bezeichnen können, und es ähnelt eher dem Entrollen eines Interpreters. Es ist natürlich auch möglich, einen zu Wasm kompilierten JS-Interpreter auszuführen, aber das wäre kaum ein Leistungsgewinn.

JS-Engines wie V8 und Spidermonkey können JS-Code genauso schnell ausführen, wie sie es tun, indem sie ihn Just-In-Time kompilieren. Durch die JIT-Kompilierung können sie beobachten, was die wirklich beabsichtigte Semantik für einen bestimmten Teil von JS ist, und schnellen Code für diesen speziellen Fall generieren, während sie natürlich darauf achten, jede Änderung in der Umgebung zu erkennen, die die aktuellen Annahmen ungültig machen könnte.

Einverstanden. Ich hätte jedoch nichts dagegen, eine JavaScript-Untermenge zu verwenden. Oder vielleicht eine typisierte Variante, die wahrscheinlich die Dynamik reduzieren und eine effizientere Codegenerierung ermöglichen würde.

Gibt es Neuigkeiten zum Thema "starker Modus" übrigens?

@Simran-B, wir haben den starken Modus aus den hier zusammengefassten Gründen schon lange aufgegeben. Die Erkenntnis ist, dass es so gut wie unmöglich ist, die JavaScript-Semantik zu straffen, ohne die Interoperabilität mit dem vorhandenen Code zu verlieren.

Aus dem gleichen Grund habe ich auch nicht viel Hoffnung für die Idee, einen "statisch kompilierbaren" Dialekt von JavaScript oder TypeScript zu entwerfen - es wäre eine andere Sprache, die vorhandenen Code nicht ausführen kann, also nicht viel Sinn.

@Simran-B: "Ich hätte jedoch nichts dagegen, eine JavaScript-Untermenge zu verwenden. Oder vielleicht eine typisierte Variante."

Es gibt einige sehr interessante Arbeiten in diesem Bereich, wie AssemblyScript, eine strikte Teilmenge von TypeScript, die zu WebAssembly kompiliert wird, https://github.com/AssemblyScript/assemblyscript

@rossberg : "Ich habe auch nicht viel Hoffnung für die Idee, einen "statisch kompilierbaren" Dialekt von JavaScript oder TypeScript zu entwerfen - es wäre eine andere Sprache, die vorhandenen Code nicht ausführen kann, also nicht viel Sinn."

Ich denke, das große Potenzial von Dingen wie AssemblyScript besteht nicht darin, vorhandenen Code auszuführen (da stimme ich Ihnen zu, das wird im Allgemeinen nicht machbar sein), sondern dass eine freundliche und vertraute Sprache eine große Sache ist.

Wenn Sie derzeit ein TypeScript-Entwickler sind und WebAssembly schreiben möchten, müssen Sie C++ oder Rust verwenden. Beides sind gute Sprachen, haben aber auch Nachteile. Für jemanden mit diesem Hintergrund könnte so etwas wie AssemblyScript der schnellste Weg zur Produktivität sein.

Wenn AssemblyScript sowohl in JavaScript als auch in Assembly kompilieren kann, wäre das ziemlich ideal. Freue mich auf diese Updates.

Außerdem werde ich in Zukunft wahrscheinlich versuchen, einen TypeScript -> Assembly Script-Konverter zu schreiben, der die Dateien durchgeht, die Fragen stellt, die er stellen muss, und dann die Konvertierung durchführt, es sei denn, jemand tut es zuerst. Hoffentlich klappt es!

@SephReed Ja, es kann zu JavaScript kompiliert werden, da es einen WebAssembly -> asm.js-Compiler gibt , der mit dem gesamten WebAssembly-Code funktionieren sollte.

Siehe auch "Kann WebAssembly mehrfach gefüllt werden?"

Wenn Sie stattdessen meinten "ist es möglich, dass AssemblyScript in idiomatischen JavaScript-Code kompiliert wird?", dann muss ich fragen, warum sollten Sie das tun, wenn WebAssembly / asm.js so viel schneller als idiomatischer JavaScript-Code sind?

Ich nehme jedoch an, dass Sie den AssemblyScript-Code über den TypeScript-Compiler ausführen können sollten. Sie müssen jedoch einige Dinge beachten .

Siehe auch diesen Abschnitt der AssemblyScript-Dokumentation.

Meine Herren, denken Sie bitte an WALT , die JavaScript-ähnliche WebAssembly-Sprache.

UPD. Entschuldigung für das Nekroposting

Ich sehe, dass viele Leute diesen "JS -> WASM"-Compiler für eine gute Idee halten.

Für diejenigen, die es nicht nützlich finden, wie:

Ich bin mir jedoch nicht sicher, ob es aus der Perspektive eines Entwicklers so nützlich sein wird. Möglicherweise erhalten Sie eine Größenreduzierung, aber das war es auch schon. Aus Sicht eines Browsers kann es aus reiner Sicherheitssicht interessant sein, die JS-Engine in wasm implementiert zu haben.

Bitte, hier ist mein konkretes Beispiel dafür, warum es wichtig und nützlich ist, und nicht nur, dass Sie "etwas verkleinern, aber das war es auch schon". Eine der Funktionen von WebAssembly ist:

<=XXX « SANDBOXED UMGEBUNG » XXX=>

Bei WebAssembly geht es nicht nur um Leistung. Vielleicht sehen Sie einen guten Artikel über Plugins vom Figma-Team .

Ein Plugin-System zu erstellen ist ziemlich anspruchsvoll. Sie benötigen eine gute Möglichkeit, benutzerdefinierten Code auszuführen. Sie brauchen eine separate Umgebung, eine sichere.

WebAssembly bietet Ihnen das, - eine reine Umgebung ohne Durcheinander wie einige globale Variablen. AssemblyScript macht es in gewisser Weise bequem - Sie haben fast die gleiche TypeScript-Umgebung wie die Umgebung Ihrer Hauptanwendung, was ziemlich cool ist.

Aber hier ist das Problem, "fast gleich":

Kann ich JS-Pakete von NPM in meiner sicheren Umgebung verwenden?

Nein.

Nun, dieses WALT- Projekt ist eine Art AssemblyScript-Alternative. Es ist kaum JS-ähnlich, - es ist typisiert js. Es ist eher wie TS. Sie können vorhandene js-Bibliotheken damit nicht kompilieren/transpilieren.

Kann ich TS-Pakete von NPM in meiner sicheren Umgebung verwenden?

Nein.

AssemblyScript ist auch eine TS-ähnliche Sprache. Es kann etwas in TS geschriebenes kompilieren, wenn es vollständig mit Typen abgedeckt ist. Keine Ausnahmen. Keine any 's. Aber oft haben die Leute ihre Konfigurationen nicht streng genug oder sie haben ein paar @ts-ignore oder noch häufiger - sie schreiben Pakete in js und stellen separate Typen in .d.ts -Dateien bereit - in all diesen Fällen nicht in der Lage sein, ein solches Paket nach WASM zu kompilieren.

@JerryGreen gute Punkte, aber auf der Leistungsseite der Dinge glaube ich tatsächlich, dass es ein großes Missverständnis ist, dass es über das Sparen einiger Bytes hinaus keine signifikanten Leistungsvorteile gibt. Leute, einschließlich Benchmarks, sind so besessen von der Laufzeitleistung. Sehen Sie, wie schnell 3D-Spiele ausgeführt werden?

Die reale Chance liegt jedoch in der Startleistung , von der praktisch alle Websites profitieren. Nur wenige scheinen darüber zu sprechen, dass WebAssembly in der Startzeit (pro Byte) wesentlich schneller ist, weit über alle Laufzeitvorteile hinaus. Aus diesem Grund hat z. B. gzip für Textinhalte wie JavaScript kaum Auswirkungen auf die PLT – es kommt auf die Größe des kompilierten Codes an .

Ironischerweise ist die Branche von PLT (Page Load Times) und verschiedenen visuellen vollständigen Markierungen besessen, aber niemand sieht die Korrelation zwischen WebAssembly und diesen Vektoren? JavaScript ist auf den meisten Websites für über 30 % der Zeit verantwortlich, die vor diesen kritischen Ereignissen verbracht wurde. Tatsächlich haben Seitengröße und Bandbreite im Vergleich zu linearen Leistungsfaktoren, nämlich JavaScript-Startzeiten

Damit ist mir die Machbarkeit von JS -> WebAssembly nicht klar.

@JerryGreen Figmas Ansatz ist ein sehr spezifischer Fall und ich denke, für die meisten Projekte sind Iframes oder Realms hübsch genug für die JavaScript-Isolation von Drittanbietern. Für spezielle Fälle, in denen die Isolation besser kontrolliert werden soll und Leistung, Größe und Ladezeit nicht so wichtig sind, können Sie QuickJS oder JavaScriptCore immer in WebAssembly kompilieren.

Sie können auch Web Worker verwenden und Code vor Ihrem nicht vertrauenswürdigen Code ausführen, der alle APIs löscht, auf die der nicht vertrauenswürdige Code keinen Zugriff haben soll. In diesem Fall ist WASM nicht erforderlich @JerryGreen!

Framerate Drops in Three js in einer realen Sache, ich bin mir nicht sicher, ob wasm helfen könnte, aber es scheint zumindest an der Oberfläche so zu sein.

Es gibt keinen Grund, JS nach wasm zu kompilieren, da Sie auch eine ganze Javascript-VM einbinden müssten. Der resultierende Code wäre riesig und langsamer als die nativ bereitgestellte JS-VM.

Könnten wir nicht alle Monomorphisierungen usw. durchführen, die von JS-VMs durch profilgesteuerte Optimierung durchgeführt werden ? Wir würden so ziemlich dasselbe tun wie die JS-VMs zur Laufzeit, aber im Voraus.

Ein PGO-Build besteht aus zwei Durchgängen: einem ersten Durchgang zum Erstellen instrumentierter Binärdateien, dann einem zweiten Durchgang zum Neuaufbau optimierter Binärdateien unter Verwendung von Profilinformationen, die aus der Ausführung der instrumentierten Binärdateien gewonnen wurden.

Der erste Durchlauf würde uns alle Typinformationen liefern (welche Funktionen mit welchen typisierten Argumenten aufgerufen werden usw.), dann erstellen wir eine optimierte Binärdatei mit allen Varianten, mit denen eine Funktion aufgerufen wird (+ generische mit dynamischen Argumenten für nicht profilierten Code) . Wir würden nicht die gesamte JS-VM benötigen.

PGO erforderte eine großartige Testabdeckung Ihres Programms. Es ist nicht immer möglich. Sie könnten jedoch während der Ausführung in v8 einige Typinformationen verfolgen. Siehe dieses Dokument: https://docs.google.com/document/d/1JY7pUCAk8gegyi6UkIdln6j_AeJqQucZg92advaMJY4/edit#heading =h.xgjl2srtytjt

Wir haben mit dem TypeScript-Team über diese Möglichkeit gesprochen und sie haben Interesse gezeigt, aber es scheint, als ob es derzeit Fortschritte beim Hinzufügen typisierter Objekte zu JS gibt.

Brauche keine Typen

Kann QuickJS wirklich zu WASM kompiliert werden?

Ja, Figma verwendet zum Beispiel QuickJS für ihr Plugin-System

Und es wird auch in http://numcalc.com/ verwendet .