The post is my story of what I learned by winning $100K at a competition for implementing a cryptography algorithm in Wasm
It's a new way to write Wasm, built for the JavaScript ecosystem.
The post introduces the wasmati library by implementing a simple low-level crypto algorithm (finite field addition) and benchmarking against performance of JS bigints
I actually think there's a third way of "using JS to write Wasm", which is to have a JS library which has instructions to emit "hand-written" Wasm bytecode.
Example of such a library: https://github.com/iden3/wasmbuilder
That's actually what I was thinking about when picking this option!
Think of the following situation:
- You're a JS developer, and want to write a client / library mainly with JS
- You want to use Wasm only for some narrow, performance-critical parts
In this case, you may not want to use something like Rust, because that adds tooling overhead, makes the Wasm bytecode bigger & makes it harder to hand-optimize the Wasm. On the other hand, you might not want to directly write the Wasm in raw WAT, because that has crappy DX.
>> The Reference Types proposal, shipped in V8 v9.6, allows using external references from JavaScript opaquely in WebAssembly modules.
This is a major step for WebAssembly which I've waited for a long time! Note that Chrome was the last major browser not supporting reference types, so soon we'll be able to use this on real websites: https://webassembly.org/roadmap/
The main contribution is that now arbitrary values can be passed between JS and Wasm modules. These will show up on the Wasm side as opaque `externref` types.
This allows (arbitrarily powerful) Wasm modules that only import JavaScript glue code instead of having to wrap their exports with JS functions. "Modules that import the functionality they need" is, IMO, a much saner model for creating an ecosystem of modules than "modules which are wrapped with functions specific to the functionality they need". I think this will lead to
* more transparent code (= closer correspondence between the code which is compiled to Wasm and the thing that actually runs in your browser)
* a standard interface between functions across the ecosystem => much more potential to just import and use Wasm modules written in other languages
* an easier way to ship only the minimal amount of JS glue code you need
Signal doesn't even have a web app. They have a desktop app that works great and that I use every day, all day long for all kinds of communication. On my desktop and laptop.
Edit: nvm found it! No it doesn't, as this is not dealing with EVM at all