Hacker News new | ask | show | jobs
by dmitriid 3247 days ago
> 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

1 comments

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.

> you're welcome to prove me wrong

Ahahah what?

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

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.