[dmitriid]

1. One of my complaints was that yes, WebAssembly for some reason decided to target C++ first.

2. From the FAQs:

Beyond the MVP, another high-level goal is to improve support for languages other than C/C++. This includes allowing WebAssembly code to allocate and access garbage-collected (JavaScript, DOM, Web API) objects

3. News flash: some people use statically typed languages for web development: TypeScript, Elm, Purescript

[djeric3]

> One of my complaints was that yes, WebAssembly for some reason decided to target C++ first.

It's much easier to support C++ in WebAssembly. C++ and other statically typed languages can be compiled ahead of time to low-level instructions that manipulate memory or registers in a virtual CPU.

It's much more difficult to compile dynamic languages. Consider a JavaScript statement like:

let result = a + b;

If this were a statically typed language, the compiler would know "a" and "b" are integers and can compile it into a single ADD.INT assembly instruction.

In a dynamically typed language, that "+" symbol could be an integer addition, or a floating-point addition, or a string concatenation depending on the types of "a" and "b". So what should the JS-to-WASM compiler generate? It has to generate different code to handle all the different data types, including throwing an exception for invalid types.

There would be a few problems with WASM code generated by such a compiler:

1) the generated code with all this extra checking is not going to be performant, 2) the generated code would be much larger, which would hurt transfer & parsing times, 3) the compiler would essentially be outputting the JavaScript interpreter in WASM by adding all these runtime guards for types.

> Beyond the MVP, another high-level goal is to improve support for languages other than C/C++. This includes allowing WebAssembly code to allocate and access garbage-collected (JavaScript, DOM, Web API) objects

Adding GC and DOM interop will help WASM adoption, but you'll still have the issues I described above if you try to compile JS codebases to WASM.

> statically typed languages for web development

Yes, people can use statically typed languages for web dev, and if they compile them to WASM after it has GC and fast DOM interop support, they will get performance wins vs transforming their codebases to plain JS.

But there are productivity advantages from using dynamically-typed languages during development and there are existing, very large web app codebases written in JavaScript which cannot be typed.

[dmitriid]

> There would be a few problems with WASM code generated by such a compiler: > 1) the generated code with all this extra checking is not going to be performant, 2) the generated code would be much larger, which would hurt transfer & parsing times, 3) the compiler would essentially be outputting the JavaScript interpreter in WASM by adding all these runtime guards for types.

And, of course, you have full evidence supporting these statements

[djeric3]

I don't, you're welcome to prove me wrong if you want to whip up a basic prototype. I'm vdjeric on github.

My goal is to make sophisticated web apps faster, I'm not married to any particular approach.

[dmitriid]

> you're welcome to prove me wrong

Ahahah what?

You are the one claiming this. The burden of proof is on you

[djeric3]

I would say that the burden of proof is on me to prove that Binary AST is a significant real-world performance win and that it will not cause undue burden on JS engine implementors.

I don't think the "burden of proof" philosophy requires me to disprove every other possible approach, right?

I explained my reasoning for my statements in the comment itself. If you believe WASM could address this use case better, and are so inclined to build a toy proof-of-concept JS-to-WASM compiler, I'd be very interested in seeing it.