Hacker News new | ask | show | jobs
by backspaces 4014 days ago
So I should give up on JS programming, go back to C/C#/C++/Java/Swift and have them generate wasm? Kinda sad, I like JS. But I like performance too.

Is there a possibility for JS tooling? Babel etc? Or any compile-to-JS language like CoffeeScript, TypeScript etc being able to emit/convert to wasm?

Or maybe I'm missing the whole point of this? :)
1 comments
zamalek 4014 days ago
Chances are JS will remain a first-class citizen. WASM is just for those who would prefer to not use JS. Basically, if you like JS hopefully nothing will change for you, if you don't like JS you will have better options than cross compiling to JS.
link
backspaces 4013 days ago
Boy do I hope you're right! Performance is likely an issue tho. Wasm is designed to be faster, both loading/parsing and execution.

I did notice that es6 import/export works for Wasm, so I can write performant segments in C. Whew!

link
zamalek 4013 days ago
> Wasm is designed to be faster, both loading/parsing and execution.

If you want that from your JS codebase, I'm sure it would happily compile to Wasm - you'd probably find that a JS-to-Wasm compiler would be one of the first proofs-of-concept for Wasm.

link
BrendanEich 4013 days ago
This misses the division of labor behind wasm (and asm.js, and PNaCl). JS is a dynamic language, in full it needs JITting, speculative optimization based on runtime profile feedback, statically unsound type inference rescued by dynamic checks that have low-enough cost.

In contrast, wasm is for C and C++ first, and in due course many languages. The C/C++-first design point is a way of limiting scope creep and catering to important native-code use-cases (games, AI, CV, etc.). It's the starting point, not the final state. But it involves the usual static types trade-off that reduces runtime overhead.

Therefore a full JS engine in wasm would not run very fast compared to today's in-browser JS VMs, which are evolving to be JS/wasm VMs. For dynamic languages to compile to efficient wasm, we'll need the future JIT-generated wasm support and other desiderata on the roadmap. These come after the "MVP" that is co-expressive with asm.js.

So the proof of concept for wasm must start with asm.js and grow to PNaCl in full (which has had APIs and optimizations that asm.js or JS and the Web APIs have not provided yet), and then on to dynamic language runtime support. HTH.

link
zamalek 4013 days ago
That makes a ton of sense, thanks for taking the time to clarify.
link
BrendanEich 4013 days ago
No problem. I could go on (but should cut myself short to save time for other things).

Another dynamic language support part of wasm's roadmap that's post-MVP: GC support, both for GC of allocations from wasm code, and for references from wasm memory into the JS (DOM whatever) object space. One GC to rule them all, and one VM too.

link