Transcript

[0:00] Aus welchen Programmiersprachen heraus lässt sich nach Wasm compilieren? Also C++, Rust?
Rust, tatsächlich, ja, Go, Java, C Sharp mit Blazor natürlich ist ganz vorne dran.
Mittlerweile gibt es aber auch für PHP und Python.
Stefan Baumgarten, aber auch Rainer Strohbeck, die haben mich da in Rust sehr gepusht.
Rust ist einfach für mich so der nächste Schritt nach C++, plus systemnahe Programmiersprache, die halt sich unfassbar leicht nach WebAssembly portieren lässt oder kompilieren lässt.

[0:34] Music.

[0:56] Revision 601, danken euch tausendfach für die Unterstützung und fürs weitere Zuhören.

[1:33] Wir sind heute nur zu zweit. Aus dem Team wäre nur ich dabei, der Shep.

Revision 601: WebAssembly - Vergangenheit, Gegenwart und Zukunft

https://workingdraft.de/601/

[1:38] Und das bedeutet, wir haben wieder eine Gästin am Start, und zwar die Martina Kraus. Hallo Martina.
Hallo, ich freue mich total hier zu sein. Ja, welcome back, sage ich nur.
Genau, welcome back nach langer Zeit, glaube ich. Ich weiß nicht mehr genau, wie lang das her ist. Ich google das Das ist jetzt mal ganz spontan.
Schon über ein Jahr her, definitiv. Ja, auf jeden Fall, mindestens.
Und wir haben damals über Angular, glaube ich, gesprochen. Genau, TypeScript auch so im Speziellen.

[2:08] Genau, und du hast es ja gerade gesagt, das ist schon eine ganze Weile her.
Deswegen die Frage an dich. Magst du noch mal kurz sagen, wer du bist? Was du so machst?
Na klar, gerne. Ja, ich bin Martina. Ich komme aus dem schönen Karlsruhe, so ein bisschen südlich in Deutschland.
Ich bin als selbstständige Softwareentwicklerin unterwegs, halte aber auch gerne Vorträge, weil ich mich gerne reden höre, Workshops, alles rund um WebAssembly, Angular und auch schon seit mehreren Jahren jetzt speziell im Thema Security weiterentwickelt und auch dort Consultant, Beratung, alles rund um das Thema Security, weil das natürlich mit der Entwicklung der SBAs auch immer wichtiger geworden ist. Mhm.
Sehr cool. Letztes Mal haben wir auch über SPAs gesprochen und über Angular und TypeScript.
Heute ist unser Thema XML, MathML und SVG.
Das haben wir ja gesagt im Glücksrad, dass wir hier so einen Themenschwenk jetzt mal machen wollen im Podcast.
Die Sache mit WebAssembly im Titel, das ist wahrscheinlich nur ein Vertipper gewesen. Nee, Quatsch. Also wir machen natürlich, wir sprechen über WebAssembly heute.
Das haben wir schon mal gemacht, zweimal sogar. Aber das letzte Mal ist auch schon wieder dreieinhalb Jahre her.

[3:29] Und seitdem hat sich wieder einiges Neues getan. Und da dachten wir, könnten wir dieses Thema ja nochmal beleuchten.
Ja, auf jeden Fall.
Vielleicht starten wir nochmal mit so einem kleinen Recap. was WebAssembly denn überhaupt ist.
Ich denke mal, den Namen hat man schon gehört und dass das irgendwas Krasses ist, ist vielleicht auch noch mal hängen geblieben. So was für Pros.
Aber genau, was ist es denn eigentlich wirklich?

[3:58] Genau, dann starten wir einfach mal der kleinen Einführung noch mal.
WebAssembly ist eigentlich einfach nur Bytecode für das Web.
Der Grundgedanke ist, dass sich jegliche Art von Programmiersprache zu einer Art Binärformat kompilieren kann, das dann der Browser plötzlich ausführen kann.
Und der Gedanke ist natürlich super.
Viele freuen sich dann schon, dass man kein JavaScript mehr braucht. Endlich.
Das stimmt leider so nicht ganz, weil wir für die UI brauchen wir weiterhin HTML und CSS.
Vielleicht ja auch bald nicht mehr, wie ich gerade gehört habe.
Und dafür brauchen wir halt noch so eine Art Brückencode, was immer noch JavaScript ist. Oft bekomme ich aber die Frage, was ist der Unterschied zu Java Applets oder gerade Silverlight, Flash?
Und der größte Unterschied ist, dass WebAssembly nativ im Browser vorhanden ist.
Das heißt, es ist spezifiziert durch das World Wide Web Konsortium und implementiert in sämtlichen Webbrowsern.
Das heißt, ich kann einfach so ein Binär-Code, also ein WebAssembly-Modul letztendlich kompilieren und es einfach in meinen Browser laden und es funktioniert.
Ich brauche keine Plugins, die mir das erst ermöglichen, dass ich jetzt mein Java als Applet irgendwie im Webbrowser ausführen kann.
Und das bringt natürlich ja einige Vorteile, gerade wenn halt viele Entwickler ihre native Applikation vielleicht irgendwie doch als eine Art Web-Anwendung in den Browser bringen möchten.

[5:26] Genau, wenn ich das richtig verstanden habe, ist ja WebAssembly eigentlich im Prinzip das, was die Browser intern ja auch aus interpretiertem JavaScript im Prinzip basteln.
Also die wandeln das ja oder die kompilieren das ja auch in nativen Bytecode, einfach um das schneller zu machen.
Und das Ganze wird dann flankiert von diesen ganzen Array-Buffern und so Zeugs, mit denen man dann im Grunde genommen so Konstrukte aus C++ und Co.

[6:02] Nachmodellieren kann, letztlich, oder emulieren kann, sodass dann der Programmcode denkt, ey, cool, ich bin in einer entsprechenden Umgebung.

[6:11] Genau, ganz richtig und du sprichst es auch schon an.
Ich beschäftige mich auch sehr stark mit der V8-Engine, das ist die JavaScript-Engine in Chrome oder in Chromium-basierten Webbrowsern und da ist es ja Ignition und TurboFan, die beiden Compiler und Interpreter, die JavaScript letztendlich handeln und tatsächlich der Compiler, der kann dann letztendlich auch WebAssembly kompilieren und dann letztendlich ist das alles derselbe Bytecode zum Schluss.
Und du hast es auch schon angesprochen, beide teilen sich dadurch auch denselben Speicher letztendlich im Webbrowser.
Das Ganze nennt man linearer Speicher. Das ist dann ganz cool, weil im Browser steht dann halt so ein linearer Speicher für WebAssembly zur Verfügung.
Wenn ich halt irgendwas austauschen möchte zwischen JavaScript und WebAssembly, dann übergebe ich lediglich die Größe des Areas oder des Objektes letztendlich und die Speicheradresse.
Und das ist tatsächlich auch schon wie Objekte, sage ich mal, zwischen dem WebAssembly-Modul und JavaScript ausgetauscht werden können.
Und das ist relativ simpel und wird uns aber tatsächlich von den ganzen Compilern aber auch abgenommen.
Das heißt, wir müssen uns nicht wirklich darum kümmern, jetzt die Speicheradresse herauszufinden und zu übergeben. Das war vor drei Jahren so, aber mittlerweile ist es glücklicherweise etwas abstrahiert von gewissen Frameworks.
Eine der Neuerungen, auf die wir bestimmt gleich noch zu sprechen kommen.

[7:37] Genau, und der Grund, warum man WebAssembly jetzt, warum das besser ist, also wir haben ja gerade gesagt, hier Ignition und vor allem TurboFan, die kompilieren das ja selber auch, also JavaScript auch so in diesem Bytecode. Das heißt also...

[7:53] Und der Vorteil von Wasm liegt dann im Grunde darin, dass man sich Schritte spart, weil die man sozusagen im Grunde wie so, wie wenn man vorab gezippte Sachen auf dem Web-Server ablegt, da muss man das nicht on the fly irgendwie zippen und man kann das vielleicht dann auch einfach noch ein bisschen optimieren und man kann Konstrukte vielleicht auch da reinweben, die man mit JavaScript so wahrscheinlich gar nicht beschreiben könnte derzeit, oder?

[8:21] Absolut. Du hast es schon angesprochen. WebAssembly ist tatsächlich von der Performance her so schnell wie nahezu nativer Bytecode.
Es ist bereits kombinierter Bytecode und dadurch ist das Bundle, sage ich mal, dementsprechend auch kleiner, als wenn ich textuelles JavaScript irgendwie in den Webbrowser laden muss.
Und dann muss das Ganze nicht erst noch irgendwie zum Abstract Syntax Tree und der Interpreter und dann der Compiler und dann kann es erst ausgeführt werden, obwohl man auch hier tatsächlich vielleicht sagen muss, dass das VA-Team unfassbar einen guten Job macht, um diese Execution Speed von JavaScript zu erhöhen.
Also, wenn man nicht gerade dagegen arbeitet, das kann man nämlich, wenn man JavaScript schreibt, auch, Aber wenn man eigentlich auch performantes JavaScript schreibt, dann ist man eigentlich schon nahezu so schnell wie WebAssembly, aber es ist natürlich viel einfacher, mit WebAssembly performanten Codes zu schreiben letztendlich, weil es eben bei JavaScript auch so einfach ist, jetzt blöden, blödsinnhaften Codes, sage ich mal, zu schreiben, ohne dass es halt eben leichter ist.
Schon allein, wenn man keinen TypeScript jetzt in dem Sinne auch verwendet, zur Entwicklungszeit zumindest.

[9:38] Da können wir vielleicht noch mal auf das Blog von den V8-Machern hinweisen, die auch regelmäßig irgendwie zu neuen Releases beschreiben, was sie optimiert haben.
Manchmal ist es irgendwie irgendwelche Array-Methoden, die irgendwie schneller laufen oder was weiß ich.
Solche Dinge sind sehr nerdy und interessant auch.

[9:58] Und einen weiteren Vorteil, den man immer außer Acht lässt, ist, dass wir als JavaScript-Entwickler halt, Ich mag jetzt die Bildverarbeitung machen und dann gehe ich auf ein NPM Registry und suche mir halt irgendeinen JavaScript-Bibliothek oder irgendeinen JavaScript-Code, der für mich zum Beispiel Filter auf ein Bild draufsetzt oder irgendwelche Effekte.
Und das Coole ist, jetzt mit der WebAssembly-Welt kann ich ja zum Beispiel auch mal schauen, ob es eine C++-Lib gibt, die sowas schon macht oder eine Rust-Lib.
Ich meine, C++ hat schon ein paar Jahre länger mit Bildverarbeitung zu tun gehabt als JavaScript und kann es in dem Sinne vielleicht auch ein bisschen performanter und auch schon, ich nenne es mal, battle-proofen.
Und jetzt mit WebAssembly können wir einfach sagen, hey, nehme ich den C++-Code, kompiliere den zu WebAssembly und integriere diese einzelnen Algorithmen in meinen Webbrowser und rufe die von JavaScript auf.
Ich habe also, wenn wir mal das Performance mal außer Acht lassen, habe ich auch einfach eine viel größere Ökosystem, der sich jetzt zugreifen kann.
Das heißt, ich bin nicht nur auf das JavaScript-Ökosystem beschränkt, sage ich jetzt mal, sondern kann einfach auch C++-Libraries verwenden oder Rust.

[11:12] Welche Programmiersprachen oder aus welchen Programmiersprachen heraus lässt sich nach Rust kompilieren, also C++?
Rust? Gibt es noch mehr?

[11:51] Kompiliert werden kann. Also LLVM ist ja dieses riesige Umbrella-Objekt für Debugger, für Frontend und Backend-Compiler.
Also es ist so eine Art, weiß ich nicht, standardisiertes quasi Austauschformat, könnte man das so nennen? Genau, richtig.
Und alles, was im LLVM so einen Frontend-Compiler hat, wozu ja Python und Go und auch PHP dazugehört, kann automatisch dadurch auch zu WebAssembly kompiliert werden, weil LLVM den entsprechenden Backend-Compiler zu Intermediate-Code, LLVM-Intermediate-Code, zu WebAssembly mitbringt.
Okay. Das habe ich nämlich nie verstanden früher, was die Rolle von LLVM, wie heißt das?
Das eine ist irgendwie Clang, ist auch noch so ein Compiler?
Clang, genau. Clang ist der Frontend-Compiler für C++ und C.
Ja, dann gab es noch irgendeinen anderen, der irgendwie immer am Start ist.
GCC vielleicht gibt es noch. Ja, vielleicht, ja. Also das sind so die beiden C++C-Compiler.

[12:51] Nichtsdestotrotz gibt es natürlich einige Programmiersprachen, die sich besser eignen, sage ich jetzt mal, für die WebAssembly-Kompilierung als andere, was zum Beispiel schlichtweg damit zu tun hat, dass in WebAssembly es bisher leider noch keine Nativ-Unterstützung für Garbage-Collection gibt, also automatisierte Garbage-Collection.
Damit ist es natürlich ein bisschen schwieriger für Sprachen wie Java und C-Sharp jetzt nach WebAssembly zu kompilieren und de facto ist es tatsächlich so, was das .NET-Team da letztendlich macht, die ganze Mono-Runtime inklusive der automatischen Garbage Collection mit nach WebAssembly zu kompilieren und da dann die ganzen selbstgeschriebenen DLLs mit reinzupacken.
Was dann leider bedeutet, dass dieses WebAssembly-Modul halt irgendwie 50 Megabyte groß ist.
Ja, weil man seine Runtime auch leider mitliefern muss, ne?
Genau. Kann man machen. Und deshalb eignen sich natürlich Sprachen wie Rust, C und C++ eigentlich bisher Status Quo am besten halt nach WebAssembly zu kompilieren, weil die natürlich ihr ganz eigenes Memory Management haben in dem Sinne. Ja.

[14:02] Genau, und man kann ja wohl auch, wenn man irgendwie, wie soll man sagen, wenn man ein bisschen masochistisch veranlagt ist, dann gibt es auch, glaube ich, WasmScript noch, wo man dann, oder gibt es das nicht?
So eine WasmScript-Sprache, die... Also es gibt eine textuelle Repräsentation.
Ja, genau, ich glaube, die meine ich. Ja, genau, das ist Bust.

[14:27] Genau, das ist ja eine Stack-basierte Runtime letztendlich, WebAssembly.
Und wenn man Lust hat, kann man diese textuelle Repräsentation selbst schreiben.
Aber ich meine, das ist wie Assembler-Code selbst zu schreiben.
Das ist natürlich, wie du sagst, wenn man mal so ristig veranlagt ist.

[14:45] Nichtsdestotrotz ist es immer cool, es mal gesehen zu haben und vielleicht mal ein paar Zeilen selbst zu schreiben, weil es, wenn man sich wirklich dafür interessiert und tiefer einsteigen will, hilft sowas natürlich immer, das Ganze zu verstehen, die Datentypen hintendran zu verstehen, wie das alles zu verarbeiten ist, aber Spaß macht es natürlich nicht, sind wir ehrlich, also Spaß ist was anderes, bin ich gerne bei einer High-Level-Language dann, wie zum Beispiel Trust.
Das ist mehr so Jugendforscht, ne? Genau, genau, auf jeden Fall.
Aber es ist cool, um mal wirklich deep dive zu verstehen, wie WebAssembly funktioniert.

[15:19] Genau, und du hast ja auch gerade gesagt, also dank WebAssembly hat man eben, kann man sozusagen auf ein viel größeres Ökosystem an bestehender Software zurückgreifen.
Das geht natürlich jetzt nicht pauschal, man kann nicht irgendwie alles dann nutzen, aber eben man hat mehr Optionen.
Und unser Gast, der das letzte Mal über WebAssembly hier gesprochen hatte, Surma, der hat damals mit ein paar anderen die Squoosh-Web-App rausgebracht und das ist so ein Beispiel dafür, wo die das eben gemacht haben.
Das ist ja eine App, wo man Bilder reinwirft und die dann nochmal so richtig so alle Bytes rausquetschen kann und in andere Formate, also WebP und A-Wiff umwandeln kann und da haben die im Hintergrund, eben auch auch entsprechende Bibliotheken, See-Bibliotheken nach Wessum portiert.
Das ist tatsächlich mega spannend und mega cool.
Mittlerweile gibt es hier so viele Adaptionen von WebAssembly.
Ich denke mal, die berühmteste oder bekannteste ist Adobe Photoshop.

[16:28] Adobe hat ja seinen kompletten Photoshop-Software in den Browser portiert, mithilfe von WebAssembly. Das heißt, alles, was wir da an Bildverarbeitung letztendlich vollziehen, ist hintendran letztendlich ein WebAssembly-Modul.
Google Earth, alles, was so 3D-Simulation ist, ist ebenfalls letztendlich ein WebAssembly-Modul hintendran. Twitch, Videostreaming, benutzt WebAssembly.
Google selbst hat einige Produkte. Alles, was halt so mit Kryptografie, so rechenintensive Aufgaben, Videoverarbeitung, Musikstreaming, Amazon Music ebenfalls.
Das kann man auch ziemlich cool mal nachverfolgen, wenn man mal wirklich auf Amazon Music geht oder auf Google Earth geht und im Network-Tab kann man einfach mal nach was und filtern und dann sieht man, wie viel Webseite und wie viele Tools eigentlich WebAssembly schon benutzen.

[17:23] Mittlerweile natürlich mit der ganzen AI ein ganz großer Use Case, ebenfalls für die ganzen Modelle.
Die ganzen Datenmodelle, die ganzen Transformationen, die wir in der AI jetzt benötigen, setzen natürlich ebenfalls auf WebAssembly.
Weil auch da natürlich die ganzen Berechnungen der Large Language Models ebenfalls natürlich ziemlich rechenintensiv sind, sage ich mal.
Und auch das liegt dann ebenfalls als WebAssembly-Modul vor. Mhm.
Gibt aber nicht ein Browser-Plugin, das einem dann so anzeigt, wenn eine Seite Wasm geladen hat, oder? Das wäre auch noch cool.
Das gibt es ja manchmal für so bestimmte Dinge.
Das stimmt. Ist eigentlich eine coole Idee. Das ist mir zumindest nicht bekannt, aber vielleicht.
Vielleicht gibt es das tatsächlich schon. Wahrscheinlich würde man dann auch tatsächlich so, ui, das ist ja wirklich hier Wasm, da Wasm.

[18:10] Das ist wahrscheinlich eine coole Idee. Ich habe sowas schon mal für Angular geschrieben.
So ein kleines Plugin, um halt zu erkennen, was für eine Version und welche Webseite in Angular implementiert ist.
Sowas kann man wahrscheinlich auch relativ simpel für WebAssembly schreiben.
Das ist eine coole Idee. Das nehme ich vielleicht mal auf. Ja, ich bin gespannt.

[18:57] Dann haben wir aber vorhin einmal kurz noch, bevor wir quasi die Browser verlassen, da hast du gesagt, dass sich in den letzten drei Jahren hinsichtlich dieser UASM zu JavaScript-Brücke oder quasi der Kommunikation, dem Datenaustausch, dass sich da einiges Neues getan hat.
Es gab irgendeine API, die da, glaube ich, in der Mache war.
Ich glaube, letztes Mal haben wir da auch drüber gesprochen.
Ich vermute, dass die das ist oder ein Interface oder sowas.
Wasi, WebAssembly System Interface. Ja, genau, Wasi, genau. Wobei Wasi jetzt tatsächlich nichts so konkret mit dem Browser zu tun hat, sondern wenn ich WebAssembly dann auf meinem Desktop-PC irgendwie ausführen möchte.
Es ist eine System Interface sozusagen, was dann die ganzen System Calls quasi zu meinem WebAssembly-Modul weiterleiten soll.
Oder auch, wie ich auf Netzwerke, wie ich auf gewisse Betriebssystem-Funktionalitäten zugreifen.
Also so ein bisschen wie hier, wie ist denn diese Umgebung von Adobe und vielleicht auch so hier in dem Slack auch gemacht ist, also Elektron ja genau sowas. Genau.

[20:12] Tatsächlich ist es eher vergleichbar mit dem ELF-Standard, Executable and Linkable Format.
Also, das ist ja quasi der Standard, wie Dateien in den Stack geladen werden, wie Daten quasi in die Register geladen werden. Das heißt, noch mal eine Ebene tiefer.
Also es geht wirklich konkret darum jetzt zu sagen, dass ich jetzt mein WebAssembly-Modul ist jetzt wie so eine Desktop-Anwendung im Prinzip und irgendwie will ich dieser Desktop-Anwendung ja, wie wird die geladen, wie erlaube ich dieser Desktop-Anwendung Zugriffe auf mein Filesystem, weil ich will ja nicht, dass jetzt dieses WebAssembly-Modul jetzt überall drauf Zugriff hat.
Also wie diese Brücke sozusagen, das beschreibt dieses WebAssembly-System-Interface.
Und da gibt es dann halt verschiedene Runtime-Implementierungen.
Dazu können wir dann noch später noch kommen.
Wasma ist Wassentime und Wassma sind so die bekanntesten.
Aber wie du auch schon gesagt hast, das können wir gleich besprechen.
Wir können noch mal rübergehen zu, was sich im Webbrowser jetzt die letzten drei Jahre so getan hat.
Und da bin ich tatsächlich die letzten drei Jahre ein sehr großes Rust-Fangirl geworden.

[21:26] Tatsächlich da auch noch mal ein Shoutout an euren Kollegen Stefan, der ja auch sehr viel damit macht.
Stefan Baumgarten, aber auch Rainer Strohbeck, die haben mich da in Rust sehr gepusht. unterbewusst wahrscheinlich.
Rust ist einfach eine sehr, sehr, für mich so der nächste Schritt nach C++, Systemnahe Programmiersprache, die halt sich unfassbar leicht nach WebAssembly portieren lässt oder kompilieren lässt.
Denn das Problem an so C++-Anwendungen ist halt weiterhin, dass es halt so viel Legacy-Code gibt und es braucht quasi so eine Art portierbare Funktionalität, die das dann in der Media-Language, die daraus der Frontend-Compiler kompiliert, eben nach WebAssembly sich kompilieren lässt in dem Sinne.
Und das ist halt bei C++ oft so, dass man sehr viel mit dem bestehenden Code noch anpassen muss und vielleicht neuere Funktionen oder neuere Libraries nutzen muss, damit ich das Ganze überhaupt vernünftig kompilieren kann, letztendlich.
Das heißt, vielleicht auch eins vorweg, ich kann nicht einfach nur sagen, oh, kompilier nach WebAssembly und alles funktioniert.
Ich muss sowohl den Rust C, C++-Code, auch den Java-Code, ich muss den immer ein bisschen vorbereiten.
Und eine Vorbereitungssache ist halt zum Beispiel überhaupt zu sagen, welche Funktionen sollen überhaupt ansprechbar sein von meinem JavaScript.

[22:53] Und genau da hat sich in dieser Brücke, in dieser Kommunikation zwischen JavaScript und dann dem WebAssembly-Modul hat sich einiges getan.
Und nach meiner persönlichen Meinung hat sich da am meisten im Rust-Ekosystem getan.
Da gibt es zum Beispiel Wasmpeg.

[23:12] Wasmpeg ist jetzt in dem Sinne die Runtime oder der Compiler letztendlich auch von letztendlich Rust zu WebAssembly.

[23:23] Und was es darüber hinaus ebenfalls gibt, sind dann sogenannte Rust Crates.
Das sind die NPM-Packages, wenn man so will, für Rust.
Und da gibt es zum Beispiel ein Crate, der nennt sich was im Bindgen.
Und das ist letztendlich, wer sich jetzt mit Rust auskennt, der versteht das sicherlich leichter.
Was ein Beinchen ist eigentlich eine Art Makro, ein Rust-Makro, das dann eben Code während der Kompilierung halt hinzufügt, was dann der sogenannte Brücken-Code ist für JavaScript.
JavaScript, was dieses Makro letztendlich macht, ist die Funktion, an der ich das Makro packe oder die Klasse, also es kann auch ein Struct sein, also nicht die Klasse, in Rust gibt es ja keine Klassen in dem Sinne, es wird nur zum Schluss in JavaScript eine Klasse daraus erstellt, deshalb habe ich Klasse gesagt, kann ich halt an Konstruktoren und an Structs ebenfalls hinzufügen und dann wird mir halt das JavaScript-Äquivalent letztendlich transpiliert, beziehungsweise kreiert.
Während ich das Ganze da mit Wassernpack kombiniere.
Und was ich ebenfalls bekomme, und das ist ein super geiles Feature nach meiner Meinung, sind TypeScript Bindings.
Das heißt, wenn ich jetzt ein Struct habe und das packe ich jetzt, ich sag mal sehr solopp, einfach mit diesem Makro, verbinde ich das und dann habe ich zum Schluss TypeScript Bindings und habe eine TypeScript Klasse, ich habe Typings.

[24:49] Das ist super cool und ich habe das bisher noch in keiner anderen Sprache so gesehen, wie es halt jetzt in Rust letztendlich ist, mit diesem Wassenbeinchen.
Es gibt sowas ähnliches in C, C++. Da gibt es M-Skripten-Bindings.
M-Skripten ist ebenfalls ein C, C++ zu WebAssembly-Compiler.
Also quasi das C-Äquivalent für M-Skripten. Den hatte ich vorhin im Sinn, genau, M-Skripten. Ah ja, genau, M-Skripten, genau.
Und M-Skripten ist quasi der Compiler für C, C++ zu WebAssembly.
Und auch da hat sich einiges getan.
Ich erinnere mich noch, ich habe es vorhin angerissen, wie ich mal vor ein paar Jahren, zwei oder zweieinhalb Jahren, einen Talk gehalten habe darüber, wie ich ein Objekt von JavaScript zu C++.

[25:35] C-Code war das, glaube ich, damals, übergeben kann.
Und dann musste ich mir selbst so ein Typed Array erstellen, dann dort die Werte kopieren, das Typed Array allokiere ich dann in meinem Browser-Speicher, dann habe ich die Adresse und die Größe dieses Typed Arrays und die beiden Numbers letztendlich, also Integers in dem Sinne, übergebe ich dann an mein C-Modul, was dann natürlich in place dieses Array dann oder dieses Objekt irgendwie manipuliert hat.
Und danach musste ich wieder das Array an der Stelle auslesen, um dann, ich habe damals das genutzt, um mal zu demonstrieren, wie ich ein Array sortieren kann, wie ich einen Quicksort quasi implementieren kann mit C und es halt von JavaScript aus aufrufen kann.
Und das war so umständlich, es hat so viele Zeilen Code benötigt und jetzt rufe ich einfach halt eine Funktion auf, die mir von Wassernbeinchen halt generiert wird und natürlich im Hintergrund funktioniert noch genauso.
Alles noch genauso. Ich übergebe eine Adresse und die Größe, aber es ist halt weg abstrahiert.
Und das macht es so bequem, halt jetzt mittlerweile mit WebSend die Modulen zu laden.

[26:47] Auch letztens erst, ich habe einen Vortrag über WebAssembly gehalten und dann hat mich ein Zuschauer gefragt, ja, aber wie ist das denn jetzt, wo lade ich denn das WebAssembly-Modul in meinen Browser rein?
Dann habe ich ihm die eine Zeile gezeigt mit einem asynchronen Import und so lade ich das WebAssembly-Modul.
Und dann hat er gemeint, ja, aber er hat sich dran erinnert, vor einem Jahr war das irgendwie noch voll komplex, dass ich erst einen Speicher allokieren musste, und irgendwie dann das WebAssembly-Modul erst selbst kompilieren musste und so und dann habe ich auch gesagt, ja, das war damals so, ich musste das alles selbst kompilieren, das in einem Array-Buffer irgendwie letztendlich mir reinladen und dann halt byte für byte selbst kompilieren, diesen Stream, der letztendlich gedownloadet wurde in meinen Webbrowser, Aber das muss man alles nicht mehr.
Und das ist so die größte Entwicklung.
Was schade ist, dass das viele gar nicht so mitbekommen haben, wie einfach das Handling von WebAssembly mittlerweile im Webbrowser geworden ist. Und de facto, und da kommen wir dann vielleicht mal zu der Gegenwart, ist eigentlich so WebSAM wie ein Webbrowser längst Schnee von gestern.
Das funktioniert und alle benutzen es eigentlich schon.
Nur wir, ich sag mal, normalen Entwickler, die jetzt in so einem mittelständischen Unternehmen sind oder auch als Selbstständige, wir trauen uns noch nicht so richtig an WebSAM wie dran.
Aber alle großen, Google, Adobe, Amazon, die benutzen das schon seit Jahren letztendlich.
Tja, woran liegt das? Vielleicht.

[28:17] Die Schwierigkeit, so einen Use Case dafür zu finden, könnte ich mir vorstellen. Also, Ich habe mich mal mit jemandem darüber unterhalten und der hat mir einen sehr interessanten Denkanstoß gegeben, dass es halt ein Shifting ist in zwei verschiedenen Paradigmen.
Also, ich bin jetzt, ich habe jetzt vielleicht C++-Code irgendwie und den möchte ich ins Webbrowser bringen. Ich muss trotzdem erstmal ein Frontend-Framework lernen.
Also, ich brauche ja irgendwo trotzdem die UI.
Das heißt, ich muss mich mit HTML, ich muss mich mit CSS auseinandersetzen und ich muss mich auch mit TypeScript auseinandersetzen.
Und auch wenn ich tatsächlich dann zum Schluss die Business-Logik oder die Algorithmik zwar einfach so kompilieren kann nach WebAssembly, brauche ich trotzdem erstmal Angular oder React oder Vue, was ich lernen muss.
Und dann muss ich mich auch noch mit WebAssembly auseinandersetzen.
Also dann muss ich auch wissen, wie kompiliere ich das eigentlich?
Und wie gesagt, der Code muss vorbereitet werden.
Und dann wirkt es halt so, okay, ich bin eh schon mit drei neuen Sachen überfordert.
JavaScript, eh totale Überforderung, wenn ich von C komme.

[29:28] Styling sowieso. Ich weiß immer noch nicht, wie man Diff eigentlich zentralisiert, oder halt HTML in dem Sinne.
Und das sind halt alles so Sachen, damit ist man eh schon überfordert.
Und wenn dann noch eine vierte Technologie hinzukommt, wie WebAssembly, auch wenn es im Endeffekt, glaube ich, leichter ist und hilfreicher, landen doch sehr viele dann damit zu sagen, okay, ich schreibe einfach mein C-Code in JavaScript um an sich, weil ich dann nicht nochmal extra was lernen muss und mich mit einer Compiler-Toolchain auseinandersetzen muss. Mhm.
Ja, aber ich denke mal, also WebAssembly würde man ja nicht für irgendwelche Dinge nehmen, die sozusagen sehr viel mit der UI machen.
Also da würde sich das wahrscheinlich einfach nicht lohnen, das zu verwenden, weil da ohnehin das DOM, sag ich mal, so der limitierende Faktor ist.
Und das kann man ja dann leider nicht loswerden.
Das heißt also, man braucht im Grunde irgendwas, was vielleicht sehr rechenintensiv ist, dem man einmal was rüberwirft und das dann erstmal eine Weile drauf rumdenken kann, um dann die Rückmeldung zurückzugeben.
Also eine Weile drauf rumdenken kann dann auch weniger als eine Sekunde sein, aber so in Computerzeit gerechnet ist das ja dann lange.

[30:55] Ja, auf jeden Fall. Genau, also so Bildverarbeitung und so, was du schon so gesagt hast oder Audio, Video, Kryptografie, 3D-Simulation, all das sind perfekte Use Cases tatsächlich auch für den Webbrowser.
Aber es ist ja auch nicht nur der Punkt.
Ich habe lustigerweise gerade jetzt in letzter Zeit sehr viele Einsteiger-Angular-Workshops gehalten, in dem dann Teilnehmer und Teilnehmerinnen saßen, die dann von ihrem Management gesagt bekommen haben, hier, ihr habt eine alte Java-Applikation oder ihr habt eine alte C++-native Applikation und das Web, dieser Webbrowser, der scheint ja voll cool zu sein.
Deshalb lernt ihr jetzt Angular, damit ihr eure alte Java-Applikation jetzt ins Web bringt.
Das heißt, die Zielgruppe sind ja vielleicht auch nicht nur Web-Entwickler, die jetzt ihre Browser-Applikation performanter machen wollen, weil sie jetzt eine Rust-Library zum Beispiel suchen für Bildverarbeitung, sondern eben auch der Schritt zu sagen, hey, du musst jetzt nicht.

[32:02] Nicht das ganze Team muss jetzt vielleicht Angular lernen, sondern ja, ein paar sollten dann Ahnung von Angular haben, auch von JavaScript, aber der Rest kann sich dann nur darauf fokussieren, wie jetzt die Java-Applikation nach WebAssembly kompiliert wird.
Und dann müssen die gar nicht das gesamte Java irgendwie nach TypeScript portieren, sondern können Teile einfach nach WebAssembly kompilieren und dann wiederverwenden in dem Sinne.
Klar, wie gesagt, die UI, die wird so oder so, die muss neu geschrieben werden, weil, wie du auch gesagt hast, der DOM, das ist halt das, was die UI darstellt im Webbrowser.
Aber die ganze Business-Logik, die kann halt einfach nach WebAssembly kompiliert werden in dem Sinne.

[32:44] Ja, das macht absolut Sinn, dass man sozusagen eine bestehende Anwendung dann in die Neuzeit portiert damit.
Ja. Und genau, der Browser als Runtime ist ja auch insofern toll, als dass im Grunde ja nie Features ausgebaut werden.
Und solange es Browser gibt, man eigentlich davon ausgehen kann, dass die Umgebung dann für immer da ist, in der man das dann laufen lassen kann.
Und das ist ja bei anderen Programmiersprachen nicht immer so klar.
Ja, absolut. Absolut richtig.

[33:25] Okay, genau, aber man kann den Browser ja auch ganz außen vor lassen und Wasm auch für ganz andere Dinge einsetzen.
Genau, da kenne ich mich jetzt weniger aus. Ich kenne nur dieses eine Zitat von einem der Docker-Erfinder, glaube ich, der meinte, genau, also der irgendwie sinngemäß meinte, hätten wir damals gewusst, dass es Wasm geben würde, hätten wir Docker wahrscheinlich gar nicht erst entwickelt.

[33:59] Finde ich sehr cool, dass du dieses Zitat bringst, weil wenn nicht, dann hätte ich es gebracht, weil das immer so mein Aufhänger ist tatsächlich.
Und ja, gerade in den letzten drei Jahren hat man dann klar der Browser war so die erste Anlaufstelle, dass man WebAssembly im Browser nutzen kann.
Aber so jetzt, wo wir uns gerade befinden, sage ich mal in der Gegenwart, Status Quo, wird WebAssembly eben auch verwendet, um halt quasi serverseitig WebAssembly-Module auszuführen.
Das ist im Prinzip so wie Docker, dass ich irgendwie sagen kann, okay, hier, ich habe jetzt mein Node.js, was ich in einem Docker-Image habe und jetzt habe ich irgendwie serverseitiges JavaScript, was ich in dieses Image reinkopiere und dann wird der Container gestartet.
Und der Vorteil von Docker ist ja, dass das auch alles so eine Art sichere Laufzeitumgebung ist.
Also wenn ich den Container einmal habe, den ich ja dann auch zigmal irgendwie spawnen kann, dann bin ich dafür verantwortlich, diesem Container zu sagen, welche Ports und was auch immer ich halt nach außen hin freigebe.

[35:01] Und das Coole ist, jetzt mit WebAssembly, und das war das, was wir vorhin angesprochen haben, dieses WASI, dieses WASM System Interface, dass das eben diese sichere Laufzeitumgebung eben definieren soll, dass eben Runtimes, die dieses System Interface implementieren, eben auch ganz genau bestimmen, wie dieses WebAssembly-Modul geladen wird und was für Rechte es hat.
Das nennt sich auch gerne Capability-basiertes Sicherheitsmodell, dass ich halt sage, okay, diesem WebAssembly-Modul, was braucht es denn?
Ah, das braucht irgendwie Zugriff auf ein Filesystem.
Okay, diese Kapabilität gebe ich ihm jetzt. Aber ansonsten gebe ich diesem WebAssembly-Modul gar nichts.
Und dadurch habe ich halt auch so eine Art Sandbox, wie wir sie von Docker halt lieben und kennen.

[35:52] Aber, und das kann man sich so salopp vorstellen, mit viel weniger Layern dazwischen, viel weniger Schichten. Ich habe kein riesiges Virtualisierungssystem unten drunter.
Ich habe einfach nur diese Wassern-Runtime, die dieses System-Interface implementiert.
Und ich habe es ja schon angesprochen, das ist eher so als Äquivalent von diesem 11-Standard zu sehen, dieses Executable-Linkable-Format, was ja eigentlich die meisten Betriebssysteme ja eben schon unterstützen, sodass man immer weiß, egal was für ein Programm ich habe, dass alle Betriebssysteme jedes Programm starten können, sozusagen.

[36:28] Und so muss es jetzt eben auch mit WebAssembly sein.
Es geht jetzt ein bisschen zu tief, aber bei WebAssembly hat man herausgefunden, das Modul ist halt doch so anders, wie es geladen wird, in was für Register es ausgeführt wird, dass man halt gesagt hat, nee, man muss eine Art eigenes Systeminterface implementieren oder definieren.
Und da hat sich dann auch damals diese Bytecode-Allianz gegründet von verschiedenen Browsern, Microsoft, Chrome natürlich auch, Fastly, Fastly ist auch so eine, ich sag mal Lynn Clark, Lynn Clark war so die WebAssembly-Treiberin bei Mozilla Firefox.
Die hat sich dann irgendwann abgekapselt und sich nur noch auf WebAssembly fokussiert und die ist dann zu Fastly gegangen.
Das Fastly ist auch super, wem das interessiert, kann sich mal mit Fastly ein bisschen beschäftigen.
Die haben dieses ganze Systeminterface auch ziemlich stark vorangetrieben und jetzt sind halt auch die ersten Runtimes erschienen.

[37:28] Also erst, zugegeben, das ist auch schon doch ein paar, schon ein Jahr her, aber die haben diese Runtimes letztendlich vorangetrieben, die dieses System Interface implementieren und da ist so was mehr und was zum Teil sind so die beiden gängigsten, die man jetzt die ganze Zeit gerne verwendet.
Und die können dann halt letztendlich WebAssembly-Code oder WebAssembly-Module einfach serverseitig ausführen.
Das heißt, ich kann jetzt Python-Code haben und den nach WebAssembly portieren und den dann mit Wasma eben auf Desktop-Seite eben ebenfalls ausführen.
Was gleichzeitig eben auch bedeutet, dass dieser Code portable ist.

[38:09] Weil wenn ich jetzt irgendwie C oder C++ Code kompiliere, dann kann das ja auch sein, dass das nur für diese spezielle Architektur eben ausführbar ist, AMD oder x86.
Aber klar, wenn ich jetzt wieder das als WebAssembly-Modul habe, dann könnte ich jetzt eigentlich das auch auf Windows oder macOS, auch verschiedene Architekturen.
Ja, auch diese ganzen Schwierigkeiten, die es ja am Anfang auch, glaube ich, mit Docker und den Apple-M-Chips gab und so, das hätte man dann wahrscheinlich nicht gehabt. Genau, absolut.
Also klar, sicherlich, es gibt Limitierungen von Wassentime und Wasma.
Sicherlich gibt es da auch Dinge, die auf einem Unix-basierten System ein bisschen besser funktionieren.
Aber so grundsätzlich, meine Erfahrung, gerade mit Wasma, ich arbeite viel mit Wasma, ist halt super, super positiv. Positiv.
Und es macht auch richtig Spaß. Und noch cooler ist, dass ähnlich wie Docker Hub, man kennt ja Docker Hub, da gibt es Docker Images und die kann man sich runterladen und dann hat man schon mal ein Nginx zum Beispiel, so ein Base Image, auf das man dann aufbauen kann, ist zwar, glaube ich, letztes Jahr im Dezember, also ist auch schon eine Weile her, ist WasmHub gepublished worden.
Und WasmHub bietet halt bereits fertige Wasm-Module an, auf die ich ebenfalls setzen kann, um halt darauf aufbauend auch noch mein eigenes WebSAMD-Modul draufzusetzen.

[39:39] Und gleichzeitig gibt es auch, es gibt so Wasmer.io.

[39:45] Das ist halt so wie eine NPM-Registry eigentlich oder wie eine Docker-Registry.
Da gibt es halt zig WebSAMD-Module, die halt vielleicht, Da gibt es vielleicht schon einfach ein WebAssembly-Modul, was Bildverarbeitung kann.
Und ich kann mir das einfach runterladen und Servers, also DeskOps halt nicht ausführen und dann habe ich das einfach schon mal.
Und das ist halt schon cool. Auch in C, C++ gibt es mittlerweile zig Libraries, auch Legacy-Libraries, die auch bereits schon längst nach WebAssembly portiert wurden.
Und da kann ich auch nur empfehlen, mal auf wassma.io zu gehen.
Da gibt es dann auch ein WebAssembly-Packet-Manager, Schawappen.
Es gibt eh, es gibt Wassi, es gibt Wassen, es gibt Wast, es gibt Wappen.
Da kann man schon mal durcheinander kommen.

[40:32] Aber genau, da gibt es halt einiges. Und zum Rumspielen, mega cool.
Und dann natürlich auch so wieder den Gedanken zu haben, write once, run everywhere.
Dass ich halt ein WebAssembly-Modul habe, das kann ich jetzt in den Browser packen und es läuft, aber ich kann es auch serverseitig ausführen und es läuft.
Und das ist ist halt super, super cool. Und der Vorteil ist halt bei WebAssembly, wenn ich das mit Wasma laufe, dass es halt wirklich nahezu eine tiefe Geschwindigkeit erreicht.
Auch das ist ein bisschen anders bei Docker, bis das Docker erstmal gestartet ist und dann losrollt.
Du hast halt viel weniger, du hast es ja eben schon gesagt, viel weniger Abstraktionsschichten oder Kompatibilitätsschichten noch dazwischen hängen. Genau, absolut. Absolut.
Ich meine, das sind alles vorkompilierte Binärdateien und die müssen dann einfach nur zum Laufen gebracht werden von der Raspal-Runtime.
Und das ist natürlich nochmal ein bisschen was anderes, als wenn ich erstmal mein Node.js oder meine JVM starten muss und bis das dann erstmal wieder kompiliert ist. Ja, macht Sinn.

[41:43] Und du hast ja gesagt, Fastly ist so ein Player, der da so sehr hinterher ist, diese WASI-Umgebung irgendwie zu weiterzubringen.
Wäre das dann auch ein Hoster, auf dem man WASM ...
Ja, im Prinzip sind die ja ein CDN, glaube ich, eigentlich. Oder zumindest sind die daher ein Begriff.
Und dann könnte man aber auch, also bieten die dann auch sozusagen WASM-Hosting an in diesen Runtimes, also so Docker-like.
Genau, genau. Wie du es auch gerade zu CDN, Corner Delivery Network artig, dass ich halt dort mein BASM letztendlich hosten kann und es halt von dort relativ schnell dann auch in meine Web-Applikationen fetchen kann in dem Sinne oder auch downloaden kann. Genau.
Okay, aber es ist nicht so, dass du quasi, also es ist nicht so, dass einfach nur dein Backend-Code so wie ein Docker-Container dann auch bei denen gehostet laufen würde, wo dann dein Web-Server drin steckt oder sowas. Das machen die nicht.

[42:55] Soweit ich es verstanden habe, nein. Vielleicht ist es mittlerweile auch schon wieder anders, aber soweit mein letzter Stand ist es mehr so ein CDN.
Gibt es denn da Hoster, die das machen, was ich so gerade so vor Augen habe?
Im Prinzip, was du schon denkst, ist so ein bisschen Function as a Service.
Also so in der Richtung, dass ich mein WebAssembly-Modul jetzt einfach, ja, zum Beispiel wie eine Azure-Function oder irgendwie in AWS irgendwie hoste.
Und es wird dann ausgeführt bei Anfrage letztendlich und dann wird der Code eben ausgeführt.
In die Richtung geht es dann tatsächlich eher.
Okay, ja. Da gibt es ja, glaube ich, viele Anbieter, die das machen.
Also so Cloudflare, glaube ich, oder nicht? Genau, genau.
Cloudflare, also gut, es gibt so was im eigenen, was im Edge gibt es da, was im Cloud. AWS natürlich auch, Azure Function.

[43:57] Weil ich habe tatsächlich jetzt gerade nochmal, weil ich mir selbst unsicher war, habe ich gerade nochmal ganz kurz auf Fastly geschaut. Tatsächlich bietet Fastly auch sowas an.
Zwar ich bin nämlich selbst gerade sehr unsicher, weil ich Fastly so nur als CDN bisher verwendet habe, aber Fastly kann auch dafür verwendet werden.
Dann revidiere ich das, was ich gerade gesagt habe. Ja, macht ja auch Sinn dann, wenn die da so involviert waren.
Die müssen ja irgendwas verfolgen sozusagen. Die sind ja nicht einfach aus Spaß involviert. dann macht das auf jeden Fall Sinn.
Aber AWS Lambda bietet auch eine Ausführumgebung an für WebAssembly in dem Sinne.
Es gibt halt wie gesagt eigene, nur für WebAssembly spezialisierte Hostings.
Es ist dann sowas wie WasmEdge.
Kragen.de gibt es noch.
Habe ich jetzt persönlich noch nicht verwendet, aber taucht auf jeden Fall auf, wenn man auch nach WasmHostings letztendlich sucht.

[44:48] Und würdest du dann irgendwie einen Unterschied sehen, bei denen, die nur auf Wasm spezialisiert sind und die, die sozusagen JavaScript und Wasm Edge Functions anbieten, also von der Performance her ist das wahrscheinlich kein Unterschied, oder?
Nee, also ich kenn's halt, ich hab mit Azure Functions in der BSMD-Integration schon ein bisschen was gemacht. macht.
Letztendlich ist das ja auch einfach nur, also die bieten dann nicht irgendwie eine JavaScript-Environment an, wo ich dann WebSAMPY drauf laufen lasse, sondern das ist dann eine reine WebSAMPY-Runtime, die da dann als Server in das Applikation läuft.
Okay, ich dachte so Cloudflare und Co., die stecken das dann am Ende auch nur in die V8, die da läuft.
Nee, nee, nee, auf gar keinen Fall. Okay. Genau, genau.
Und genau deshalb machst du natürlich keinen Unterschied, ob es jetzt Wasm-Edges, sag ich mal, oder jetzt in dem Sinne Azure Azure Function oder AWS Lambda.
Die bieten dann halt einfach nur an, dass man jetzt keine native Azure Function nutzt, sondern halt eben das Ganze als WebAssembly-Modul halt ausführt.
Und das ist so ein bisschen, um auch den letzten Part vielleicht mal anzubringen, die Zukunft, wo WebAssembly definitiv noch eine große Rolle in Zukunft spielen wird in den sämtlichen Serverless-Applikationen.

[46:09] Alleine schon, wenn man die Startlaufzeit von Azure Functions sieht, dauert das halt schon ewig, wenn man jetzt einen Code an eine Azure Function schickt und bis die mal gestartet ist, bis die dann den Code mal ausführt.
Klar, wir sind natürlich auch in der Webentwicklung oder generell in der Serverseiting-Entwicklung ein bisschen verwöhnt geworden.
Da sehen wir halt eine Sekunde oder zwei schon als sehr langsam an.

[46:35] Aber wenn man das halt jetzt vergleicht mit WebAssembly als Serverless-Alternative, dann sind wir auch da wieder bei denselben Argumenten wie schon auf der DeskOps-Seite.
Dass da halt so viele Schichten einfach wegfallen, weil es schon ein kompilierter Binärcode ist.
Weil halt ein viel, viel geringerer Overload halt einfach beim Starten, dass wir bisher die Moduls letztendlich ausgeführt werden mussten.
Der Binärcode ist so klein auch.
Dadurch werden auch viel, viel weniger Ressourcen benötigt. Ja.
Das heißt, wenn ich jetzt zum Beispiel, gut, das geht jetzt wieder ein bisschen weg von dem Argument, den ich eigentlich bringen wollte, aber passt trotzdem, wenn ich jetzt einen Host habe und da kann ich maximal vier Docker-Container starten, weil mir ansonsten die Ressourcen ausgehen, kann ich natürlich viel mehr stattdessen Wasmer-Module letztendlich starten, weil einfach viel weniger Ressourcen gebraucht werden. Ja.
Und das ist halt dann doch ein Riesenvorteil WebAssembly gegenüber halt so nativen Azure-Functions jetzt zum Beispiel und auch gegenüber generell Docker in dem Sinne.
Vielleicht können wir einmal noch sagen, also für so, wir sind immer noch ein Frontend-Podcast und ich glaube, die vielen Leute kennen ja auch Edge-Functions so aus, von Vercel und Co., aber im Endeffekt sind das einfach nur, da eiern tausende Server rum und man kann denen im Prinzip einmal Code entgegenwerfen.

[48:03] Entweder man macht das proaktiv oder irgendwie gibt es bestimmte Trigger dafür und dann machen die das und dann füllt ihr den aus und danach werfen die alles wieder weg und legen sich wieder hin.

[48:14] Genau, also das Ganze gibt es ja schon seit längerem, dieses Function as a Service ist ja das Prinzip, dass man einfach kurz mal so eine Runtime startet, die den Code einfach ausführt und die Grundidee ist, dass ich das ist natürlich ein Shifting von einem Denkmodell auf, aber dass ich daher keinen keinen Server überhaupt brauche.
Weil der Server wird ja nichts anderes tun, als den Request entgegennehmen, vielleicht eine Datenbankabfrage machen, vielleicht die Daten irgendwie aufbereiten und wegschicken.
Und genau das will man jetzt einfach ein bisschen wegkapseln, dass man einfach sagt, ich habe nur eine Funktion.
Und genau diese Funktion wird einfach irgendwo in der Cloud ausgeführt.
Skaliert natürlich mega gut auch, weil ich dann einfach sagen kann, ich haue jetzt mal kurz nochmal einen Knoten auf, sage ich mal, der diesen Code ausführt und danach, wie du auch richtig gesagt hast, ist der Knoten wieder weg.
Und genau dieses Erstellen, dieser Runtime oder dieser Umgebung, wo der Code dann ausgeführt werden kann, das ist halt gerade bei nativen Azure Functions zum Beispiel, da weiß ich es relativ gut, recht lange.
Lange, aber wenn das halt als WebAssembly-Modul gestartet wird, dann, überwiegend ist definitiv, überwiegt der Vorteil, dass das halt so viel performanter ist und die Code, man nennt es Kaltstartzeit, also von dem Moment an, dass das WebAssembly-Modul letztendlich gestartet wird und den Code ausführt.

[49:34] Ist halt so immens viel schneller, wenn man es dann... Weil halt alles schon fertig ist.
Es muss nichts irgendwie hochgefahren vorbereitet werden, sondern das kann sozusagen sagen, mit drehenden Rädern schon direkt aufsetzen und loslaufen. Absolut.
Nichtsdestotrotz ist vielleicht wichtig an der Stelle zu erwähnen, dass man alles trotzdem steht und fällt mit vernünftig geschriebenem Code.
Also ich kann natürlich jetzt auch C, C++ Code schreiben, der so imperformant ist, dann ist auch das WebAssembly-Modul natürlich imperformant.
Klar, aber es ist, bis es loslegen kann, imperformant zu sein, da ist Es ist sehr schnell drin, sozusagen.
Es stellt sich sehr schnell heraus dann, dass es sehr inperformant ist.
Ja, absolut. Auch während das bei den anderen noch eine kleine Überraschung bleibt.
Vielleicht ein Punkt, den ich gerne noch irgendwie anbringen möchte, ist die Fehlerbehandlung.
Ich habe nämlich schon sehr oft Fragen zu Debugging und generell Fehlerbehandlung.
Das ist ein gutes Thema, ja, sehr gut.
In WebAssembly gehört. Und Debugging im Webbrowser ist tatsächlich möglich.

[50:44] In Chrome gibt es dafür eine Einstellung, die ich aber aktivieren muss.
Es gibt so Experimental Settings in einem Chrome-Browser und da muss ich WebAssembly Debugging aktivieren.
Und es ist tatsächlich status quo so, dass ich dann in dieser textuellen Repräsentation, die wir vorhin angesprochen haben, kann ich Breakpoints setzen.
Der Gedanke ist natürlich, dass ich gerne auch so eine Art Source Map habe, also dass ich, blöd gesagt, Rust-Code im Webbrowser debuggen kann.
Und es gibt bereits Ansätze, also gerade im Rust-Bereich gibt es da Crates, die ich aktivieren kann und die dann in meinem Browser quasi ausgeführt werden.
Also, aber natürlich nur, wenn ich ein Debug-Flag setze und dann das kompiliere.
Andernfalls landet das Create natürlich nicht in meinem Production Rust, sage ich jetzt mal.
Und dann ist es auch möglich, dass mir so eine Azus-Mapping erstellt wird und ich Rust tatsächlich auch im Browser debuggen kann.

[51:51] Fairerweise muss ich sagen, dass ich das bisher noch nicht zum Laufen bekommen habe.
Ich kenne die Theorie. Ich habe bisher nur WASD, also WebAssembly Textuale Repräsentation, kompiliert.
Daher vielleicht auch der kleine Aufruf an euch, wenn ihr, weil ich habe zwei Crates gefunden, die das angeblich machen sollen, diese Source Maps, und ich sehe dann Bilder oder Videos, dass das funktioniert.
Ich habe das irgendwie noch nicht zum Laufen bekommen.
Deshalb gerne kann man Vorschläge auch gerne vielleicht dann hier auf dem Podcast oder so mal posten.
Das würde mich selbst sehr stark interessieren, weil die Crates, die ich verwendet habe, es waren bisher zwei, die haben das leider noch nicht, da hat es nicht funktioniert.
Deshalb, Debugging im Webbrowser, ja, ist möglich, aber es erfordert noch ein bisschen manuelle Arbeit und man muss anscheinend so das richtige Compiler-Flag setzen und dann das richtige Package, sage ich jetzt mal, verwenden.
Daher ist es dann wahrscheinlich nochmal ein bisschen anstrengender.
Genau, und zu der Fehlerbehandlung in WebAssembly-Modulen ist es tatsächlich auch noch recht spannend, denn es hängt immer ein bisschen vom Host-System dann ab, was das WebAssembly-Modul tatsächlich auch ausführt.

[53:13] Bleiben wir mal bei sehr einfachen Fehlern, irgendwelche Laufzeitfehler.
Wenn ich jetzt zum Beispiel in C habe ich jetzt eine Funktion, die soll einfach nur eine Division durchführen.
Und in JavaScript gebe ich jetzt eine Null rein. So, was passiert dann?
Dann klar, EC würde mir dann hoffentlich natürlich einen Fehler schmeißen.
Und solche Laufzeiteros nennt man dann auch gerne sogenannte Wasm-Traps.
Das sind Laufzeiteros. Und wenn ich im Browser mich befinde, lassen die sich sehr leicht mit dem Try-Catch abfangen.
Das heißt, wenn ich so User-Eingaben am besten irgendwie habe, die dann direkt in ein Web-SAM, die Modul übergeben werden sollen.

[53:55] Dann würde ich da immer ein Try-Catch-Block umranden, also das eingrenzen.
Und die Herausforderung ist dann leider, dass wir das WebAssembly-Modul, weil es sich dann in einem undefinierten Zustand befindet, tatsächlich stoppt dieses WebAssembly-Modul dann komplett und ich muss es neu laden bzw.
Ich muss es neu laden oder neu kompilieren und dann kann ich erst wieder weitere Funktionen auf dem WebAssembly-Modul ausführen.
Aber auch das wird mir von gewissen Frameworks mittlerweile abgenommen, aber so Laufzeiterrors, die am besten immer mit einem Try-Catch absichern und dann im Catch-Block am besten das WebAssembly-Modul nochmal neu laden und dem Nutzer mitteilen, dass er bitte vernünftige Dateneingaben verwenden soll oder noch besser, eigentlich am besten schon im JavaScript-Code halt fehlerhafte Eingaben vielleicht abfangen.
Sodass ich die Null erst da nicht in mein Web-Send-Modul übergebe an der Stelle.
Würden da auch die TypeScript-Geschichten helfen?

[54:59] Das wahrscheinlich nicht, ne? Zur Laufzeit ja nicht.
Ja, zur Laufzeit muss man sich so Typeguards selber bauen.
Also alles, was zur Laufzeit passiert, kann natürlich nicht mehr von TypeScript abgefangen werden.
Aber da muss man halt vorher letztendlich eine Art Validierung machen.
Denn eine Herausforderung ist natürlich auch, und das habe ich bisher ein bisschen verheimlicht, ist, wie das eigentlich mit JavaScript und zum Beispiel C ist.
In C habe ich ein Float, ein Unsigned-In, ein Double und in JavaScript, wie wir wissen, haben wir Number.
Und jetzt ist es natürlich schon interessant, wenn ich jetzt hier eine C-Funktion habe, die jetzt irgendwie eigentlich zwei Doubles erhält und ein Integer oder ein Unsigned Integer sogar und ich übergebe aber jetzt halt schon minus zwei auf diesen Unsigned in.
Und das kann natürlich auch problematisch werden und was tatsächlich leider passiert, ist, dass JavaScript bei der Übergabe in das Web-SAMD-Modul versucht, ein Parsing zu vollziehen.
Konkret ist es beispielsweise, wenn ich jetzt eine 5,5 an ein Integer übergebe, wird daraus eine 5.

[56:14] Es gibt natürlich auch Momente, wo dann quasi ein Laufzeitfehler passiert.
Das wäre bei dem Unsigned-In jetzt der Fall. Also wenn ich irgendwie versuche, einen Minus-Einsitz einem Unsigned-In zu übergeben, dann wird ein Fehler geschmissen.

[56:29] Unsigned-In nur kurz eingeschoben heißt im Prinzip, dass man kann nicht mit Vorzeichen arbeiten.
Es kann nur positive Zahlen und dann ist ein Minuswert halt irgendwie ein Fehlerplatz. Genau.
Und es hängt tatsächlich aber auch ein bisschen vom Host ab, wie er das dann handelt.
Also Wasma handelt das ebenfalls als ein Laufzeiterror, aber es kann sein, dass andere Rusten-Runtimes vielleicht sogar das Minuszeichen einfach wegschneiden.
Und dann halt einfach nur... Also das heißt, es ist so nett, aber man hört das ja schon bei dir raus, dass im Endeffekt es einem damit nicht geholfen, weil so Dinge möglicherweise dann erst mal unter dem Radar bleiben.
Das heißt, so ärgerlich wie das ist, kann ich da nur raten, wirklich sich bewusst zu sein, was eigentlich die C- oder Rust-Funktion oder was auch immer erwartet und das gut wie es geht versuchen, suchen, im JavaScript-Code dann abzufangen oder im JavaScript-Code zu behandeln.
Ich verstehe, dass man natürlich sich eigentlich dann gerne nicht mit dem C-Code beschäftigen möchte, wenn man es aufruft und dann einfach vertrauen möchte, dass schon das Richtige, reingelangt oder so, aber das geht leider nicht so einfach in diesem Übergabe von JavaScript zu C-Code letztendlich.

[57:53] Und das kann man ja auch dann nicht, also, das kann man ja auch nicht in TypeScript abbilden, richtig?
Weil TypeScript ja nur die Datentypen abbilden kann, die JavaScript auch darstellen kann.
Nichtsdestotrotz, in den meisten Fällen gibt es so eine Art, wenn WebAssembly einen Fehler schmeißt, dann wird es meistens an den Host, also an die Runtime letztendlich propagiert.
Und dann, wie gesagt, ist der Host ein Webbrowser, dann ist das ein ganz normaler JavaScript-Exception.
Es ist zwar dann natürlich auch nicht so leicht herauszufinden, warum die Exception geflogen ist, also da steht dann nicht drin sowas wie, du darfst nicht durch Null teilen, wir kennen ja alle JavaScript-Exceptions oder JavaScript-Error und lieben sie, aber nichtsdestotrotz ist das wenigstens etwas, was wir wenigstens behandeln können und dann wissen, okay, es hat ein Fehler geflogen, jetzt lade ich nochmal das Modul neu und dann kann ich das weitermachen in dem Sinne.

[58:55] Ja, also man genau, kann so Error Recovery zumindest machen. Ja.
Gut, dass du das aber noch erwähnt hast, weil genau, wir haben ja erst mal nur so die schöne Developer-Experience-freundliche Welt und die Möglichkeiten sind wir durchgegangen, was ja auch seine Berechtigung hat.
Aber klar, es gibt ja auch dann eben die Debug-Situationen, die dann auch manchmal sehr anstrengend werden können.
Aber ich kann nur sagen, es macht auch wahnsinnig Spaß, irgendwie mit WebSambi zu arbeiten, weil es dann doch die Portierung, ich habe schon einigen Teams auch geholfen, gerade ihren C-Code bzw.
C++-Code nach WebSambi zu portieren.
Wobei ich auch bei weitem, ich bin gar keine C++-Expertin.

[59:52] Ich bin eigentlich JavaScript-Entwicklerin, schon seit Jahren.
Und bei mir hat es nur ein bisschen angefangen, weil ich zwei ältere Brüder habe, die Hardcore-C++-Entwickler sind.
Und die sich natürlich irgendwie über ihre kleine Schwester lustig gemacht haben, dass ich meine vernünftige Programmiersprache lernen soll.
Und so bin ich eigentlich in das ganze WebAssembly-Thema überhaupt erst reingekommen und habe mich dann auch erst mit der Programmiersprache C++ auseinandergesetzt, weil ich es dann umso spannender fand, jetzt diesen C++-Code einfach mal im Webbrowser auszuführen.
Und was ich damit sagen will, ist die Perspektive, dass ich jetzt einfach eine Webentwicklerin bin und mich plötzlich mit C-Code auseinandersetzen kann, aber das Wissen reicht mir trotzdem, diesen C-Code zu portieren nach WebAssembly.
Das heißt, ich muss auf der anderen Seite jetzt auch keine Hardcore-C-Entwicklerin werden, damit ich jetzt diese native Applikation nach WebAssembly portieren kann.
Und das ist, denke ich mal, auch schon cool zu wissen oder auf jeden Fall auch vorteilhaft in dem Sinne.

[1:00:59] Mhm. Ja, das ist ja vielleicht das, was du vorhin meintest, dass wenn man eben aus C++ oder einer ähnlichen Sprache kommt und will dann sozusagen den Weg ins Web gehen, dass man dann sich rumschlagen muss mit diesem ganzen Krempel XML, MathML, SVG, HTML, CSS, JavaScript.

[1:01:23] Und der umgekehrte Weg ist eben möglicherweise dann fast ein bisschen einfacher, weil man dann eben nur ...
Was über die Art und Weise, wie jetzt zum Beispiel C++ funktioniert, lernen muss. Ja, absolut.
Und wie gesagt, ich kann eigentlich nur mal jedem empfehlen, nach WebAssembly vielleicht eine Chance zu geben.
Also tatsächlich einfach sich mal da reinzufuchsen.

[1:01:50] Am meisten Sinn macht es, sich eine Sprache aber zu nehmen, die man halt schon kennt, um die mal nach WebAssembly zu importieren. De facto gibt es tatsächlich auch einen Compiler, mithilfe dessen man TypeScript zur WebAssembly kompilieren kann.
Nennt sich AssemblyScript und hat tatsächlich den Vorteil, dass es zum einen natürlich dann schneller läuft, also vorkompiliert ist zumindest, zumindest wenn man es natürlich schafft, die V8-Engine auch zu nummern, was Performance angeht.
Wie schon gesagt, die ist ziemlich gut, die V8-Engine, was die Execution-Speed auch angeht.
Aber auch zum anderen, so ein Binärformat ist natürlich noch schwerer zu lesen als JavaScript.
Wir agglifieren ja schon unser JavaScript, damit man das nicht einfach lesen kann. Obfuscating ist ja da das Stichwort.
Und wenn das Ganze als WebAssembly-Modul vorliegt, dann können wir es erst recht noch weniger lesen.
Es gibt immer Methodiken, wie ich auch Binärformat natürlich wieder entschlüsseln kann und lesen kann, aber es ist natürlich noch mal schwieriger, als wenn ich jetzt das JavaScript nur Aglifier und auch das kann schon ein super Use Case sein, einfach mal sich mit WebAssembly zu beschäftigen und das Ganze dann halt mal noch WebAssembly zu kompilieren. Ja.
Und man merkt aber auf jeden Fall auch, dass du da große Freude dann hast.
Also du bist total hin und weg.

[1:03:19] Hasst du denn noch irgendwas, wo du selber sagst, da würdest du dir wünschen, dass in Sachen WebAssembly noch ein bisschen was ausgebaut wird oder passiert?
Gibt es so irgendwelche, sagen wir mal, unbeleuchtete Bereiche, die ein bisschen ausgeleuchtet werden sollten?
Also es gibt so drei Dinge tatsächlich, die schon sehr lange im WebAssembly-Bereich so ein bisschen auf in Progress stehen.
Und klar, eines ist die Garbage Collection.
Ich habe es vorhin schon angesprochen, es gibt keine automatisierte Garbage Collection, es gibt ein Proposal.

[1:03:59] Und so richtig geht es da nicht voran. Aber wenn deshalb mal jetzt, es schreckt, glaube ich, auch viele ab, gerade die C-Sharp oder Java verwenden, jetzt tatsächlich mal das Ganze nach WebSambit zu portieren.
Ich meine, wie gesagt, Blazor, C-Sharp.net hat auch seinen eigenen Weg gefunden, den aber trotzdem natürlich sehr viele Entwickler, glaube ich, auch eher abschreckt, um ehrlich zu sein.
Die ganze Mono-Runtime, also die ganze C-Sharp-Runtime da in den Browser zu bringen, weil das das Argument wieder ein bisschen killt, dass WebAssembly-Module ja so klein sind, weil es ja nur Binärcode ist.
Deshalb wird es wahrscheinlich da nochmal eine größere Adaption geben, wenn endlich mal die automatisierte Garbage-Collection drin ist.
Multi-Threading ist ein ganz großes Thema für C++-Entwickler.
Es gibt zwar mittlerweile so Multi-Threading, was dann auf die Webworker aufbaut, also dass halt ein Thread sozusagen ein Webworker ist und den Memory, der zwischen den ganzen Threads in dem Sinne dann geshared wird, also verteilt wird, ist dann so ein Shared-Array-Buffer.
Das heißt, man versucht es dann auf Browser-Funktionalitäten zu mappen, aber es erhöht so ein bisschen noch so Sicherheitsrisiken, wenn dann plötzlich doch von einem Web-Worker Zugriff ist auf den anderen.
Das heißt, das schreckt noch viele ab tatsächlich.

[1:05:24] Ich meine, Share-Workers kann man ja auch nicht benutzen, wenn man irgendwie nicht Origin-Isolation irgendwie an den Start bringt.
Also das ist ja an sich schon sehr schwer, das sicherzustellen.
Eine Implementierung zu Multithreading, aber da muss man halt wahnsinnig viel berücksichtigen, wie du richtig sagst. Das ist halt ein riesiges Sicherheitsrisiko auch.
Und dann halt, wie gesagt, die Fehlerbehandlung würde ich mir tatsächlich auch ein bisschen wünschen, dass das irgendwie ein bisschen intuitiver ist, dass ich gleich, ich kriege dann so eine Wassentrap, was dann vielleicht so eine Art JavaScript-Exception ist, aber es ist noch nicht so richtig definiert irgendwie.
Es gibt keine native Fehlerunterstützung in WebAssembly.
Es obliegt dann quasi dem Host, wie er dann mit so einem Bassenmodul-Fehler umgeht, in dem Sinne, ob es so eine JavaScript-Exception ist, ob er versucht, dann einfach die 5,5 zu einer 5 zu passen.
Und jede Runtime oder jede Laufzeitumgebung von WebAssembly macht es vielleicht auch ein bisschen anders.
Da würde ich mir halt auch wünschen, dass das ein bisschen standardisiert ist und auch ein bisschen klarer ist, was dann eigentlich mit meinem WebAssembly-Modul passiert ist in dem Sinne.

[1:06:41] Ja, aber wenn es so weitergeht wie jetzt bisher und in den letzten drei Jahren, dann, genau, also es sind ja wirklich schon echt riesen Fortschritte gemacht worden. Absolut.
Also ich bin auch, ich meine, wir müssen ja auch immer sehen, ich weiß in der Web-Welt, Angular ist jetzt sieben Jahre alt und für viele ist Angular schon ein Framework, das gefühlt jahrzehntelang da ist.
WebAssembly sehen alle auch noch als sehr neue Technologie an und es ist auch eigentlich relativ jung.
Aber trotzdem, was die Entwicklung der letzten Jahre von WebAssembly war, bin ich mal gespannt, was die nächsten drei Jahre dann passiert.
Dann sitzen wir vielleicht wieder hier und reden dann nochmal darüber, wie cool jetzt Multithreading umgesetzt ist und wie toll die Fehlerbehandlung ist und so da.
Und man muss auch sagen, gerade diese Bicode-Allianz, also auch Chrome und auch Mozilla selbst und Microsoft natürlich auch, pushen halt WebAssembly unfassbar arg.
Die wollen, dass WebAssembly genutzt wird.
Also die wollen, dass es adaptiert wird, weil WebAssembly halt so viele Vorteile einfach uns als auch native Desktop-Entwickler halt letztendlich bringt.

[1:07:57] Ja, also ich kann mir auch vorstellen, dass in drei Jahren, wenn dann die Developer Experience eben dann noch besser geworden ist durch eben so vielleicht besseres Debugging, durch Standards, was so die Wessi-Runtimes angeht, dass dann auch tatsächlich einfach mehr Leute das benutzen.
Weil ich finde, das ist ja auch immer die, also am Anfang hast du halt die Early Adopter, die sich da so durchgraben und durchfräsen, trotz aller Widrigkeiten, aber wenn du dann irgendwann das ganze Tooling hast, was die Dinge dann irgendwie transparent macht und nachvollziehbar und irgendwie leicht auch umzusetzen, dann gewinnst du natürlich auch dann die breite Masse für sowas.
Gerade bei der Developer Experience hat ja Woodshed hat sich schon einiges getan und ja, ich bin überzeugt oder so, wenn ich die letzten Bewegungen auch sehe, dass ich da in Zukunft auf jeden Fall auch noch mehr tun wird in dem Sinne.

[1:08:58] Ja, super. Sehr cool. Gutes Thema.
Super gut, dass du da warst. Ja, vielen Dank für die Einladung.
Es hat mir, wie man gemerkt hat, riesen Spaß gemacht, darüber zu reden.
Wo könnte ich denn unsere Hörerinnen und Hörer alles treffen oder irgendwie auffinden?
Du bist ja unter anderem auch Google Developer Expert, richtig?
Ist das immer noch der Fall? Genau, das ist immer noch der Fall.
In Angular letztendlich.
Ansonsten, ich bin, glaube ich, auf so sämtlichen jeden Social-Plattformen.
Ich wollte schon wieder Twitter sagen. Ich sag immer noch Twitter.

[1:09:39] Blue Sky, Mastodon mit einem Handel Martina Kraus 11 letztendlich vorhanden.
Martina Kraus war schon vergeben, deshalb habe ich noch meine Lieblingsteilchen zu. Ja, ich kenne das.

[1:09:51] LinkedIn, klar, auch jederzeit. Ich freue mich mega über Fragen rund um WebAssembly, wo ich auch unterstützen kann.
Mega, mega gerne. Schreibt mich gerne an. Lasst mir eine Nachricht da, wenn es euch gefallen hat.
Oder kommentiert auf diesen Podcast natürlich auch sehr gerne.
Oder wenn ein Projekt irgendwie sich zusammenbraut, ein potenzielles, dann kann man dich wahrscheinlich auch mit dazu holen, richtig?
Ja, klar, auf jeden Fall. Sehr, sehr gerne.
Also ich bin da nicht nur, also ich berate nicht nur, sondern ich entwickle auch mit. Also das ist mir auch immer sehr wichtig.
Ich rede nicht nur darüber, sondern ich möchte auch mit entwickeln, damit ich auch noch weiterhin am Ball bleibe. Ja, cool.
Vielen, vielen Dank. Viele liebe Grüße nach Karlsruhe.
Ja, ebenfalls. Danke. Und ja, hoffentlich nicht erst bis in drei Jahren oder so, sondern früher.
Ja, sehr gerne. Ich mag euren Podcast total und höre auch hin und wieder rein.
Das ist sehr, sehr cool. Ja, danke schön. Vielen Dank für die Einladung.
Vielen Dank fürs Zuhören und bis nächste Woche. Macht's gut. Tschüss. Tschüss.

[1:11:10] Music.

[1:11:39] Untertitelung des ZDF, 2020.