7 ms·

I get the attraction for compiling a non-web language (say Python) so that you can write Python and have it run in the browser, but since Typescript already com

by vosper 9y ago

I get the attraction for compiling a non-web language (say Python) so that you can write Python and have it run in the browser, but since Typescript already compiles to JS I don't really get it. What am I missing? Can it be faster, or do more/different things?

shakna 9y ago
> It aims to provide everyone with an existing background in TypeScript and standard JavaScript-APIs with a comfortable way to compile to WebAssembly, eliminating the need to switch between languages or to learn new ones just for this purpose. Learn WASMs APIs without the need to learn another language seems to be the goal.
Ironchefpython 9y ago
> Can it be faster, or do more/different things? Currently, no. Ostensibly, there is the possibility for significant execution speed improvements though AOT optimization in the compiler, and simpler (and therefore faster) JIT compilation in the browser. Currently however, interaction with the DOM API from webassembly is a bad experience, making it a poor choice from most browser-based apps.
bcoates 9y ago
You get it. It's more of a dying-on-Everest-because-we-can than something you'd actually want to use.
deleted 9y ago
[deleted]
JasonSage 9y ago
I don't think so. From what I understand, calling WebAssembly functions from JavaScript (and vice-versa) incur a runtime penalty that's way worse than calling JavaScript functions from JavaScript. As such, WebAssembly makes sense for entire applications that would be compiled—think game engines targeting WebGL, or a font rasterizer targeting canvas, etc. Since this only supports a subset of TypeScript, you won't even be able to compile your dependencies to WebAssembly, meaning that literally any code you interact with that you did not write has this performance setback.
- forgotpw1123 9y ago
  ... Until the first person ports QT or GTK and suddenly WASM is just pushing 60 PNG frames a second into a canvas.
  - tyingq 9y ago
    It may get there eventually, but currently, having to pass the JavaScript/wasm chasm for DOM manipulation is really slow. https://github.com/rust-webplatform/rust-webplatform/issues/20 https://github.com/rust-webplatform/rust-webplatform/issues/...
    - paulddraper 9y ago
      But canvas is faster.
      - orange8 9y ago
        Canvas is part of the DOM. It is a DOM element that JS can draw graphics on.
        abecedarius 9y ago
        Not a problem: you can ask the canvas for an arraybuffer to draw on, and pass that to the wasm code. I did this with asm.js in place of wasm (which didn't exist yet) in http://wry.me/hacking/Turing-Drawings/ http://wry.me/hacking/Turing-Drawings/ and you can judge the speed yourself. (As that page describes, there was some overhead from calling from JS to asm.js at least when asm.js first came out. I don't know the current figures.)
        orange8 9y ago
        asm.js is valid Javascript. It is a valid subset of js that the browser js engines understand, even for the older ones like IE 8. JavaScript has direct access to the DOM, with webassembly, not yet. It may in the future, its still in the proposal phrase (https://github.com/WebAssembly/gc/blob/master/proposals/gc/Overview.md https://github.com/WebAssembly/gc/blob/master/proposals/gc/O...) So the way to do it today would be WebAssembly -> asm.js/js -> canvas
tyingq 9y ago
I guess if you wanted source obfuscation that's deeper than a minifier it might be of some use? Not sure what decompiled WASM might look like.
- __s 9y ago
  https://serprex.github.io/Befunge https://serprex.github.io/Befunge hit Run in Chrome & you can see the 500 instruction compilationg of Mandelbrot-in-Befunge to WASM
themihai 9y ago
It's basically a new language very similar with TS. Think of CoffeScript without the JS legacy, interop and compilation mess.

by vosper 9y ago

shakna 9y ago

> It aims to provide everyone with an existing background in TypeScript and standard JavaScript-APIs with a comfortable way to compile to WebAssembly, eliminating the need to switch between languages or to learn new ones just for this purpose. Learn WASMs APIs without the need to learn another language seems to be the goal.

Ironchefpython 9y ago

> Can it be faster, or do more/different things? Currently, no. Ostensibly, there is the possibility for significant execution speed improvements though AOT optimization in the compiler, and simpler (and therefore faster) JIT compilation in the browser. Currently however, interaction with the DOM API from webassembly is a bad experience, making it a poor choice from most browser-based apps.

bcoates 9y ago

You get it. It's more of a dying-on-Everest-because-we-can than something you'd actually want to use.

deleted 9y ago

[deleted]

JasonSage 9y ago

I don't think so. From what I understand, calling WebAssembly functions from JavaScript (and vice-versa) incur a runtime penalty that's way worse than calling JavaScript functions from JavaScript. As such, WebAssembly makes sense for entire applications that would be compiled—think game engines targeting WebGL, or a font rasterizer targeting canvas, etc. Since this only supports a subset of TypeScript, you won't even be able to compile your dependencies to WebAssembly, meaning that literally any code you interact with that you did not write has this performance setback.

forgotpw1123 9y ago
... Until the first person ports QT or GTK and suddenly WASM is just pushing 60 PNG frames a second into a canvas.
- tyingq 9y ago
  It may get there eventually, but currently, having to pass the JavaScript/wasm chasm for DOM manipulation is really slow. https://github.com/rust-webplatform/rust-webplatform/issues/20 https://github.com/rust-webplatform/rust-webplatform/issues/...
  - paulddraper 9y ago
    But canvas is faster.
    - orange8 9y ago
      Canvas is part of the DOM. It is a DOM element that JS can draw graphics on.
      - abecedarius 9y ago
        Not a problem: you can ask the canvas for an arraybuffer to draw on, and pass that to the wasm code. I did this with asm.js in place of wasm (which didn't exist yet) in http://wry.me/hacking/Turing-Drawings/ http://wry.me/hacking/Turing-Drawings/ and you can judge the speed yourself. (As that page describes, there was some overhead from calling from JS to asm.js at least when asm.js first came out. I don't know the current figures.)
        orange8 9y ago
        asm.js is valid Javascript. It is a valid subset of js that the browser js engines understand, even for the older ones like IE 8. JavaScript has direct access to the DOM, with webassembly, not yet. It may in the future, its still in the proposal phrase (https://github.com/WebAssembly/gc/blob/master/proposals/gc/Overview.md https://github.com/WebAssembly/gc/blob/master/proposals/gc/O...) So the way to do it today would be WebAssembly -> asm.js/js -> canvas

tyingq 9y ago

I guess if you wanted source obfuscation that's deeper than a minifier it might be of some use? Not sure what decompiled WASM might look like.

__s 9y ago
https://serprex.github.io/Befunge https://serprex.github.io/Befunge hit Run in Chrome & you can see the 500 instruction compilationg of Mandelbrot-in-Befunge to WASM

themihai 9y ago

It's basically a new language very similar with TS. Think of CoffeScript without the JS legacy, interop and compilation mess.