It is possible to use Rhai when compiling to WebAssembly (WASM). This yields a scripting engine (and language) that can be run in a standard web browser.
But anyhow, do it because you can!
When building for WASM, certain features will not be available, such as the script file API’s and loading modules from external script files.
Also look into minimal builds to reduce generated WASM size.
As of this version, a typical, full-featured Rhai scripting engine compiles to a single WASM file less than 200KB gzipped.
When excluding features that are marginal in WASM environment, the gzipped payload can be further shrunk to 160KB.
In benchmark tests, a WASM build runs scripts roughly 1.7-2.2x slower than a native optimized release build.
Some Rhai functionalities are not necessary in a WASM environment, so the following features are typically used for a WASM build:
|when a WASM module panics, it doesn’t crash the entire web app; however this also disables maximum number of operations and progress tracking so a script can still run indefinitely – the web app must terminate it itself|
|WASM supports 32-bit and 64-bit integers, but most scripts will only need 32-bit|
|WASM supports 32-bit single-precision and 64-bit double-precision floating-point numbers, but single-precision is usually fine for most uses|
|a WASM module cannot load modules from the file system, so usually this is not needed, but the savings are minimal; alternatively, a custom module resolver can be provided that loads other Rhai scripts|
The following features are typically not used because they don’t make sense in a WASM build:
|WASM is single-threaded|
|WASM usually doesn’t need access to Rhai functions metadata|
|WASM usually doesn’t need to access Rhai internal data structures, unless you are walking the |