Das Ziel ist in der Tat, jede Sprache zu unterstützen, aber die Unterstützung jeder Sprache ist ohne große Verzögerungen schwierig. Die WebAssembly konzentriert sich derzeit auf Sprachen, die traditionell im Voraus kompiliert werden, gut mit linearen Heapspeicher arbeiten und keine dynamische Neukompilierung, das Laden von Laufzeitcode oder Speicherbereinigungen erfordern.
Einige dieser Einschränkungen waren dazu da, so früh wie möglich zu einem "Minimum Viable Product" zu kommen (dies geschah in February 2017), und berücksichtigen, was existierende In-Browser-Compiler können.
Beachten Sie, dass der MVP Threads nicht unterstützt. Themen werden kurz danach hinzugefügt.
Python, JavaScript und Ruby können einfach durch Kompilieren eines in C/C++ geschriebenen Interpreters in WebAssembly unterstützt werden. Spätere Versionen von WebAssembly unterstützen JIT-Kompilierung, aber Engines wie V8 müssen WebAssembly als ob es eine neue ISA (z. B. auf gleicher Ebene mit x86-64/ARM/...) sein soll.
C# und Java erfordern ähnliche GC- und Stapelmanipulationsgrundelemente. Das ist auch auf der Roadmap, aber nach MVP, Threads und dynamischer Verknüpfung.
Beachten Sie, dass die Sprachen gut funktionieren, aber die Unterstützung all ihrer Bibliotheken ist ebenfalls schwierig! Wir (Browseringenieure) können gut auf die Unterstützung von Sprachen hinarbeiten, aber wir brauchen Communities, die sich um großartige Bibliotheksunterstützung aufbauen.
Wird WebAssembly JavaScript ersetzen?
Auf Ihren letzten Satz: ja WebAssembly sollte in der Lage sein, viele Dinge zu tun, die JavaScript tun kann, weil es Zugriff auf die gleichen Web-APIs haben wird. Sein Ziel ist es jedoch nicht, JavaScript zu ersetzen: es soll JavaScript ergänzen, das Hinzufügen von Funktionen zu JavaScript vermeiden, um natürlich andere Sprachen zu unterstützen, und eine vorhersehbare fast-native Performance für Low-Level-Sprachen wie C++/Rust bieten.
Halten Sie JavaScript-Entwicklung für Leute, die JavaScript oder kompilieren ähnliche Sprachen zu JavaScript (z. B. TypScript), und entwickeln WebAssembly zu JavaScript coole Sidekick, der andere Sprachen mag.
Schließlich wird WebAssembly even more low-level features unterstützen. Einige von diesen sind für JavaScript nicht sinnvoll, aber existierender Code (z. B. große C++ - Codebasen) setzt voraus, dass diese Merkmale für Korrektheit und/oder Leistung existieren.
Sollten Menschen aufhören, JavaScript zu schreiben und zu WebAssembly wechseln? Nein. Ich erwarte, dass die enge Integration mit JavaScript bedeutet, dass WebAssembly-Module von JavaScript (z. B. ein schneller Bildprozessor) verwendet werden, und vorhandene C++ - Codebasen zielen auf das Web, aber ich sehe JavaScript dying any time soon nicht.
Bedeutet dies, dass JavaScript letztendlich die Sprache der Zukunft sein wird? Da WebAssembly so universell sein soll (es würde fast überall nach den Spezifikationen existieren: https://github.com/WebAssembly/design/blob/master/NonWeb.md) und gleichzeitig JavaScript ergänzen, diese Sprache wird in der Zukunft # 1 sein? –
JavaScript ist die Lingua Franca des Webs. WebAssembly oder JavaScript # 1 ist nicht wirklich ein Ziel, zumindest nicht für mich. Wir wollen verbessern, was die Web-Plattform tun kann, ohne JavaScript zu belasten und ohne WebAssembly wegen des Designs von JavaScript zu kompromittieren. Wir möchten, dass diese Plattform aufgrund der Geschwindigkeit, Portabilität und Sicherheitsaspekte auch außerhalb von Browsern nützlich ist. Erfolg in diesen Metriken gibt es, was IMO ausmacht. –
Dies ist in der Tat ein brillanter Ansatz. Ich bin sehr aufgeregt darüber! –