
JSIL - .NET bytecode to JS compiler - cobrausn
http://jsil.org/
======
j_s
There are a handful of projects translating C# to JavaScript:

\- [http://sharpkit.net/](http://sharpkit.net/) (commercial)

\- [http://scriptsharp.com/](http://scriptsharp.com/) (closed compiler)

\- [http://www.saltarelle-compiler.com/](http://www.saltarelle-compiler.com/)
(open source)

~~~
dested
I am very partial to saltarelle. It supports c# 5.0 constructs like async, c#
2.0 constructs like generics, and everything in between. It has a full suite
of tests and relatively active. I have a lot of full projects implemented in
it from 60fps canvas games to just normal sites. If anyone is interested in
seeing some stuff, or just chatting about it, let me know.

~~~
_random_
Yes, please! Post some links to samples. How easy is it to port an existing
XNA/MonoGame project?

~~~
dested
To be fair, I've never done a port, always a custom implementation.
[http://oursonic.org/](http://oursonic.org/) is my favorite personal project.
You can see the source at
[https://github.com/OurSonic/OurSonicSharp](https://github.com/OurSonic/OurSonicSharp)

[https://github.com/OurSonic/OurSonicSharp/blob/master/OurSon...](https://github.com/OurSonic/OurSonicSharp/blob/master/OurSonic/Sonic/Sonic.cs#L524)

maps to

[https://github.com/OurSonic/OurSonicSharp/blob/master/Output...](https://github.com/OurSonic/OurSonicSharp/blob/master/Output/OurSonic.js#L6923)

As a bit of self promotion, if anyone is interested in helping on this
project, or any other web based c# -> js game, shoot me an email dested@gmail
:-)

------
positivejam
So, if one were to use this or something like it, how would you handle DOM
interaction? Write JavaScript by hand for that, and have it call out to JSIL-
generated code?

~~~
kevingadd
Like gecko said, you can use C#'s 'dynamic' feature to grab references to JS
objects from the DOM and do late-bound manipulation of them.

Functions can also have their body entirely replaced by a JavaScript
expression, and it's done using an attribute so that it doesn't affect how
your code runs in native .NET. This is used in parts of the runtime library
and in some of the examples, like so:

    
    
            [JSReplacement("document.getElementById('speed').innerHTML = $text")]
            static void WriteSpeedText (string text) {
              Debug.WriteLine(text);
            }
    

You can also directly embed raw JavaScript into function bodies, like this:

    
    
            var a = 2;
            var b = 5;
            Verbatim.Expression("print($0 + $1)", a, b);
    

That allows you to embed particular JavaScript constructs that the compiler
won't normally generate, call out to things like jQuery directly, etc. The
downside to this is that you've now written something that won't run in any
other .NET environment, but you can always wrap it in a JavaScript-only
conditional.

~~~
positivejam
Cool, thanks for the explanation.

------
cobrausn
[http://www.playescapegoat.com/](http://www.playescapegoat.com/)

I thought this was a pretty cute little example game.

~~~
_random_
Makes you think, doesn't it: MonoGame+XNA => Windows, Web, iOS, Mac OS,
Android, Linux, PS3/4, XBOX.

------
manojlds
Good approach using bytecode so that any .NET langugage can be supported.

~~~
Romoku
Honestly the JavaScript it generates isn't very nice to read. I'd rather use a
language like TypeScript which tries to generate idiomatic JavaScript.

~~~
emn13
I'd rather it'd go the other way: please generate hopelessly unreadable but
optimal javascript. However, include the original source as comments in some
debug mode.

In my experience with coffeescript, the idea that the source is really
readable is only somewhat true. Sure, you can read what's going on. But
fancier features aren't always trivially translated; and even where a
translation is trivial the small differences in syntax mean that in a large
enough codebase it can take some time to find the corresponding source line.

Furthermore, because the code is supposedly "easy to read" that means it
_must_ be fairly close to javascript native, and _that_ means (for instance)
either a heavy abstraction (JSIL) that's probably slow, or exposing lots of
unfortunate javascript quirks (coffeescript) such as 0 vs. null vs. undefined
vs. false and/or => vs. ->. Basically, to reason about coffeescript you often
enough need to understand in detail how it's translated to javascript; at that
point you've lost any productivity gains you were hoping for but are still
paying the costs in terms of poor tooling and browser integration.

If you're using javascript like assembly, treat it like that: please don't
waste my time being sorta-almost-but-not-quite readable. Just make fast,
robust, no-leaky-abstraction javascript, please.

------
brianberns
What happens if your program uses classes from the .NET Framework, like List
or Dictionary? Does the framework IL get translated to JavaScript and sent to
the browser too?

------
matra
To add my 2c: We have a great esxperience using JSIL for executing some C#
business logic on the clinet to make the page more responsible. By chaninig
single c# file we get updated functionality both on client and on the server.

------
memracom
Is there anything like this that emits JVM bytecodes? It would be interesting
to write C# code to run on the JVM.

~~~
icebraining
Search and you shall find:
[http://dev.mainsoft.com/Default.aspx?tabid=267](http://dev.mainsoft.com/Default.aspx?tabid=267)

