I think there's at least some value in these "toy tools". Would being able to tinker with WASM not help development of compilers? I place a very high value on understanding as far down the stack as you can, I don't think ignorance of every abstraction layer below the one you're working on is a very noble goal to strive for.
There are tools, even web based ones, that allow you to tinker with WASM, compile C, C++ or Rust code to WASM, print out the WAT representation, turn WAT into WASM, run the WASM blobs through JS, etc.
These tools are probably very useful for the guys developing WASM frontends and backends. E.g. sharing a piece of WASM code with other developers.
Should the average developer use them? Not really. Maybe spend an hour poking at things to get the general idea of how it works. You really don't need to understand the details of LLVM IR, SPIR-V, WASM or GCC's GIMPLE in order to use those compilers.
Is it a good idea to understand what and how are intermediate representations used in compilers but actually writing that by hand is not necessary or productive.
Compiler IR's like WASM or LLVM IR are very laborious to type, they're intended to be produced and consumed by compilers.
You need to write very verbose code with all the type declarations, which aren't automatically propagaged, ie. `(func $foo (param $0 i32) (result i32) ...)` and `(i32.add ...)`. There's very little point in writing code like this by hand, apart from testing and debugging the compiler producing or consuming this code.
It doesn't make much sense to have this "in the cloud" outside of toy tools like this. In any kind of actual work scenario, you'd be running a compiler producing WASM on your development machine and deliver the WASM binaries over HTTP to the client machine. The whole point is to have near-native performance while reducing the compile time on the client side.
But if you want to tinker with it, knock yourself out. Here's the tool:
[0] https://cdn.rawgit.com/WebAssembly/wabt/fb986fbd/demo/wat2wa...