WebAssembly support

[GerjanOnline]

Now that WebAssembly is out of preview (https://lists.w3.org/Archives/Public/public-webassembly/2017Feb/0002.html), is this something you consider as an alternative output?

Personally, I think it can give F# a head start and maybe drive the F# adoption as a whole. You guys have done incredible job by building this "new webstack" but supporting WebAssembly may give it an extra enormous boost.

It is just a question, I have not read the specs of WebAssembly and did not look at the limitations. I am just curious what you think about this matter.

[alfonsogarciacaro]

There seems to be a lot of hype (and confusion) about WebAssembly ;) I've read a bit about it, but I haven't fully understand it yet and even if it's out of preview now (which just means browsers can enable it by default), I don't think it means that WebAssembly is already a finished product.

According to its high level goals right now WebAssembly only has the same functionality as asm.js, and if you look at its specs you'll see that's mainly designed to crunch numbers: only numeric types (no string, etc), no garbage collection, etc. This makes it very difficult to target WebAssembly from a higher level language like F#. For reference, see why Typescript cannot be compiled to asm.js.

The goals also say that there'll be more features coming and support for other languages than C/C++. I think also Icaza commented they want to port the .NET platform to WebAssembly someday. So I guess it's in the horizon, but we still have to wait :) Anyway, now that WebAssembly is supported by the browsers, there'll be more libraries coming for intensive computations and you should be able to use them from F#/JS.

[GerjanOnline]

Thanks for your answer, I also read scala-js/scala-js#1747 that was also mentioning the lack of GC.

Conclusion is: little more patience :)

[alfonsogarciacaro]

Yes, we must wait. But that's OK, we programmers are always waiting for the "next big thing" :)

Anyway, although any performance promise is always very appealing, take into account that the main benefits of WASM will be in the parsing and compilation times, which are not that bad for most applications (and JS execution performance in V8 keeps getting better and better). And as commented above, I'm pretty sure that there'll be many libraries coming for computational intensive tasks that'll you be able to consume from your JS/F# apps (three.js comes to mind).

[jslegers]

I understand that TypeScript is not intented to be compiled to asm.js, C/C++ or WebAssembly (and I expect that), the ability to export a language like Flow or TypeScript to typed AST in some way or another would be a good first start. With the TypeScript core devs not interested in this feature, it would at least open up the possibility for other teams to implement TypeScript to WebAssembly, TypeScript to C/C++ or TypeScript to asm.js conversion wherever possible.

[jslegers]

Those also interested in converting staticly typed variations of JavaScript to asm.js, WebAssembly or C might want to take a look at ThinScript, TurboScript or AssemblyScript.

ThinScript compiles to JavaScript, WebAssembly, and C. TurboScript compiles only to JavaScript and WebAssembly. AssemblyScript compiles to WebAssembly only.

Each of these languages have been inspired by TypeScript, and the latter is a subset of TypeScript.

I'd like to thank @RReverser for pointing me in the direction of these languages.

[alfonsogarciacaro]

@jslegers Now that's something very interesting 😉 If we just have a language very similar to typed JS/Typescript it should be easy to target it using Fable. We just need an AST specification like this one and a function to transform that AST to actual code.

[jslegers]

I like where TurboScript is heading :

AssemblyScript is only two weeks old, so it's still too early to see where that one is heading... but that one sure does look promising as well!

[ShalokShalom]

Any news?

[alfonsogarciacaro]

@ShalokShalom Compiling Fable to WASM is not a priority at the moment, if it happens it would be, as discussed above, compiling to a JS-like language that targets WASM. Apparently the languages mentioned above haven't evolved much so I'm not sure. Recently I had a look at https://github.com/ballercat/walt but it seems to also be in an early stage too.

You may also want to have a look at https://github.com/ncave/dna-redux

[7sharp9]

https://caniuse.com/#feat=wasm

Most browsers now support it by default. Rust compiled to wasm seems to be of fairly easy todo as of now.

[ncave]

@7sharp9 A possible path forward (aside of completely rewriting Fable to target Rust, which is a large undertaking) will be to produce output that AssemblyScript can consume, and rewrite the Fable BCL to target it too. Unfortunately AssemblyScript is still missing important features like closures and iterators.

[7sharp9]

Wouldn’t targeting assemblyscript be just as large an undertaking?

[ncave]

@7sharp9 In theory should not be that big, once it supports a sufficiently large subset of javascript.
But as usual In theory there is no difference between theory and practice. In practice there is.

[7sharp9]

Rust targets wasm but also seems to have quite advanced support, I think all sorts of rust syntax can be represented. e.g: https://rustwasm.github.io/wasm-bindgen/examples/closures.html