You can do that but why would you want to? The tool you're looking for is wat2wasm, which converts the human readable WAT source to WASM binary, and here [0] is an online tool if you want to tinker with it.

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...

I like this answer a lot more than the other ones that are just dismissive.

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.

> Would being able to tinker with WASM not help development of compilers?

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.

WebAssembly is still very new - better tools are bound to show up, but I think GC and DOM support need to be finalized first.

I can understand the nostalgia, but that just isn't really true anymore for a lot of front-end web development.

Almost everywhere you look in front-end web today you see a toolchain that includes the node runtime, babel or typescript as a compiler, and some kind of bundler/linker such as webpack or browserify that throws in minification/mangling in as a freebie. That doesn't even cover CSS.

JS/CSS is already a compile target with a build artifact often barely resemble the original source code. WASM is just another compile target that opens up the web as a platform for other languages.

> I don't like to install software. As a child of the web, my feet are firmly planted into the cloud.

It's funny, I'm the exact opposite. I don't like cloud apps. One day they're there, next day half their features are removed, next day they're gone. And I can't hack them to make them better fits for me when they keep changing. I want the code to run on my machine so I can do anything I want to it and have a stable environment I can rely on.

I don't care if jsfiddle still exists tomorrow. I just use it to quickly try something and immediately share it with others.

I don't put anything I care for on machines I don't own. I own many machines in the cloud. They are beautiful. Because they are all the same. They are virtual. They are cheap. I can create them with a click. There are so many vendors. If one of them would go away, it would not tamper with my ability to create new machines.

> I own many machines in the cloud.

> They are virtual. They are cheap. I can create them with a click.

If they are virtual, you don't own them. You own an 'I promise really really hard' of some vendor at best.

I own the virtual thing. It's my data. Yes, the vendor could illegaly tamper with it. Or legaly stop providing me service. But the beauty of the cloud is that it would not affect me. Because I can replace any vendor with a click.

I think you're confusing the buzzword "cloud" for "rented virtual server".

None of which has anything at all to do with installing a fucking tool chain.

> I own many machines in the cloud. They are beautiful.

I was talking about web apps, but w.r.t. VMs... sure, at the price of your pocket though? I can run my home computer all I want and not pay for anything except the electricity and internet.

As someone who learned programming as the web grow, I was like you, but I now I see WebAssembly as the future of the web. Lots of amazing and horrible things will emerge. It's better to catch up now, than 2 years later when it will be everywhere.

BTW you DON'T need WA if you don't have performance issues with your current web application.

I only do what I like. So I don't need to catch up with a technology if I don't like it. And if I need a toolchain, I am not tempted to use wasm.

As for performance: I do a lot of machine learning in the browser. So performance is something that I am interested in.

npm, bower, webpacker,... sounds like a toolchain to me.

"There is a principle which is a bar against all information, which is proof against all arguments and which cannot fail to keep a man in everlasting ignorance—that principle is contempt prior to investigation." -William Paley

So you mean applications that I never get to see the code, because they are hidden in servers I don't have access to?

Sounds like a strange duality of criteria to me.

I'm pretty sure someone will write a Forth for WA, if it's not done already. You'll even get a REPL for the assembly, then.