While just the parsing step may be faster indeed, I don't think that aspect alone is enough to make a difference for an application.
Browsers are often able to defer parsing of JS functions until they're called, so dead JS code doesn't cost much in parsing time.
In JS first run goes through an interpreter (without a delay for compilation/optimization), so JS has a pretty low latency for initial execution.
JS is relatively easy to split into pieces and lazy load (there are various bundlers that support "chunking"), and not loading code is faster than fastest parsers. WASM could theoretically do that too, but current languages and tooling are more geared towards monolithic executables. For UI, where time to interactive matters most, JS will likely do a better than a big blob of WASM.
WASM still needs to call out to JS for DOM interactions, so if your UI is DOM-based, you'll need a bunch of JS anyway, and have JS<>WASM communication overhead.
Browsers do a fast partial parse to figure out things like scoping and variable names, but skip actually building an AST so it's still a lot quicker than full parsing (e.g. https://v8.dev/blog/preparser)
Does wasm support anything other than monolithic executables? The last I used it, multiple wasm bundles had to be loaded up by JavaScript and glued together with JavaScript.
Browsers are often able to defer parsing of JS functions until they're called, so dead JS code doesn't cost much in parsing time.
In JS first run goes through an interpreter (without a delay for compilation/optimization), so JS has a pretty low latency for initial execution.
JS is relatively easy to split into pieces and lazy load (there are various bundlers that support "chunking"), and not loading code is faster than fastest parsers. WASM could theoretically do that too, but current languages and tooling are more geared towards monolithic executables. For UI, where time to interactive matters most, JS will likely do a better than a big blob of WASM.
WASM still needs to call out to JS for DOM interactions, so if your UI is DOM-based, you'll need a bunch of JS anyway, and have JS<>WASM communication overhead.