binaryen.js: Binaryen als npm-Paket für Browser und Node.js
Ein Buildbot für Browser- und Node.js-Builds von Binaryen, einer Compiler-Infrastruktur und Toolchain-Bibliothek für WebAssembly.
Auf einen Blick
- Was ist das?
- Ein Buildbot verpackt die WebAssembly-Werkzeugsammlung Binaryen in ein JavaScript-Paket, inklusive Kommandozeilenwerkzeugen. Einordnung von API, Versionsversorgung und Dokumentationsstand.
- Für wen ist es gedacht?
- Sinnvoll ist binaryen.js für Projekte, die WebAssembly zur Laufzeit aus JavaScript erzeugen oder umformen wollen und dafür Binaryens Optimierungsgänge brauchen, ohne eine C++-Werkzeugkette zu bauen. Ungeeignet ist es für den produktiven Einsatz ohne feste Version, weil das README selbst davon abrät, VERSION in den CDN-Adressen wegzulassen, und weil die mitgelieferten Typdefinitionen laut README hinter der Upstream-API zurückbleiben können.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 4 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich JavaScript, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
binaryen.js: ein Buildbot für Browser- und Node.js-Builds von Binaryen
Die Beschreibung des Repositories ist ungewöhnlich präzise: ein Buildbot für Browser- und Node.js-Builds von Binaryen, einer Compiler-Infrastruktur und Werkzeugkettensammlung für WebAssembly. AssemblyScript/binaryen.js ist also kein eigenständiger Compiler, sondern eine Verpackung. In den Metadaten stehen 404 Sterne, 54 Forks und 13 offene Issues, als Sprache ist JavaScript eingetragen, als Lizenz Apache-2.0 und als Startseite das Upstream-Projekt unter github.com/WebAssembly/binaryen.
Was das Paket leistet, sagt das README im ersten Satz: eine Portierung von Binaryen ins Web, mit der sich WebAssembly über eine JavaScript-API erzeugen lässt. Wer Module programmatisch baut, umformen oder optimieren will, bekommt damit den gesamten Funktionsumfang von Binaryen in einer Umgebung, in der kein Compilerlauf möglich ist.
Die Releases-Liste in den Metadaten ist leer, und das Feld für den letzten Push ebenfalls. Für ein Paket, das nach eigener Aussage von einem Bot erzeugt wird, ist das kein Widerspruch, die Versionierung läuft über npm und nicht über GitHub-Releases.
npm install binaryen: vom Modul zum Aufruf von add(41, 1)
Der Einstieg besteht aus zwei Zeilen: `npm install binaryen` und `import binaryen from "binaryen"`. Danach beginnt der Aufbau eines Moduls mit `new binaryen.Module()`. Im Beispiel des README folgt eine Funktion namens add, die zwei 32-Bit-Ganzzahlen addiert.
Der Aufruf von `myModule.addFunction` nimmt fünf Argumente: den Namen, den Parametertyp über `binaryen.createType([ binaryen.i32, binaryen.i32 ])`, den Ergebnistyp `binaryen.i32`, ein Array weiterer lokaler Variablen und den Funktionskörper. Der Körper ist ein Block aus `myModule.local.set`, einer Addition über `myModule.i32.add`, zwei `myModule.local.get`-Zugriffen und einem `myModule.return`. Mit `myModule.addFunctionExport("add", "add")` wird die Funktion exportiert.
Laut README schließt das Beispiel mit der Optimierung über Standard-Passes, einer Validierung und der Ausgabe in Text- und Binärform. Das Binärformat geht an die WebAssembly-API, wird kompiliert und instanziiert, und der Aufruf der exportierten Funktion mit 41 und 1 ergibt 42. Genau diese Kette, von der Deklaration bis zur Ausführung im selben Prozess, ist der Grund für die Existenz des Pakets.
addFunction, validate und emitBinary: die API-Abschnitte im README
Das Inhaltsverzeichnis der Dokumentation ist lang und in acht Hauptbereiche gegliedert: Typen, Modulkonstruktion, Modulmanipulation, Validierung, Optimierung, Modulerzeugung, Ausdruckskonstruktion und Ausdrucksmanipulation, dazu Relooper, Source Maps und Debugging. Der Abschnitt zur Ausdruckskonstruktion ist weiter unterteilt, unter anderem in Kontrollfluss, Variablenzugriffe, Ganzzahl- und Gleitkommaoperationen, Typumwandlungen, Funktionsaufrufe, lineare Speicherzugriffe, Vektoroperationen und Multi-Value-Helfer.
Bei den Typen nennt das README none, i32, i64, f32, f64 und v128 sowie die Referenztypen funcref, externref, anyref, eqref, i31ref, structref und stringref. Hinzu kommen unreachable für unerreichbaren Code und auto, das ausschließlich in `Module#block` erlaubt ist und den Ergebnistyp eines Blocks selbst bestimmt. Mit `createType` und `expandType` lassen sich Multi-Value-Typen zusammenlegen und wieder zerlegen.
Die Konstruktion eines Moduls hat drei Wege: `new Module()` für ein leeres Modul, `parseText` für das s-Ausdruck-Textformat von Binaryen und `readBinary` für Binärdaten in einem Uint8Array. Für die Manipulation listet das README unter anderem addFunction, getFunction, removeFunction, getNumFunctions, getFunctionByIndex sowie Importe für Funktionen, Tabellen und Speicher. Validierung ist ein einzelner Aufruf, der einen Wahrheitswert liefert und bei Fehlern Meldungen ausgibt. Zur Ausgabe stehen emitBinary, emitText, emitStackIR und emitAsmjs bereit, disposal gibt Ressourcen frei.
Nachtversionen, Tags und die drei CDN-Adressen für binaryen
Der Buildbot veröffentlicht laut README einmal täglich eine Nachtversion, sofern es Änderungen gab. Installiert wird sie mit `npm install binaryen@nightly`. Wer eine bestimmte frühere Fassung braucht, findet sie über die Tags-Seite des Repositories.
Ohne npm lässt sich das Paket über drei Adressen laden: `https://cdn.jsdelivr.net/gh/AssemblyScript/binaryen.js@VERSION/index.js` von GitHub über jsDelivr, `https://cdn.jsdelivr.net/npm/binaryen@VERSION/index.js` von npm über jsDelivr sowie `https://unpkg.com/binaryen@VERSION/index.js`. In allen drei Fällen ist VERSION durch eine konkrete Versionsangabe zu ersetzen.
Das README formuliert hier eine selten deutliche Warnung: Wer VERSION weglasse, erhalte main beziehungsweise latest, und das sei für den Produktiveinsatz nicht empfohlen. Angesichts eines Bots, der täglich neu baut, ist das die richtige Empfehlung.
wasm-opt und acht weitere Werkzeuge im Node.js-Paket
Über die JavaScript-API hinaus bringt das Paket Node.js-Builds der Kommandozeilenwerkzeuge von Binaryen mit. Genannt werden wasm-shell, wasm-opt, wasm-metadce, wasm2js, wasm-as, wasm-dis, wasm-ctor-eval, wasm-reduce und wasm-merge. Für deren Bedienung verweist das README auf die Upstream-Dokumentation und dokumentiert die Aufrufe nicht selbst.
Das ist ein praktischer Nebeneffekt. Wer in einer Build-Pipeline Module verkleinern will, bekommt wasm-opt ohne separates Binary und ohne systemnahe Installation, sondern als Teil einer normalen Node-Abhängigkeit. Für CI-Umgebungen, in denen nur Node verfügbar ist, ist das der einfachere Weg.
Werkzeuge wie wasm-reduce oder wasm-merge entfalten ihren Nutzen eher in der Fehlersuche als im Alltag. Welche Version der Werkzeuge das Paket jeweils enthält, ergibt sich aus der installierten Paketversion, eine gesonderte Auflistung gibt es im Material nicht.
Warnung im README: index.d.ts hinkt der Binaryen-API hinterher
Der ehrlichste Absatz des README steht im Kapitel API. Dort heißt es, die Binaryen-API entwickele sich schnell und die vom Paket gelieferten Definitionen und die Dokumentation neigten trotz aller Bemühungen zum Veralten. Der Satz endet mit der Bemerkung, es sei schließlich ein Bot. Wer einen Fehler finde, möge einen Pull Request schicken und index.d.ts sowie README.md an die aktuelle API angleichen.
Als Referenz nennt das README die Datei src/js/binaryen.js-post.js im Upstream-Repository. Wer auf die Typdefinitionen angewiesen ist, sollte beide Dateien nebeneinanderlegen, bevor er Stunden in eine Signatur investiert, die es so nicht mehr gibt.
Eine zweite Einschränkung betrifft künftige WebAssembly-Funktionen. Operationen für atomare Speicherzugriffe, Ausnahmebehandlung und Referenztypen sind im README mit einem Einhorn-Symbol gekennzeichnet, ebenso die Typen v128 und die Referenztypen. Das README weist darauf hin, dass diese Funktionen nicht von allen Laufzeiten unterstützt werden. Wer direkt auf das Upstream-Projekt WebAssembly/binaryen setzt, bekommt die Werkzeugkette in C++ und die jeweils aktuelle API, verliert dafür die JavaScript-Oberfläche und muss selbst bauen.
Redaktionelles Fazit
Sinnvoll ist binaryen.js für Projekte, die WebAssembly zur Laufzeit aus JavaScript erzeugen oder umformen wollen und dafür Binaryens Optimierungsgänge brauchen, ohne eine C++-Werkzeugkette zu bauen. Ungeeignet ist es für den produktiven Einsatz ohne feste Version, weil das README selbst davon abrät, VERSION in den CDN-Adressen wegzulassen, und weil die mitgelieferten Typdefinitionen laut README hinter der Upstream-API zurückbleiben können. Vor dem Einstieg empfiehlt sich ein Vergleich von index.d.ts mit src/js/binaryen.js-post.js im Upstream-Repository, um zu sehen, wie groß die Lücke bei der eigenen Version ist.
Community-Notizen