Is WebAssembly the Return of Java Applets and Flash?
The OP is really spot on.<p>For the commenters that seem to have some underlying fear that WASM apps will be another incarnation of a &quot;window in a window&quot; or some horrible bitmapped graphics pane that does not fit into the web model:<p>WASM is just a CPU. It&#x27;s a bytecode format for expressing low-level, high-performance programs. It comes &quot;batteries not included&quot;--intentionally. By batteries, I mean APIs. WebAssembly modules must import everything they need from the outside. When embedded in JS and the Web, the first and still primary use case of WASM, that means modules can import functionality from both JS and the Web, and call literally <i>anything that JS can call</i>. That means WASM can (though still somewhat clunkily) manipulate the DOM, WebGL, audio, service events, etc, through all of the same APIs that JS can do. There is nothing that prevents a WASM app from looking and feeling exactly like something written in JS.<p>To reiterate: WASM does not require you to drop down to canvas or render fonts yourself. You can call out to JS or direct to WebAPIs! (again, it just happens to be clunky to do this from C++.) But other languages are working on bindings that make this much nicer. Rust anyone? :)<p>What WASM gives the web is a proper <i>layer</i> for expressing computation. The APIs and paradigms that build on top of WASM are independent, swappable, interposable, by design. Because it&#x27;s a layer for computation, and a low-level one, it is by nature language-independent. As Steve mentioned, adding languages to the web one by one does not scale. Thus WASM.