Design: Webasm kann Javascript im Browser ersetzen?

Ich kenne mich mit c# nicht aus, aber eigentlich denke ich, dass wasm Javascript nicht komplett übernehmen kann.

Erstens, wenn Sie es versucht haben, würden Sie feststellen, dass Javascript bei einigen niedrigeren Operationen wie "+,-,*,/" und einigen anderen mathematischen Operationen aufgrund des geringen Overheads beim Aufrufen aus JavaScript viel schneller ist als wasm in WebAssembly und zurück. #1120

Zweitens, für Webentwickler, die bereits mit Javascript und seiner Grammatik vertraut waren, ist es für sie unnötig und schwierig, Webanwendungen mit einer anderen Nicht-Web-Entwicklungssprache zu erstellen.

Mit Hilfe von „ Binary AST “ wird die Leistungsfähigkeit aktueller Webanwendungen endlich auf ein neues Niveau gehoben, ohne dass diese Anwendungen überarbeitet werden müssen.

PS:
Unabhängig von C# oder Java, wenn Sie diese Programmiersprache für Entwickler viel benutzerfreundlicher machen möchten, wird die Effizienz dieser Sprache aufgrund einiger "einfach zu verwendender" Funktionen wie "schwacher Typ" und anderer Funktionen eingeschränkt sein, und umgekehrt.

@Becavalier Kann ja sein, wenn Sie versuchen, eine wasm-Funktion aus dem JS-Kontext-Overhead aufzurufen, aber die Laufzeit kommuniziert nicht mit Javascript, bis und es sei denn, es ist ausschließlich erforderlich _etc.._ Die gesamte Ausführung innerhalb des wasm-Kontexts ist ziemlich schneller. Die Verzögerung tritt auf, wenn die JS-Bridge eingeführt wird. Im Fall von #1120 versuchen Sie, den Leistungszeitstempel im Javascript-Kontext für eine Funktion zu drucken, die im Wasm-Kontext ausgeführt wird, was eine zusätzliche Verzögerung darstellt.

Beliebte Frameworks wie Angular2/4, die eine komplette Überarbeitung mit Typescript, Android in Kotlin oder iOS in Swift sind, wenn hinter einigen der Frameworks ein großer Name steht, oder die ganze Welt der Sprache versuchen, die Änderung zu übernehmen.

Der Punkt ist also, dass die Möglichkeit besteht, dass JS durch Abstraktion der API-Brücken und Portierung von Laufzeiten im Browser an den Rand gedrängt oder sogar aus dem Bild entfernt wird. Webassembly hat Compilern anderer Sprachen die Tür geöffnet, um mit Javascript im Browser zu konkurrieren.

Anfangs haben wir Technologien eingeführt, die unseren JS-Code für die Ausführung auf VMs wie V8 und anderen effizienter machten, aber jetzt können Sie einen Assemblercode schreiben und kompilieren, der den JS-Code überspringen kann.

Jetzt können Sie Compiler für das Web erwarten, die Transpiler wie TypeScript, CoffeeScript usw. ersetzen.

Javascript-Entwickler, drückt die Daumen . Kann in den kommenden Jahren mit einem großen Schritt rechnen.

PS: Ich liebe Javascript und C-Lang

Webassembly hat Compilern anderer Sprachen die Tür geöffnet, um mit Javascript im Browser zu konkurrieren.

Ja, das ist einer der Zwecke von WebAssembly.

Hier ist ein Zitat aus den WebAssembly-FAQ :

Während WebAssembly im Laufe der Zeit die Kompilierung vieler Sprachen für das Web ermöglichen wird, hat JavaScript eine unglaubliche Dynamik und wird die einzige, privilegierte (wie oben beschriebene) dynamische Sprache des Webs bleiben. Darüber hinaus wird erwartet, dass JavaScript und WebAssembly in einer Reihe von Konfigurationen zusammen verwendet werden:

• Ganze, kompilierte C++-Apps, die JavaScript nutzen, um Dinge zusammenzufügen.

Denken Sie daran, dass andere Sprachen seit Jahren zu JavaScript kompiliert werden und dies mit oder ohne WebAssembly weiterhin tun werden.

Sie können C#, F#, C++, OCaml, Elm, PureScript, Haskell, Java, Python, Ruby, Perl usw. bereits in JavaScript kompilieren.

Sie können .NET-Bytecode zu JavaScript kompilieren , Sie können GWT gibt es seit 11 Jahren und wird in großen Projekten verwendet.

Diese Projekte gibt es schon seit vielen Jahren. Es ist nicht wirklich neu.

JavaScript konkurriert bereits mit anderen Sprachen. WebAssembly macht andere Sprachen nur effizienter, das ist alles.

Anfangs haben wir Technologien eingeführt, die unseren JS-Code für die Ausführung auf VMs wie V8 und anderen effizienter machten, aber jetzt können Sie einen Assemblercode schreiben und kompilieren, der den JS-Code überspringen kann.

Ja, da JavaScript-VMs aufgrund des Overheads von JIT-Engines (und der inhärent dynamischen Natur von JavaScript) niemals eine native Leistung erreichen können. Wenn Sie also mehr Leistung wünschen, benötigen Sie eine strenge Low-Level-Steuerung der Codeausführung. WebAssembly gibt Ihnen diese Kontrolle.

Der Punkt ist also, dass die Möglichkeit besteht, dass JS durch Abstraktion der API-Brücken und Portierung von Laufzeiten im Browser an den Rand gedrängt oder sogar aus dem Bild entfernt wird.

Nein, die Leute werden weiterhin JavaScript verwenden.

Auf dem Desktop stehen seit vielen Jahren viele Sprachen zur Auswahl: Python, Perl, Ruby, PHP, Haskell, JavaScript (Node.js), OCaml, C++, Java usw.

Die Leute verwenden viele Sprachen, einschließlich JavaScript. JavaScript führt nirgendwo hin.

Selbst in einer ( sehr unwahrscheinlichen) hypothetischen Welt, in der JavaScript keine erstklassige Sprache ist, können die Leute JavaScript in WebAssembly kompilieren.

Jetzt können Sie Compiler für das Web erwarten, die Transpiler wie TypeScript, CoffeeScript usw. ersetzen.

Das ist unwahrscheinlich, es gibt immer noch gute Gründe, TypeScript und JavaScript zu verwenden.

Natürlich wird es Alternativen zu TypeScript geben, und einige Leute werden diese Alternativen verwenden, aber TypeScript wird wahrscheinlich nicht verschwinden.

Ich sage das, weil es schon seit Jahren gute Alternativen zu TypeScript gibt (wie Haxe ), die TypeScript aber nie ersetzt haben.

Am 4. September 2017 um 03:42 schrieb Pauan [email protected] :
>

JavaScript konkurriert bereits mit anderen Sprachen. WebAssembly macht einfach
andere Sprachen effizienter, das ist alles.

Letzteres ist nicht ganz richtig. Ein weiteres Ziel von Wasm ist es, Funktionen zu aktivieren
die von JavaScript nicht unterstützt werden und möglicherweise auch nie unterstützt werden. Zum
Parallelität, Tail Calls oder fortsetzbare Ausnahmen sind alle auf der
Straßenkarte.

@rossberg-chromium Tatsächlich hast du Recht, dieses Detail hatte ich vergessen. Danke fürs klarstellen.

@Pauan Danke für die Details. Obwohl einige Ihrer Punkte gültig und sinnvoll sind, stimme ich nicht allen zu.

C# auf Client-Seite sieht vielversprechend aus und ist ein Killer-Beispiel, um Javascript in der Entwicklungsphase vollständig zu vermeiden. dh.. Ich kann C# verwenden, um eine voll funktionsfähige Webapp zu schreiben, ohne dass ich Javascript-Code schreibe. Diese Art von einstellungsbasierten Frameworks haben eine wahrscheinliche Chance, Javascript-Legacy zumindest bis zu einem gewissen Grad zu dämpfen.

Sie können C#, F#, C++, OCaml, Elm, PureScript, Haskell, Java, Python, Ruby, Perl usw. bereits in JavaScript kompilieren.

Ja, das Javascript war im Bild. Aber jetzt mit WASM/Webasm ändert sich mein Motiv, nach Javascript zu kompilieren. Man kann bei Bedarf direkt in wasm kompilieren und eine API-Maskenschicht oder Bridges in Javascript schreiben, so dass die Entwicklerbasis kein Javascript kennen muss, um eine Webapp mit Webapp zu entwickeln. Ich meine reine Webapp, nicht ASP.net, JSP-Frameworks.

Denken Sie daran, dass andere Sprachen seit Jahren zu JavaScript kompiliert wurden und dies mit oder ohne WebAssembly weiterhin tun werden.

Sie können C#, F#, C++, OCaml, Elm, PureScript, Haskell, Java, Python, Ruby, Perl usw. bereits in JavaScript kompilieren.

Während viele Sprachen bereits in JavaScript kompilieren können, würde die Kompilierung in Webasm die erheblichen Nachteile bei der Last und der Laufzeitleistung vermeiden? Und die Leistungsprobleme, wenn Sie eine vollständige C-VM für Sprachen nach Webasm kompiliert haben, um dies auf diese Weise zu tun?

Wenn die Verwendung anderer Sprachen zu unvermeidlichen Leistungsproblemen führt oder an vielen Stellen gegen diese Sprachspezifikation verstößt (aus Leistungsgründen), ist dies bestenfalls ein teilweiser Ersatz für JavaScript und im Allgemeinen habe ich gesehen, dass sie mehr für die Portierung von Legacy-Code als für neuen Code zum "Ersetzen" verwendet wurden JavaScript" (mit Ausnahme von CoffeeScript, TypeScript usw., die so konzipiert sind, dass sie gut in JS kompiliert werden).

Sind diese Probleme lösbar? zB mit einem neuen Ruby -> Webasm-Compiler und vergleichbare Performance zu aktuellem Browser-JavaScript?

Um JavaScript und Ruby (mit Opal) als Beispiel zu verwenden (wie ich es zuvor versucht und im Grunde aufgegeben habe):

In JavaScript mit einem + Operator ermöglicht es die Umwandlung von Zahlen in einen String, zB

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

Ruby hat eine viel stärkere Typisierung, und das ist nicht erlaubt:

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

Opal muss also für viele Kerntypen eigene Plus- und ziemlich komplexe Methoden entwickeln

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()}

Ebenso für viele grundlegende Operationen.

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

Vielleicht könnte ein JIT das theoretisch vollständig optimieren, aber ich denke nicht, dass sie nahe dran sind (kein Mikro-Benchmark, aber für eine ganze Prototyp-App/-Seite habe ich die Ruby-Version wesentlich langsamer gemacht) Optimierer das Leben schwerer?

Und selbst dann sind einige Dinge falsch oder werden nicht unterstützt (obwohl Webasm native Integer hat, also ist das hoffentlich ein Anfang, wenn man eher zu Webasm als zu JS kompiliert):

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

Ich kann C# verwenden, um eine voll funktionsfähige Webapp zu schreiben, ohne dass ich Javascript-Code schreiben muss.

Ja, und ich stimme zu, dass das sehr cool ist (ich arbeite an einer Sprache, die ich zu WebAssembly kompilieren möchte), aber mein Punkt ist, dass Sie dies bereits tun können, auch ohne WebAssembly.

Man kann bei Bedarf direkt in wasm kompilieren und eine API-Maskenschicht oder Bridges in Javascript schreiben, so dass die Entwicklerbasis kein Javascript kennen muss, um eine Webapp mit Webapp zu entwickeln. Ich meine reine Webapp, nicht ASP.net, JSP-Frameworks.

Tatsächlich, und das ist schon seit vielen Jahren möglich. Sie müssen nicht auf WebAssembly warten, Sie können jetzt beginnen : asm.js existiert seit mehreren Jahren.

@wnewbery

Während viele Sprachen bereits in JavaScript kompilieren können, würde die Kompilierung in Webasm die erheblichen Nachteile bei der Last und der Laufzeitleistung vermeiden? Und die Leistungsprobleme, wenn Sie eine vollständige C-VM für Sprachen nach Webasm kompiliert haben, um dies auf diese Weise zu tun?

Es kann die Analysezeiten unterstützen, aber es ist unwahrscheinlich, dass die Laufzeitleistung verbessert wird.

Lassen Sie mich etwas klarstellen :

Es war also bereits möglich, eine Sprache zu nehmen, ihre VM, Laufzeit und Garbage Collector in asm.js zu kompilieren, und Sie können dann jede gewünschte Sprache im Browser mit fast der gleichen Geschwindigkeit wie auf dem Desktop ausführen. Dies ist bereits seit einiger Zeit möglich.

Das Kompilieren der VM, der Laufzeit und des Garbage Collectors bedeutet jedoch, dass die Dateigröße ziemlich groß ist (viele Megabyte).

Und es ist schwierig, mit JS-APIs (wie dem DOM) zu kommunizieren.

Aber einige Leute haben es trotzdem getan und Dinge wie PyPy.js erstellt, die den PyPy-Interpreter in

Es läuft schneller als CPython (ja, wirklich! Der PyPy-Interpreter, der in JavaScript kompiliert wurde und in einem Browser läuft, läuft schneller als natives CPython auf dem Desktop!)

Aber die Dateigröße ist ziemlich schlecht (5 Megabyte gzipped, 15 Megabyte roh).

Sie könnten also Rubys VM + Garbage Collector + Runtime in asm.js kompilieren, und es wäre sehr schnell, aber es hätte diese Probleme. Stattdessen erschaffen die Leute Dinge wie Opal.

WebAssembly ist die nächste Weiterentwicklung von asm.js. Im Moment ist alles, was Sie mit WebAssembly machen können, auch mit asm.js möglich.

Also ja, es ist möglich, Ihre Sprache + VM + Laufzeit + Garbage Collector zu WebAssembly zu kompilieren, und es wird mit fast nativer Geschwindigkeit ausgeführt.

Aber natürlich hat es die gleichen Nachteile wie asm.js: sehr große Dateigröße und es ist schwierig, mit JS-APIs zu kommunizieren.

Es gibt sieben Unterschiede zwischen WebAssembly und asm.js:

1. WebAssembly ist ein kleines bisschen (5%) schneller als asm.js im Allgemeinen.

2. WebAssembly ist deutlich (~ 400 %) schneller als asm.js, wenn Sie 64-Bit-Ganzzahlen verwenden.

3. WebAssembly kann viel schneller geparst werden. Dies verbessert nicht die Laufzeit Ihres Programms, aber es bedeutet, dass die anfängliche Ladezeit mit WebAssembly schneller ist.

4. Die Dateigröße von WebAssembly ist kleiner als die Dateigröße von asm.js (ca. 10-20% kleiner).

5. WebAssembly könnte in Zukunft großartige Funktionen erhalten, die asm.js nicht hat (Threads, Parallelität, Null-Kosten-Ausnahmen usw.).

6. WebAssembly könnte in Zukunft Zugriff auf den Garbage Collector von JavaScript erhalten (was bedeutet, dass Sie den Garbage Collector Ihrer Sprache nicht mehr zu WebAssembly kompilieren müssen, was kleinere Dateigrößen bedeutet).

7. WebAssembly wird in Zukunft die Möglichkeit erhalten, JS-APIs (wie das DOM) einfach zu verwenden.

Aber auch in Zukunft wird es notwendig sein, die VM + Runtime Ihrer Sprache in WebAssembly zu kompilieren, so dass die Dateigröße weiterhin ein Problem darstellt.

Wenn das Kompilieren der VM + Laufzeit + Garbage Collector Ihrer Sprache in asm.js für Sie nicht akzeptabel ist, wird es wahrscheinlich auch mit WebAssembly nicht akzeptabel sein.

Und wenn Sie die Sprache des Kompilieren VM + Runtime + Garbage Collector für Sie akzeptabel ist, können Sie bereits das tun jetzt mit asm.js (und dann leicht Übergang zu Webassembly später).

Sind diese Probleme lösbar? zB mit einem neuen Ruby -> Webasm-Compiler und vergleichbare Performance zu aktuellem Browser-JavaScript?

Der Zweck von WebAssembly besteht darin, Programme mit nativer Geschwindigkeit auszuführen. Mit anderen Worten, sie werden mit der gleichen Geschwindigkeit ausgeführt, die sie auf dem Desktop ausführen.

Wenn Sie also Ruby zu WebAssembly kompilieren, läuft es mit der gleichen Geschwindigkeit wie Ruby auf dem Desktop.

Ruby ist eine ziemlich langsame Sprache. Langsame Sprachen und langsame Programme werden immer noch langsam sein, selbst wenn sie mit WebAssembly kompiliert werden.

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

Das ist ein Fehler in Opal, der durch einfaches Ändern der Definition der Funktion $rb_divide behoben werden kann.

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

Das kann behoben werden, indem Opal Strings in JavaScript-Arrays kompiliert (die veränderbar sind).

@Pauan

WebAssembly könnte in Zukunft großartige Funktionen erhalten, die asm.js nicht hat (Threads, Parallelität, Null-Kosten-Ausnahmen usw.).

Thread ist ein sehr wichtiges Feature für viele Sprachen, Bibliotheken und Frameworks. Ohne Thread können viele von c++, c#, Java erstellte Apps, die auf Multithread basieren, nicht einfach in Webapp umgewandelt werden, da dies zu seltsamem Verhalten führen kann (ganz zu schweigen von einer anderen guten Sache wie SIMD Unterstützung _in Zukunft(?)_). Kurz gesagt, ich denke, dass asm.js nicht gut genug ist, weder Leistung noch Portfähigkeit, wenn es so gut ist, sollten vor langer Zeit mehr Bibliotheken auf asm.js "portiert" werden.

Wie alle gesagt haben, Javascript wird nicht nur verschwinden, weil es so beliebt ist und für Legacy-Unterstützung, die meisten Browser werden immer noch die native Ausführung von Javascript unterstützen, aber ich denke, in Zukunft wird jeder, der neue Websites mit Javascript erstellt, es für all diese Leistungssteigerungen zu wasm kompilieren

@unmellow , um diesen Mythos noch einmal zu entlarven: Es gäbe keine magischen Leistungsgewinne durch das Kompilieren von JS zu Wasm, ganz im Gegenteil. Wenn Sie eine bessere Leistung wünschen, als JS-Engines liefern können, müssen Sie eine bessere Sprache auswählen.

Entschuldigung, ich habe vergessen, ich meinte, es würde schneller geparst
Bearbeiten: etwas, das passieren könnte, ist, dass der Browser seine Javascript-Engines nicht aktualisiert, um sie zu unterstützen
neuere Versionen von Javascript Sense konnten ohne Leistungseinbußen nach wasm kompilieren

Ich fühle mich nicht wirklich wohl damit, ein Jahr altes Ticket aufzuwerfen, aber um der Diskussion willen und nur ein bisschen zu schimpfen.

Ich kann sehen, dass viele Leute skeptisch sind, Javascript durch WASM zu ersetzen, aber eine Sache ist, dass es bei WASM nicht nur um Leistung geht. Was die Leute meistens vergessen, ist, dass Javascript nicht die Sprache ist, die sie wollen (oder wollten). Ich meine, zumindest ist das Barebone- Javascript nicht das, was die Leute wollen. Immer mehr Leute setzen auf Transpiler, die im Grunde Compiler für Sprachen von Drittanbietern sind. Dies ist lediglich so, dass die Leute aufgegeben haben, sich auf Standards zu verlassen und auf Userland(?)-Lösungen umgeleitet wurden.

Aber die Transpilation ist naturgemäß viel schwieriger als die Kompilierung. Das mathematische Problem der Zuordnung einer Sprache zu einer anderen ist nicht immer auf den lokalen Bereich beschränkt. Einige Kontextinformationen müssen auf die andere Seite übertragen werden, und dies richtig zu tun ist ein schwieriges Problem. Aus diesem Grund werden nicht-Javascript-ähnliche Transpiler nicht weit verbreitet (oder warum man sich nicht auf sie verlassen sollte).

Außerdem gibt es ein Problem mit doppelten Bemühungen. Transpiler sind Compiler und Bundler sind Linker. Wir alle haben diese Werkzeuge schon seit Ewigkeiten. Module, Tree Shaking, Code Splitting, Dynamic/Lazy Loading, Asset Management usw. Nichts ist wirklich neu, aber die Leute brauchen neue Tools, um diese Funktionen nur für das Web zu haben, was für Nicht-Web-Lösungen nicht geeignet ist.

Es ist nicht so, dass WASM alles an einem Tag ändern wird. Javascript hat derzeit ein gut aufgebautes Ökosystem, während andere Sprachen dies nicht tun. Ich werde mir Zeit nehmen, bis Javascript wirklich irgendwohin geht, aber es wird auf lange Sicht eindeutig passieren.

Javascript geht in eine meiner Meinung nach schreckliche Richtung, daher begrüße ich einen WASM-Ersatz. Ich denke, obwohl es erhebliche Verbesserungen gegeben hat, wurde ein Großteil der Community und der Richtung in den letzten Jahren irregeführt. Ich würde eine richtige Sprache mehr als begrüßen, um... nicht unbedingt ihren Platz einzunehmen, sondern ein direkter Konkurrent zu sein, damit ich diese neue widerliche Variante von JS und seinen "Frameworks", die aufgetaucht sind, nicht schreiben musste.

@spencerudnick Nie geschriebene Assembly für Leistungssteigerungen, die Sie von C nicht erhalten können?