Watlings – WebAssembly Text Format lernen, indem man kleine Programme repariert

• Watlings ist ein Übungsprojekt, bei dem man das WebAssembly Text Format lernt, indem man mehrere kleine Programme repariert
• Jede Aufgabe wird anhand der Anweisungen im Verzeichnis exercises gelöst; getestet wird die Lösung mit npm start 001_hello
• Zum Prüfen der Lösung dient npm run show 001_hello, und um die Lösung direkt auf die Aufgabe anzuwenden, verwendet man den Befehl npm run solve 001_hello
• Für Kompilierung und Tests werden Node 23+ und wasm-tools verwendet; innerhalb der Skripte wird wasm-tools parse aufgerufen
• Aufgaben ab Nummer 015 verwenden neuere WebAssembly-Funktionen wie Exception Handling und GC types und benötigen das nur in Node.js 23 oder neuer verfügbare Flag --experimental-wasm-exnref
• Es gibt eine Web-Version, die im Browser ausgeführt werden kann; als Editor werden VSCode und die Erweiterung wat-lsp empfohlen
• Der Lernansatz ist auf direktes Schreiben ausgerichtet: Aufgaben und Hintergrund werden über Kommentare pro Datei vermittelt, Erklärungen werden möglichst knapp gehalten, und die Syntax soll in unterschiedlichen Kontexten wiederholt auftauchen
• Als Referenzbeispiele für die Projektstruktur werden rustlings und Ziglings genannt

[GN⁺]

Hacker-News-Kommentare

• Ich sehe das immer wieder an verschiedenen Stellen, aber was WASM im Browser fehlt, ist nicht nur DOM-Zugriff, sondern praktisch jede Web-API, einschließlich fetch und XMLHttpRequest.
  Eine Liste der Web-APIs, die der Browser unterstützt, WASM aber nicht, gibt es hier; DOM ist nur eine davon: https://developer.mozilla.org/en-US/docs/Web/API
  Wenn GC jedoch finalisiert ist und von Browsern unterstützt wird, besteht die Möglichkeit, solche Interfaces zu verwenden. Es heißt, dass WebAssembly-Code mit GC-Unterstützung JavaScript-, DOM- und allgemein per WebIDL definierte Objekte referenzieren und darauf zugreifen kann.
  Siehe den letzten Absatz: https://webassembly.org/docs/web/

  • Der GC-Vorschlag kam 2018 heraus https://github.com/WebAssembly/proposals/issues/16, und es gibt auch Code: https://github.com/WebAssembly/gc/blob/master/proposals/gc/O...
    Angesichts der Möglichkeiten, die das eröffnen könnte, wirkt der Fortschritt viel zu langsam.
  • Wenn man das „löst“, besteht auch die Gefahr, dass es die nächsten Java Applets werden.
  • Ich habe WebAssembly nicht durchgehend verfolgt, aber ich frage mich, warum etwas, das einmal als „Heilmittel“ für JS galt, so lange braucht, um Grundfunktionen zu bekommen.

• Sieht dem Exercism-Modell sehr ähnlich. Exercism hat ebenfalls einen kostenlosen WASM-Kurs mit kleinen Übungen: https://exercism.org/tracks/wasm
  Ich frage mich, ob der Autor erwogen hat, zu diesem Kurs beizutragen oder daran mitzuarbeiten. Damit ließe sich ein breiteres Publikum erreichen und zugleich die bestehende Tooling-Infrastruktur von Exercism nutzen.

  • Ich mag Exercism wirklich sehr, aber das Übungsmodell dort ist deutlich freier und besteht aus viel größeren Einheiten, die vergleichsweise weniger didaktisch anleiten.
    In bestimmten Kontexten ist das ein gutes Modell, aber das Format dieses Repositories liegt näher an rustlings oder ziglings, bei denen man Syntax und Features anhand von Codebeispielen lernt.
    Das Wasm-Modul von Exercism ist nicht unbedingt „kaputt“, daher bin ich nicht sicher, ob mein Beitrag willkommen wäre.
  • Was mir an Exercism nicht gefällt: Abgesehen von beliebten Sprachen sind die Übungen meist nicht sehr systematisch.
    Mit anderen Worten: Es ähnelt eher einer LeetCode-artigen Sammlung von Aufgaben, sortiert nach Schwierigkeitsgrad.
    Ein richtiger Kurs sollte Übungen nach Sprachfeatures anordnen. Exercism hat dafür bereits ein hervorragendes Interface gebaut, nutzt es aber bei den meisten Sprachen nicht: https://exercism.org/tracks/csharp/concepts

• Eine meiner liebsten Arten, eine neue Sprache oder ein neues Framework zu lernen, sind Koans, und das hier erinnert mich daran: https://github.com/ahmdrefat/awesome-koans/blob/master/koans...
  Der sanfte Anstieg von grundlegenden zu fortgeschrittenen Funktionen und der TDD-artige Ablauf, bei dem man fehlschlagende Tests sieht, den Grund versteht und sie dann behebt, passt sehr gut zum Lernen. Außerdem liefert er diese „Aha!“-Dopaminmomente.

  • Klingt nach einer guten Methode, um allein eine Sprache zu lernen. Leider fehlt Rust; ich frage mich, ob jemand einen Link empfehlen kann.

• Wenn man mit Features wie GC in WASM experimentieren will, sollte man statt WABT besser Binaryens wasm-opt verwenden. wasm-opt unterstützt deutlich mehr WASM-Erweiterungen.

• Ziemlich cool.
  Ich habe mich selbst noch nicht tief mit WASM beschäftigt, aber diesen Guide werde ich ausprobieren. Und ich finde, dass WASM dem Web Development nach einigen Jahren bereits große Vorteile gebracht hat.
  Es ist nicht der „JavaScript-Killer“, den manche erwartet hatten, aber das war auch nie der ursprüngliche Zweck. Stattdessen integriert es sich ziemlich gut in das bestehende Ökosystem, optimiert vorhandene Use Cases und ermöglicht neue, wenn schwere Berechnungen nötig sind.
  Für alle Webentwickler ist es ein Nettogewinn: schnellere Libraries, beeindruckende Entwicklungstools und portablere Node-Binaries.

  • Ich habe WASM eher aus der Ferne verfolgt, und mein Verständnis davon, warum es kein JS-Killer ist, lautet: weil es keinen direkten Zugriff auf das DOM oder die meisten DOM-APIs hat.
    Ich frage mich, ob es noch andere Gründe gibt, die ich übersehe.

• Schön zu sehen, dass die WebAssembly-Adoption weiter vorankommt. Microsoft wird hier oft nur am Rande behandelt, aber wer sich für WASM interessiert, sollte unbedingt Blazor WebAssembly ausprobieren.
  Es ist ein sehr mächtiges Framework, mit dem man C# und die meisten .NET-Libraries sowie NuGet-Pakete als kompilierte WASM-Anwendungen im Browser nutzen kann.

  • Wenn von „den meisten NuGet-Paketen“ die Rede ist: Mich würde interessieren, worin die Einschränkungen bestehen.
    Scheitert ein Paket, das Dateien von der Festplatte lesen muss, sofort, oder leitet das Datei-Lese-Interface den Vorgang etwa an serverseitiges Rendering weiter?
  • Nach dem, was ich gelesen habe, scheint es dasselbe Problem zu geben wie beim Kompilieren von Go nach WASM: Die Payload ist groß, selbst nach Kompression normalerweise mehrere MB.

• Tolles Projekt.
  Ein einigermaßen verwandtes Repository pflege ich hier: https://github.com/eliben/wasm-wat-samples/

  • Sieht wirklich nützlich aus. Ich wünschte, ich hätte das gekannt, als ich anfing, wat zu lernen; es dürfte eine hervorragende Referenz sein.

• Ich habe WASM ausprobiert, hatte aber Probleme damit, eine SQLite-Datenbankverbindung, die ich lokal anbinden wollte, offenzulegen.
  Ich frage mich, ob jemand etwas Ähnliches gemacht hat oder gute Ressourcen dazu kennt.

  • Schau dir vielleicht Spin an. Seit 1.4 ist SQLite-Unterstützung standardmäßig in der Runtime enthalten: https://www.fermyon.com/blog/spin-v14

• Es ist wirklich spannend, dass WebAssembly wie eine echte Sprache wirkt, die man in gewissem Maß von Hand schreiben kann.
  Das dürfte die Einstiegshürde deutlich senken, wenn man sie als Target verwenden will.

• Da WebAssembly zunehmend zur gemeinsamen Sprache vieler Ökosysteme wird, lohnt es sich immer mehr, Zeit in ein solides Verständnis seiner Funktionsweise zu investieren.