WASM will pave the way for other 'easier to write' languages to occupy the same space as JS. Rust is pushing heavy for native browser support and will likely be an early adopter in this space. It's only a matter of time until <your language of choice> will support compiling to WASM and run in the browser
The problem with that is, no one is going to be writing raw WASM code - it's going to be compiled from another language, which means requiring a compiler toolchain to replace an interpreted scripting language that only really requires a text editor.
For sites which are already using the paradigm of "compiling to javascript" that might not be an issue, but that doesn't cover all the use cases for Javascript.
Other languages can't really occupy that same space until it's possible to, say, embed Lua or Rust source in script tags and just have it work as easily as Javascript does, and have the browser handle compilation and execution entirely.
If your compiler toolchain both runs on and generates WASM then you’ve removed about 90% of the pain of compiler toolchains. The experience should be on par with something like typescript or one of the ecma compatibility compilers. There’s still potential for classes of issues that would not exist in straight Javascript, but I’d rather debug most of those with browser tooling than gdb.
That's an interesting thought. I didn't mean to suggest anyone code in WASM, but I think I see what you mean.
I have experience embedding lua applications within mobile apps, and it required a fair deal of wiring in C to marshal between java and lua (android) or swift and lua (ios).
To do the same in WASM sounds rather undesirable.
Edit: to finish my thought, I dont see the problem with using a compiler toolchain to create web applications. Can you elaborate on why that isn't a good thing?
>Can you elaborate on why that isn't a good thing?
It's not a bad thing per se, but it's added complexity without any obvious benefit if that code is still doing what javascript already does, just as a binary blob, especially for simple uses like glue code around jQuery or the sort of JS running on Hacker News.
That's what I thought as well, because that's what's being told. However, Microsoft recently released the experimental Blazor framework, which is C# + Razor on WebAssembly. Among others things, it actually is for "making a modal pop up". Still early days, but I have to say I'm impressed.
It’s unlikely that vendors will ever support multiple JIT engines, so wasm is likely to be AOT only for the foreseeable future: you likely won’t see other languages inside script tags.
And secondly, it’s going to be a long time before the entirety of the Web API (which is much bigger than just the DOM) is supported in wasm, if ever.