Part of the Atomify migration (see epic). Lower priority.
The published module is built with SINGLE_FILE=1: the wasm is base64-embedded in a ~10.8 MB dist/cpp/lammps.js. Consequences for a page like Atomify:
- ~33% base64 size overhead on the wire vs a raw
.wasm
- no
WebAssembly.instantiateStreaming (decode happens on the main thread after the whole JS file arrives)
- the module can't be cached independently of the JS glue
cpp/build.py already supports SINGLE_FILE=0 (emits lammps.wasm + locateFile); the package could ship both variants (e.g. lammps.js/wasm-split) or make the split build the default with locateFile guidance for bundlers. Atomify previously served a separate public/lammps.wasm exactly this way.
Grows in importance if the package set (and thus binary size) grows per #59.
🤖 Generated with Claude Code
Part of the Atomify migration (see epic). Lower priority.
The published module is built with
SINGLE_FILE=1: the wasm is base64-embedded in a ~10.8 MBdist/cpp/lammps.js. Consequences for a page like Atomify:.wasmWebAssembly.instantiateStreaming(decode happens on the main thread after the whole JS file arrives)cpp/build.pyalready supportsSINGLE_FILE=0(emitslammps.wasm+locateFile); the package could ship both variants (e.g.lammps.js/wasm-split) or make the split build the default withlocateFileguidance for bundlers. Atomify previously served a separatepublic/lammps.wasmexactly this way.Grows in importance if the package set (and thus binary size) grows per #59.
🤖 Generated with Claude Code