Feature: (Ab)Use WASM for more efficient binary storage.

[NfNitLoop]

Deno 2.1 adds even better support for loading WASM modules.

I bet storing binary data inside of a WASM file might be more space-efficient than storing it as base64 data inside of a .ts file.

Would be fun to implement a WASM option to compare the two.

[NfNitLoop]

Question:

The current typescript-based implementation assumes that when passing a literal to a constructor like this:

new Foo(`some string literal`)

the string literal can be garbage-collected since it's never used again in code. This means that we can convert the base64-encoded version to a smaller Uint8Array representation. We may additionally choose to keep that representation compressed, or decompress it. But because the original literal is GC'd, we don't have to care about doubling memory usage.

But, does the WASM runtime allow for that? If a literal is encoded in the WASM file, and the WASM file is loaded into a state machine, it's just going to stay in memory for the entire lifetime of the WASM module, right?

That may still be fine if we load & keep compressed bytes directly from the module. But we'd also want to check on any inefficiencies that passing those bytes into JS might introduce.

[NfNitLoop]

Maybe we can load bytes from the wasm into JS then unload the wasm? If it’s in a worker?