As you can imagine, this is not a question that can be answered definitely, however, I can give you a better understanding of the current situation and where things are going.

An app compiled to a WebAssembly module, will have the following component parts:

1. The app logic itself
2. (optional) A runtime
3. (optional) Host API integration

Looking at each in turn:

Regarding (1), WebAssembly modules are a size-efficient binary format. For that reason, it is more compact (i.e. smaller) than the equivalent logic represented by minified JavaScript.

Re:2, WebAssembly lacks common runtime features such as (heap) memory management and garbage collectors. For that reason, a runtime is often shipped alongside your application logic. In some cases (Rust) this runtime is quite lightweight, and in others (Blazor) it is very heavy. We will likely see the weight of these runtimes decreasing significantly over time due to new WebAssembly features (garbage collection, module caching) and better compilation techniques (ahead-of time compilation).

Re:3, as you acknowledged, WebAssembly lacks DOM access - in fact is lacks any form of I/O. At the moment your 'standard' WebAssembly tooling generates 'bindings' that aadd additional weight to your WebAssembly modules and some JavaScript 'glue' code. This will likely decrease over time as initiatives like the interface types proposal gains traction.

So to answer you questions, yes, I do think wasm modules will be more compact than their equivalents in future. I also think the runtimes will be delivered separately and cached, but more importantly this will significantly decrease in size.

As you can imagine, this is not a question that can be answered definitely, however, I can give you a better understanding of the current situation and where things are going.

An app compiled to a WebAssembly module, will have the following component parts:

1. The app logic itself
2. (optional) A runtime
3. (optional) Host API integration

Looking at each in turn:

Regarding (1), WebAssembly modules are a size-efficient binary format. For that reason, it is more compact (i.e. smaller) than the equivalent logic represented by minified JavaScript.

Re:2, WebAssembly lacks common runtime features such as (heap) memory management and garbage collectors. For that reason, a runtime is often shipped alongside your application logic. In some cases (Rust) this runtime is quite lightweight, and in others (Blazor) it is very heavy. We will likely see the weight of these runtimes decreasing significantly over time due to new WebAssembly features (garbage collection, module caching) and better compilation techniques (ahead-of time compilation).

Re:3, as you acknowledged, WebAssembly lacks DOM access - in fact is lacks any form of I/O. At the moment your 'standard' WebAssembly tooling generates 'bindings' that add additional weight to your WebAssembly modules and some JavaScript 'glue' code. This will likely decrease over time as initiatives like the interface types proposal gains traction.

So to answer you questions, yes, I do think wasm modules will be more compact than their equivalents in future. I also think the runtimes will be delivered separately and cached, but more importantly this will significantly decrease in size.