4 ms·

I have some ES6 compliant JavaScript to run on the browser. Now I would like to compile it into web-assembly and serve that from a server to the browser, to mak

I have some ES6 compliant JavaScript to run on the browser. Now I would like to compile it into web-assembly and serve that from a server to the browser, to make it faster to run and download. Is that possible with the modern JavaScript tools?

ben-schaaf 7y ago
Considering awsm still doesn't have a gc last I heard, I don't see what you have to gain from compiling JavaScript to it.
IggleSniggle 7y ago
Depends on the specifics of your needs. Web-assembly is still slower than the V8 JIT compiler for use cases where you want to interact with the DOM. Interaction with the DOM, of course, is one of the main reasons to deliver code to a browser. But if you need to, say, create a cryptominer in the browser, then a TypeScript variant of JavaScript can target WebAssembly. You are trading out a superb JIT compiler with look-ahead and runtime optimizations for a relatively immature compiler, however. If you want your process to run on the server, and merely pass the result to the client, you can compile JavaScript to C, and then to a binary, with QuickJs. Most folks will just use Nodejs, however (which also uses V8)
shepherdjerred 7y ago
From what I've heard WASM isn't a viable alternative in the first place. It's good for compute-heavy tasks, but the overhead involved in going from browser to native to browser is too much to make WASM an alternative to what JavaScript is usually used for -- rendering interfaces and making pages interactive.
- fold_left 7y ago
  > From what I've heard WASM isn't a viable alternative in the first place. It's good for compute-heavy tasks, but the overhead involved in going from browser to native to browser is too much to make WASM an alternative to what JavaScript is usually used for -- rendering interfaces and making pages interactive. I don't think that's the case anymore: https://dassur.ma/things/is-postmessage-slow/ https://dassur.ma/things/is-postmessage-slow/
  - snek 7y ago
    Article is unrelated. The overhead for Wasm is from copying structs into and out of the Wasm's linear memory. Wasm only has ints and floats at the boundary, so you have to copy everything into structures it can understand. Note that there is work to improve this (interface types, anyref, etc), but we're not there yet.
fabian2k 7y ago
Web assembly isn't inherently faster than well-optimized Javascript. You save the parsing and compilation overhead of JS, but right now the focus with web assembly isn't on speed yet. You also can't just compile any Javascript to WASM, the closest thing to this is AssemblyScript: https://github.com/AssemblyScript/assemblyscript https://github.com/AssemblyScript/assemblyscript This compiles a subset of Typescript to web assembly. And you have to take "subset" seriously here, web assembly is very limited in how memory is managed, you can't just drop your Javascript in there and get web assembly out.
marijn 7y ago
It is, if you include a JS interpreter in your wasm bundle. But it isn't a good idea. JS is a language that needs a runtime, the browser _has_ a JS engine, and not using that would just be counterproductive and wasteful.

ben-schaaf 7y ago

Considering awsm still doesn't have a gc last I heard, I don't see what you have to gain from compiling JavaScript to it.

IggleSniggle 7y ago

Depends on the specifics of your needs. Web-assembly is still slower than the V8 JIT compiler for use cases where you want to interact with the DOM. Interaction with the DOM, of course, is one of the main reasons to deliver code to a browser. But if you need to, say, create a cryptominer in the browser, then a TypeScript variant of JavaScript can target WebAssembly. You are trading out a superb JIT compiler with look-ahead and runtime optimizations for a relatively immature compiler, however. If you want your process to run on the server, and merely pass the result to the client, you can compile JavaScript to C, and then to a binary, with QuickJs. Most folks will just use Nodejs, however (which also uses V8)

shepherdjerred 7y ago

From what I've heard WASM isn't a viable alternative in the first place. It's good for compute-heavy tasks, but the overhead involved in going from browser to native to browser is too much to make WASM an alternative to what JavaScript is usually used for -- rendering interfaces and making pages interactive.

fold_left 7y ago
> From what I've heard WASM isn't a viable alternative in the first place. It's good for compute-heavy tasks, but the overhead involved in going from browser to native to browser is too much to make WASM an alternative to what JavaScript is usually used for -- rendering interfaces and making pages interactive. I don't think that's the case anymore: https://dassur.ma/things/is-postmessage-slow/ https://dassur.ma/things/is-postmessage-slow/
- snek 7y ago
  Article is unrelated. The overhead for Wasm is from copying structs into and out of the Wasm's linear memory. Wasm only has ints and floats at the boundary, so you have to copy everything into structures it can understand. Note that there is work to improve this (interface types, anyref, etc), but we're not there yet.

fabian2k 7y ago

Web assembly isn't inherently faster than well-optimized Javascript. You save the parsing and compilation overhead of JS, but right now the focus with web assembly isn't on speed yet. You also can't just compile any Javascript to WASM, the closest thing to this is AssemblyScript: https://github.com/AssemblyScript/assemblyscript https://github.com/AssemblyScript/assemblyscript This compiles a subset of Typescript to web assembly. And you have to take "subset" seriously here, web assembly is very limited in how memory is managed, you can't just drop your Javascript in there and get web assembly out.

marijn 7y ago

It is, if you include a JS interpreter in your wasm bundle. But it isn't a good idea. JS is a language that needs a runtime, the browser _has_ a JS engine, and not using that would just be counterproductive and wasteful.