An actually usable .NET virtual machine in javascript (github.com)

55 points by Meai ↗ HN
Small comment: I see this as a dart contender, from what I hear, there is a Visual Studio debugger coming, meaning we will be able to debug c#, but have it walk through javascript on page. Sounds amazing to me, thought I should share. Follow the link in the readme to more detailed documentation. The amazing thing here, is that the produced javascript is small enough to warrant using it for real projects.

The compiler is not yet open source, they said that if there is more interest, they will open it later.

24 comments

[ 4.6 ms ] story [ 44.5 ms ] thread
Small comment from me: I see this as a dart contender, from what I hear, there is a Visual Studio debugger coming, meaning we will be able to debug c#, but have it walk through javascript on page. Sounds amazing to me, thought I should share. Follow the link in the readme to more detailed documentation. The amazing thing here, is that the produced javascript is small enough to warrant using it for real projects.

The compiler is not yet open source, they said that if there is more interest, they will open it later.

C# has closures but not when evented. That's the problem with these Language X to js projects. No language is really like JavaScript. Except CoffeeScript, of course. I'm sure you can write clean C# dom code but it won't be like js or like Silverlight. It will need new patterns.
C# has closures but not when evented.

What does this mean? How do closures behave any differently when a delegate is assigned as an event handler?

    var outer = 2;
    var btn = new Button()
    {
        Text = "Click Me"
    };
    btn.Click += (obj, eventArgs) =>
    {
        var local = outer + outer;
    };
How is the above any different/better/worse than what javascript can do?
I reserve the right to be wrong here, but I'm pretty sure in your example outer will be be null on the onclick.
Ok I tested it and you have access to outer here. I must be thinking of something else. Asynchronous web requests?
outer will be 2

A closure is created for the anonymous function, allowing access (by reference) to the non-local variables in the containing method.

Outer is (implicitly) typed as an int, so it cannot be null under any circumstances. The default value for ints is 0. However, outer will be 2 in this case. Environment capture makes it do what it looks like, just like javascript.

I don't know what you mean by "has closures but not when evented."

If outer were anything but 2 in the click handler, it wouldn't be a closure, which by definition closes over its environment.
What? C# has closures but the CLR doesn't. For the CLR, it's just yet another object of some class, where the class has a relatively funky name.

True about the new patterns, btw. I guess you'd need to port a jQuery to .NET first in order to be productive.

As someone writing a compiler which targets Javascript, I'm curious: what exactly is the problem you are referring to?

No language is really like x86 machine code, either, but that doesn't seem to have stopped people from writing anything-to-x86 compilers.

Coincidently, I'm currently creating a similar project: https://github.com/chrisdunelm/Cil2Js

This is absolutely not yet ready for real use, but can convert a sub-set of CIL to JavaScript and is fully open source :)

Update:

il2js and Cil2Js work significantly differently. il2js interprets the .NET IL in a JavaScript virtual machine, whereas Cil2Js directly converts the .NET IL into JavaScript.

Having now looked at this il2js project in more detail, it appears to have some subtle (and some not-so-subtle) differences between running on .NET and running in JS. For example, integer division will return a double in JS; Stack<T>.Last() returns wrong end of stack on JS; no/little support for non-primitive value types; etc... Hopefully these will be sorted out soon, as it's these sorts of inconsistencies that can lead to extreme frustration.

I am unconvinced that a JS VM is a good technique, as I suspect it will be an order of magnitude slower that the same IL converted to JS (although I have no test data to prove this).

However, these aside, it's an impressive project.

If I understand correctly, one advantage of il2js should be that all the core .NET libraries won't have to be ported to JS, as the needed library methods get expanded into IL.
This will also happen in Cil2Js. Any .NET library method (including system libraries) that is implemented as CIL can be converted directly to JS.

In mscorlib however, there are many methods that are implemented directly by the .NET runtime; i.e. they are not implemented in CIL. Cil2Js will provide replacements for these, either written directly in JS, or in CIL (compiled from C# source) that will provide identical functionality.

For example, string.Length is not implemened in CIL. In fact, may of the methods on 'basic' types such as System.String, System.Array, System.Int32, etc... are implemented internally by the .NET runtime.

Nikhil Kothari's Script# ( https://github.com/nikhilk/scriptsharp ) "enables developers to author C# source code and subsequently compile it into regular script that works across all modern browsers".

Uptake was hampered in the past by the author's unwillingness to open-source the compiler; I'm not sure what the community is like at this time. http://stackoverflow.com/questions/1579192/should-i-use-scri...

Script# is being used to compile Microsoft's online Office apps from C# to JS

http://blogs.msdn.com/b/ie/archive/2011/11/22/evolving-ecmas...

(see "Larger Scale JavaScript" in there). Given that, I am assuming it is quite mature and usable.

I have little doubt that Script# is mature and usable; the project's home page lists a who's who of large internet sites that use it in production.

Unfortunately from what I can tell, expertise on usage of Script# stays locked up within each company (eg. 'a variant of Script#' from the blog post). Perhaps I am demonstrating my ignorance, but the most public activity I could find was the project's GitHub issues list.

Just because Coffescript is transformed into Javascript, doesn't make this a VM written in Javascript.
Interesting, though the first thing I looked for the was the source for the compiler. Meh, call me when it's ready.