Im
letzten Artikel über WebAssembly habe ich folgende Aussage gemacht:
Einige vergleichen WebAssembly mit Java-Applets. In gewissem Sinne haben sie Recht, aber andererseits irren sie sich sehr. Irgendwie werde ich einen Artikel über die Unterschiede schreiben, aber jetzt wollen wir über die Ähnlichkeiten sprechen. In gewisser Weise ist WebAssembly eine andere Möglichkeit, um das zu erreichen, wofür die JVM gedacht war: Es ist eine gewöhnliche virtuelle Maschine für plattformübergreifende Software.
Viele Menschen haben Interesse an diesem Thema bekundet, schauen wir es uns also genauer an! In diesem Artikel vergleichen wir WebAssembly mit drei Technologien: Flash, Java-Applets und ein
wenig mit PNaCL. Der Artikel konzentriert sich auch auf die Verwendung im
Web , obwohl wir uns zuvor mit der Verwendung von Optionen für die Offline-Verwendung von WebAssembly befasst haben. Aber über einen
solchen Vergleich werden wir später sprechen. Schließlich ähnelt dieser Artikel dem Essen von Tapas [spanischer Snack mit vielen verschiedenen Zutaten - ca. per.], hier sind ein paar kleine Abschnitte. Es scheint mir, dass es etwas kurz ist, aber gleichzeitig versuche ich zu bloggen. Wenn ich es weiter ausbaue, wird es ewig dauern, also tut es mir leid.
Ich denke, ein Vergleich mit Flash- und Java-Applets ist ganz
natürlich, wenn Sie auf diese Beschreibung von WebAssembly stoßen:
WebAssembly (kurz Wasm) ist ein binäres Befehlsformat für eine gestapelte virtuelle Maschine. Wasm wurde als portable Version zum Kompilieren von Hochsprachen wie C, C ++ und Rust entwickelt, mit der Sie Client- und Serveranwendungen im Internet bereitstellen können.
Dies ist ein bisschen wie in der Vergangenheit. Es ist logisch zu vergleichen, wie sie verbunden sind, und kleine Unterschiede zwischen ihnen vorzuschlagen. WebAssembly unterscheidet sich jedoch aus mehreren Gründen erheblich.
Wasm besiegt
Der erste Grund, warum WebAssembly anders ist, ist, dass es erfolgreich war, während frühere Technologien dies nicht taten. Ich meine Sieg in einem bestimmten Sinne. Wenn Sie die Anzahl der Flash-Anwendungen und die Anzahl der WebAssembly-Anwendungen vergleichen, wird Wasm wahrscheinlich verlieren. WebAssembly-Anhänger müssen hart arbeiten, um diese Plattform zu verbreiten.
Wenn ich über den Sieg von WebAssembly spreche, meine ich, dass es Teil der Webplattform geworden ist. Flash, Java-Applets und PNaCL arbeiteten über Plugins. In gewisser Weise befanden sie sich
außerhalb des Web-Ökosystems. Sie wurden nie in den Standard aufgenommen, und das ist sehr wichtig.
In gewissem Sinne ist eine solche Erklärung ausreichend. Nur auf eine Tatsache hinzuweisen, bedeutet jedoch nicht, ihre
Ursachen zu erklären. Der Rest dieses Artikels wird versuchen herauszufinden,
warum dies passiert ist: warum WebAssembly erfolgreich war, was andere Technologien nicht konnten. Hier hängen
viele Gründe zusammen, aber ich versuche, sie vernünftigerweise in separate Punkte zu unterteilen.
Andere Technologien passten nicht in die Plattform
Erinnerst du dich daran?
Oder ist es?
Wie wäre es damit?
Ein Applet, das auf diesen Technologien basiert, ist eigentlich keine
Webanwendung . Sie haben eine Webseite mit einem Ausschnitt, und Ihr Applet hat in diesem Rahmen funktioniert. Sie verlieren alle Vorteile anderer Webtechnologien: weder HTML noch CSS noch die Fähigkeit, sich in das Web zu integrieren. Diese Plattformen interagieren nicht mit dem Rest der Plattform im Browser.
Technisch gesehen können sie das , aber in der Praxis wurden diese Technologien unterschiedlich eingesetzt.
Wie unterstützt das Web ein Ökosystem, das sich nicht in dieses integriert? Das wird niemals passieren. Und die Benutzer lehnten dies letztendlich entschieden ab. Zusätzlich zu Spielen
hassten Benutzer Flash und Java-Applets waren schwer und langsam. Diese Technologien sind in der Webplattform nicht verankert.
WebAssembly hingegen ist JavaScript viel näher. Tatsächlich nimmt Wasm Ihnen keinen Teil des Bildschirms weg. Er erschafft keine eigene kleine geschlossene Welt. Jetzt mit JavaScript und
in Zukunft allein kann es mit der Umgebung interagieren. Er passt einfach ... hinein.
Andere Technologie von Unternehmen
Java gehörte Sun Microsystems, Flash Adobe. Warum ist das wichtig?
Der Einfluss von Unternehmen auf das Internet ist ein komplexes Thema.
Im Allgemeinen arbeitet das Web nach einem Pseudokonsensmodell. Java und Flash hingegen wurden von ihren jeweiligen Unternehmen kontrolliert. Sie haben eine starke Motivation, Gewinn zu machen, nicht das Internet zu verbessern. Dies führte teilweise zu der oben genannten Situation: Diesen Unternehmen war es nicht wichtig, sich ordnungsgemäß in den Rest der Plattform zu integrieren. Warum brauchen sie es? Für Unternehmen ist es viel besser, ihre Plattform zu blockieren und den Rest des Internets vollständig aufzugeben. Die Motivation ist völlig verzerrt.
WebAssembly ist eine gemeinsame Initiative von Mozilla, Google, Apple, Microsoft und anderen. Es fördert nicht die spezifische Plattform einer Person, sondern vertritt die gemeinsamen Interessen einer Vielzahl von Stakeholdern, sowohl von Unternehmen als auch von Einzelpersonen.
WebAssembly folgte dem Webprozess
Unternehmenszugehörigkeit bedeutet
auch , dass diese Technologien nie dem Prozess gefolgt sind, den wir zur Standardisierung des Webs verwenden. Der Prozess der Übernahme von Webstandards ist gut etabliert, aber diese Technologien waren zu groß und funktionierten etwas anders. Im Gegensatz dazu folgte WebAssembly dem Standardverfahren für Webtechnologien.
Asm.js wurde zuerst als Beweis dafür erstellt, dass wir mit dem Web beeindruckende Dinge tun können. Die Ausführung erwies sich als recht hochwertig und demonstrierte die Fähigkeiten der Technologie, obwohl es dort nichts Fantastisches gibt. Der Haupttrumpf von
asm.js war, dass es sich nur um JavaScript-Code handelte: Es ist vollständig kompatibel mit dem vorhandenen Ökosystem. "Das Internet nicht brechen" ist eine sehr, sehr wichtige Regel für Browser-Entwickler.
WebAssembly war eine verbesserte Version von
asm.js Nachdem wir uns über
asm.js kamen alle zusammen, um WebAssembly Wirklichkeit werden zu lassen. Da dies nicht nur JavaScript ist, hätte er den gesamten Prozess zur Implementierung in Browsern durchlaufen und ihn bestehen müssen. Dies ist jetzt die W3C-Spezifikation, die
den Webstandards entspricht, diesen jedoch nicht widerspricht.
Folge: Andere Technologien waren zu groß und instabil
Ein weiterer Grund, warum Wasm erfolgreich war: Es ist winzig. Wasm verfolgt den Ansatz anderer Webtechnologien: Fangen Sie klein an und werden Sie auf dieser Basis größer. Abwärtskompatibel halten. Auch frühere Technologien folgten nicht dieser besonderen sozialen Konvention. Für Flash- und Java-Applets wurde eine bestimmte Laufzeit geladen, sodass keine Kompatibilität erforderlich war. PNaCl basiert auf dem vollständig instabilen LLVM-IR-Code. Sie würden es zu einer stabilen Teilmenge machen, aber wenn sich LLVM ändern würde, würde es eine Diskrepanz geben, die nicht sehr gut ist.
Diese Technologien sind auch zu umständlich, um jemals auf eine Stabilisierung zu hoffen. Können Sie sich vorstellen, dass vier Browserhersteller die JVM-Spezifikationen vollständig definieren und diese Semantik dann für immer akzeptieren? Was ist für ActionScript an sich eine ähnliche, aber unterschiedliche Version von ECMAScript? Für alles LLVM-IR?
Große Technologien stellen ein inakzeptables Risiko für die Situation dar. Dies ist ein Alles-oder-Nichts-Geschäft, und hier ist eine sichere "Nichts" -Wette. WebAssembly hingegen macht fast nichts. Dies ist hauptsächlich Mathematik und ein JavaScript-Aufruf. Das heißt, es ist
viel einfacher, hier zuzustimmen.
Folgerung: Andere Technologien erfordern eine separate virtuelle Maschine
In diesem Artikel habe ich Dart nicht erwähnt, aber es passt auch hierher. Der Satz "Lassen Sie uns einfach die JVM in jeden Browser einfügen" ist das Hauptproblem, dass der Browser
bereits eine JavaScript-Laufzeit hat. Selbst eine Laufzeit ist schwer zu pflegen, ganz zu schweigen von zwei. Und wie integrieren Sie sie?
WebAssembly hingegen ist als kleine Erweiterung vorhandener virtueller JavaScript-Maschinen konzipiert. Sie
können zwar Ihre eigene virtuelle WebAssembly-Maschine implementieren - dies geschieht häufig mit WebAssembly offline, aber für Browser sind die Wartungskosten sehr viel niedriger.
Andere Technologien sind zu spezifisch.
WebAssembly ist grundsätzlich sprachunabhängig. Flash- und Java-Applets wurden hauptsächlich zum Ausführen von ActionScript und Java entwickelt. Sie sind tief mit ihrer relativen Semantik verbunden. Sogar PNaCl leidet in gewissem Maße darunter: LLVM ist wirklich für C-ähnliche Sprachen geeignet, wenn auch nicht ganz in gleichem Maße.
Wollen wir wirklich eine Sprache für das gesamte Internet auswählen? Wir haben bereits JavaScript. Hast du dir jemals eine dritte Sprache vorgestellt? Viertens? Ein unabhängiger Ansatz ist auf lange Sicht viel besser.
Wasm verfolgt einen strengen Sicherheitsansatz
Java-Applets und Flash waren ein wahrer Sicherheitsalptraum. Selbst wenn versucht wurde, sie zu schützen, traten in Wirklichkeit ständig Probleme auf.
Auf der anderen Seite erhielt WebAssembly erneut Boni von der JavaScript-VM: Alle Bemühungen, die Sandbox zu isolieren, gelten auch für Wasm. Hier fehlen einige Funktionen des üblichen Assemblers, was zu Schwachstellen wie der Stapelzerstörung führen kann. Wasm arbeitet sicher mit dem Gedächtnis, was sehr wichtig ist!
Darüber hinaus wurde WebAssembly ursprünglich mit dem Gedanken der
Validierung entwickelt : Es ist vollständig typisiert und Programme können überprüft werden, ohne dass Code ausgeführt wird. Die Spezifikationen enthalten Anweisungen zur Durchführung einer solchen Validierung. Das ist sehr nützlich!
Fazit
Zu diesem Artikel möchte ich folgendes sagen: Er ist aus Sicht des
Entwicklers geschrieben . Entwickler sind jedoch wichtig, weil sie das Web steuern. Technologie muss mit ihren Zielen übereinstimmen - dies ist ebenso wichtig wie die Bequemlichkeit für Endbenutzer. In einem zukünftigen Artikel werde ich versuchen, die Probleme aus Sicht der Benutzer zu analysieren. Muss viel schreiben!
Zusammenfassend:
- Andere Technologien wurden nicht in die Webplattform integriert, was durch kommerzielle Interessen behindert wurde.
- Andere Technologien erforderten zu viel: Viele mussten bei der Implementierung Opfer bringen.
- Wasm hat eine wirklich gute Sandbox-Isolierung und -Validierung, die andere einfach nicht hatten.