Open qwertie opened 9 years ago
I've successfully translated with JSIL application with ~12000 LOC (I calculated only lines that contains ";" symbol, but some of them may be not used as some projects are shared). This project is depends on mscorlib, System.Core, Irony. Of course, you will need to do some work to adapt your application (and probably report or fix some bugs in JSIL).
Last time when I looked on other similar tools (about two years ago) most of them were able to translate only C# source code and not dlls, that's why I've selected JSIL.
AFAIK nobody else has solved the problem of large application full translation yet. JSIL comes the closest. It's possible one of the new compilers to the market (there's a Roslyn-based one that seemed promising) will get all the way there before JSIL does.
It's intended that in the future you will be able to translate mscorlib/system.core/etc and have the vast majority of them Just Work. It's largely blocked on a bunch of compiler infrastructure work that needs to happen (people like @iskiselev have graciously done some of the work already)
The built-in BCL stubs in JSIL are extremely minimal on purpose - the goal has never been to reimplement the whole BCL by hand, so it just implements the methods that are needed to the extent necessary to pass tests. This means ports are a pain, but it's sufficient for many simple applications.
As far as runtime feature support goes, JSIL has the broadest and deepest support of any of the available compilers I know of. Most of the others are doing translation from C# source to JS, or intentionally sacrifice semantics (for example, not doing by-value copying for structs) or rule out entire classes of features (generators or pointers or what have you). JSIL is designed to be unopinionated about your IL and translate anything it can to JS, preserving behavior.
The recent addition of P/Invoke support means that if you have native libraries you can translate via emscripten, then you can port C# that relies on them as well. Pretty much anything up-to-but-not-including actually porting the windows or linux kernel to JS is on the table as far as I'm concerned ;-) Whatever it takes to make your app work.
Currently Microsoft's team started implementing .Net -> LLVM translator. As far as I know, this project is very young now, but probably later .Net->LLVM and than LLVM -> Javascript (with Emscripten) will be another full-enough option.
The .NET -> LLVM and route and similar approaches are actually fundamentally different in that they don't interact with the JS GC heap or DOM APIs directly. This means that scenarios where you directly need to interact with JavaScript or JS APIs (like WebGL, Web Audio) become more complicated. You also pay the cost of starting up a whole .NET runtime that you might not be using. Emscripten faces most of these obstacles right now.
In the long run that might still be the correct approach, though, especially since the JS version of the .NET runtime could just be sitting on a CDN somewhere and its compilation can be cached by the browser.
Interesting, thanks very much for the answers everyone! Is there a status page with any more details?
Oh and @kg I've been wondering, do you know how can one get paid to work on cool stuff like this and WebAssembly? Because I am running low on cash.
Hi @kg and @iskiselev. Hope you are doing well. :) I have been thinking about this project lately and I was curious if you have decided (or are deciding) to use Roslyn to compile JSIL at some point? I did a search in open issues for Roslyn and found this thread. I also see Roslyn mentioned if a few issues, but it looks like it has to do with Visual Studio integration and not compilation so I wanted to see. I see you make mention of it above, and I can only imagine you are talking about duoco.de, which is (unfortunately) a paid product. Thanks for any insight you can provide!
@Michael-DST, Roslyn is really cool thing, but it works with C#/VB. As JSIL tries to translate any .Net library written on any language (F#, IL, any other) I don't think that Roslyn could help JSIL greatly. On other side, JSIL may use some additional Roslyn-based tools for some tasks (probably it could be used for better source map generation if source was in C#/VB).
Thanks @iskiselev for the info. I was not aware that Roslyn was C#/VB.NET only! I thought it enabled a ".NET" AST. I can only imagine that at some point it will support all languages. Thanks for the information. :+1:
Today I found a surprisingly long list of tools for transpiling to JS. But the web sites for these tools say frustratingly little about how good they are. CIL has a lot of features, and the BCL is huge; how reliably does JSIL transcode them, and how well is the BCL supported?
In particular, how likely is it that I could convert a random set of DLLs that depends mostly on mscorlib with, oh, maybe 20,000 LOC, to working Javascript? Do any of JSIL's competitors do a better job?