> Too high-level, too JavaScript-centric. It’s going to take programs encoded as Abstract Syntax Trees (ASTs) as input, which seems quite wrong. GCC, clang, and

> Too high-level, too JavaScript-centric. It’s going to take programs encoded as Abstract Syntax Trees (ASTs) as input, which seems quite wrong. GCC, clang, and other real-world compilers usually generate Control Flow Graphs (CFGs) at the output stage, not ASTs. Forcing compilers to convert CFGs back into ASTs seems silly. An AST is used because it allows significantly smaller download sizes, which is quite important on the web, more details here: https://github.com/WebAssembly/design/blob/master/AstSemantics.md https://github.com/WebAssembly/design/blob/master/AstSemanti... WebAssembly is in a different situation than gcc, clang, etc. It makes sense for LLVM IR, for example, to have a CFG, as it is a compiler IR meant for optimization. But WebAssembly binaries are meant to be distributed over the web and instantiated as quickly as possible. > This decision was clearly made to try and simplify the job of WebAssembly VM implementers, at the expense of everyone else. I don't think that is the reason at all. In fact it adds work for those people to handle an AST. But the work is justified by the startup speed benefits that it brings to the web platform.