> Are there any examples beating "HTML, CSS, and targeted JS" on typical webpage usecases?
No, and you won't find any. That's not the use case for WASM right now. If your JavaScript code's purpose is to manipulate HTML/CSS, then using WASM will likely make it slower and worse.
That will change and WASM gains the ability to access the DOM without going through JS, but that requires many other big features like GC and reference types, and given that there's not a lot of people working on these things anymore after the Mozilla implosion, it might take many years still, or even never happen.
Absolutely! The difference is dramatic for many types of functions.
You can write a full checkers game engine in a single wasm file weighing in at about 1500 bytes. I only use this example because I worked through it as a continuation of the 853 byte partial implementation in the pragprog wasm book. Even optimized and minified JS ends up being a far larger file for any similar amount of logic.
I could see some huge wins from rewriting popular JS utility libraries in web assembly, but of course it depends on the library how much sense it makes. There are limitations around DOM manipulation, as others have pointed out, but I'm sure we'll see more and more wasm over time.
