This repository is the home of Jaccwabyt, a single-file JavaScript library which creates JS-side bindings of WebAssembly-compiled C structs, such that changes made to a struct in JS are visible in C and vice versa. The API is described in detail in its docs.

This project also maintains a documented, tested, copy/pastable mini-library intended to replace much of the Emscripten glue code (simply for the sake of reducing dependencies on any given WASM environment). Both Jaccwabyt and those utilities are core components of SQLite's JS/WASM bindings, so are known to work well.

Platform compatibility: it's developed and tested in recent Firefox and Chrome versions and requires a recent browser. It in no way attempts to accommodate JS versions older than roughly 2018. Though Jaccwabyt is essentially platform-independent, it makes no specific attempts to account for non-browser JS environments like node.js. Contributions to make it more portable are welcomed so long as they do not limit it with regards to full-featured platforms. That said: no specific portability problems are currently known.

Formalities

• License: SQLite Blessing
• Author: Stephan Beal. Contributors are welcomed so long as they're willing to work with the Fossil SCM (i don't do github).

Downloading

This site is a Fossil SCM repository and can be cloned in full to obtain the whole source tree:

$ fossil clone https://fossil.wanderinghorse.net/r/jaccwabyt
$ cd jaccwabyt
$ ls -la

Building and Testing

Jaccwabyt itself does not depend on any given 3rd-party tools and is specifically designed to be able to be used with an any given WASM toolchain. However, this repository requires the following for building and running the test and demo code:

• The Emscripten SDK (with emcc in the $PATH) and/or the wasi-sdk (build expects it at /opt/wasi-sdk).
• GNU Make. The supplied makefile will not work with other makes.
• A Unix-style build environment.

It will build without the first two - they're used only for testing. The JS also requires building, though:

$ make; # requires GNU make, a.k.a. gmake on some systems

The resulting files are in the js/ subdirectory, in both "vanilla" JS and ESM formats.

With both GNU Make the Emscripten SDK installed and in the $PATH, simply run "make" (or, on some platforms, "gmake") to build the test and demo code. Because WASM code cannot be loaded from file:// URLs in some browsers, the test apps (test/*.html) require that it be served from an HTTP server. There are many options for doing so, but one of the simplest (for Unix-like systems) is to build althttpd, add it to the $PATH, then run:

$ althttpd -page emcc.html
# or:
$ althttpd -page wasi-sdk.html
# or:
$ make www

The test output all goes to the browser dev console, so be sure to open the dev tools. The results for the tests must be the same for each build environment but they live in different HTML files because each requires different bootstrapping steps to get the module loaded and the test environment bootstrapped. Hypothetically they could all live in one page, and maybe that will happen one day, but it currently seems like it would just cause confusion in the test output.