Here's a list of reasons wasm can be slower or faster: Faster: 1. Compiled to a strongly typed IR, wasm code means just one thing. For instance i32.add means

Here's a list of reasons wasm can be slower or faster: Faster: 1. Compiled to a strongly typed IR, wasm code means just one thing. For instance i32.add means addition of 2 i32s. In JavaScript a '+' operator has some 70 different possible input parameters. Hence, the engine cannot assume the types (until a later optimization stage) during execution 2. 'JS -> AST -> machine code' is a typical sequence for js execution. In contrast, for wasm it is 'wasm->machine code' 3. For medium to large code bases, wasm's binary format is more compact than a js text format. Wasm can also be gzipped for further compression. It should lead to smaller downloads over the wire in such cases. Slower: 1. Passing data to and from wasm needs to happen on it's heap. Oftentimes, this is a non zero-copy operation of a JavaScript object onto the heap, and back. This can lead to preformance bottlenecks 2. The actual calling interface between wasm and js incurs a cost. If the rate of calling across this interface exceeds time spent within the wasm, performance degrades. Think CPU<-->GPU where the invocation and dates passing between the interface exceeds compute time on GPU 3. Wasm doesn't have access to Dom, network, storage, .... If your app uses these from within wasm, it's essentially calling back and forth to js while stalling wasm execution and incurring high costs to navigate the wasm<-->js interface. There are plenty of samples available online demonstrating the above points. A simple demo is that of a fibonacci series for a large number. As the number gets larger, wasm starts to easily outperform js