

New C# to Javascript compiler released - erik-kallen
http://www.erik-kallen.se/blog/saltarelle-open-source-c-to-javascript-compiler

======
skrebbel
As I see the author reads these comments, I'd just like to add that this makes
me very excited. C# is my favourite language by far, combining some of the
most powerful (mainstream) language features with some of the most powerful
dev tools out there.

Having the ability to run the same code in the browser and on the server, _in
C#_ , is really a big thing for me.

I think the debugging problem stated in many comments here is overrated: If
you're writing an app the size that seriously benefits from the modularity,
the tool support and the type checking of a language like C#, you will have a
relatively small amount of code directly touching the DOM. All of that other
code can be simply unit tested in C#-o-world, straight from the dev
environment. If you're writing C#, don't test and debug like it's JS!

Surely such an approach won't catch all bugs and the occasional leaky
abstraction (or compiler bug), but it should get one pretty far. Some in-
browser unit testing lib together with the fact that the generated JS is quite
readable indeed, should help me get the rest of the way.

Can't wait to dive in!

~~~
michaelwww
After the initial curve of getting VC10 configured right, I did an inheritance
test. It worked (copied base class prototype, called base constructor with
this.) Minutes later I was happily converting C# code to nicely formatted
JavaScript. Having spent the last two weeks converting JS to Dart (basically a
one way process because you don't want to look at Dart->JS), I'd say this
project is a winner and immediately usable. I'm positive there are C# features
and libraries that don't convert well, or at all, but I'm not interested in
those in the browser any way.

------
bdfh42
The very best of luck when it comes to debugging the code when it is running
in the browser.

Maybe your experiences are different to mine but I avoid such abstractions
wherever possible.

It has become fashionable to say things like "JavaScript ... is not well
suited for developing large systems" - indeed so much so it often passes
without comment but when it is JavaScript that will be run by the browser then
JavaScript is what you should be writing.

~~~
marcelvr
"... but when it is JavaScript that will be run by the browser then JavaScript
is what you should be writing."

So by that logic, one shouldn't be writing C# that targets the CLR either, but
should rather be coding in MSIL directly. Mmm, no thanks!

~~~
weego
Come on, we all know that isn't a logical equality.

~~~
giulianob
Once the debugging tools are able to keep everything abstracted then you no
longer need to dig down. Example is of course writing assembly.

------
Fizzer
Looks impressive!

I'm curious how you're doing the parsing. I see that you reference both
NRefactory (which reads C#) and Cecil (which reads IL) -- can you talk about
how are each of these used and how you combine them?

Also, did you consider using Roslyn (Microsoft's official C# parser)?
Obviously it's still beta, but once it's complete would it remove the need for
Cecil and NRefactory completely?

~~~
erik-kallen
Why would I want to use the proprietary Roslyn when I have a working solution
with the open-source NRefactory and Cecil?

~~~
Fizzer
I can think of a dozen reasons off the top of my head. But if you prefer to
avoid proprietary utilities that's understandable.

------
OllieJones
Wow! A great hack on hacker news! Thanks Erik. Don't let the griping grind you
down.

------
acron0
Not entirely the same, but for those of us on Window, I prefer the look of
<http://jsil.org>.

~~~
erik-kallen
JSIL is also great, but its philosophy is that yo write .net code and run it
in the browser, whereas Saltarelle's (and Script#'s) is that you write
Javascript but with better tools. Also, the script that JSIL generates is very
far from what you would write by hand, whereas that generated by
Saltarelle/Script# can be distinguished from hand-written script primarily
because the indentation is always correct and there is never an accidental
loose comparison operator.

~~~
azakai
Could you not somehow reuse the JSIL code generator, and add things for the
approach you took in Saltarelle (good integration with JQuery etc.)?

Another question, did you do any performance comparisons of Saltarelle? (to
normal C# builds, to JSIL, or anything else?)

~~~
erik-kallen
I think the tools fill different purposes, so integration with JSIL is
absolutely a possibility in the future. I did not do any speed comparisons, I
just translate what you write in C# to the equivalent script, so if you write
a fast script it will be fast, if you write a slow script, it will be slow :)

~~~
azakai
Well, how you create data structures might matter for performance - if you
turn C# structs into JS typed arrays for example and do the proper
conversions, that could be much faster than simple JS objects or even arrays.

------
DougWebb
I don't see how you can really use this without already being very familiar
with Javascript. While you're writing your code you'd need to be constantly
aware of how the code will be translated to js (so you can use the correct
attributes and define datatypes correctly), and you'd also need to be aware of
avoiding. NET library classes that can't be used by the translated js. It
seems easier to just learn to manage large js projects.

~~~
eranation
The reason I'm looking for either C# / Scala JS compiler is that I'm a static
typing fan, I am an old school developer who likes IDEs and like discovering
API by pressing ctrl+space, instead of mentally knowing it or constantly
checking the API docs, I know it's against the trend, and not considered cool,
but this gets me working software out the door. I'm much more productive and
have much less bugs while writing old school, unpopular Java, and using the
IDE's (eclipse) sugar features. Scala is now my favorite language (I really
hope it was a little more new dev friendly, it can become very syntax
overwhelming sometimes) as I can many of the functional features in Ruby /
Python / JavaScript / Clojure, but still stay in Static Java land.

Another thing static typing gives me that I really wish I had in JavaScript,
is (almost) worry free refactoring.

In Java, I can extract methods, constants, delegates, change method
signatures, rename members, fix typos in code, and never to worry I copy
pasted something wrong.

I have yet to find such a way to do it safely in JavaScript / CoffeScript or
any other dynamically typed language. (feel free to point if I'm missing
something, I said I'm not that a great of a developer)

So maybe I'm just not good enough as a developer, but I like IDEs to protect
me, perhaps I'm not smart enough to use VIM / Emacs / TextMate, and I can't
memorize APIs. Static typing + functional features make me the most
productive. So C# / Scala / Java 8 javascript compilers are on the top of my
wish list.

~~~
DougWebb
I hear you, but I can't agree. Maybe it's my background. For 13 years as a
professional developer my primary languages were Perl and Javascript, using
Vim and the Unix command-line as my IDE. For the past 1.5 years I've swapped
C# for Perl and Visual Studio for my IDE (still have a vi emulator though.)
Intellisense is definitely useful, but I find it gets in the way a lot... both
literally by overlapping the code around the code I'm typing, and figuratively
by trying to insert text while I type which causes me to double-type
characters and backspace a lot. It does help with remembering (not learning)
APIs, but that's one of my concerns about translating to js: Intellisense
won't know which APIs are usable and which ones are not. If you're a C#
developer who's dependent on Intellisense, it's going to mislead you here.

Regarding refactoring, it's hardly worry free for me. I always have to double
check what VS is going to do when I use its refactoring tools, because
sometimes it makes a significant mistake. Now, that's often caused by the way
I wrote some code and I have to fix it up as part of my refactoring, but I
would have discovered that while refactoring manually too, and if I trusted VS
I wouldn't have discovered it at all. So VS helps a bit with the typing, but
it's not much faster than I'd be without it. A lot of that is probably because
I learned to refactor using vim, grep, sed, and other Unix command-line tools,
so I have no problem doing large-scale refactoring changes touching thousands
of lines over a 100k+ line codebase. Extracting a method is childs play in
comparison, and I don't mind the extra few seconds it takes to do it manually
exactly the way I want it.

There is definitely a need for better javascript editing tools. VS, with the
right plugins, wouldn't be bad, but I'm not sure Intellisense can really cut
it. When I'm putting some code into an MVC template or js file and I want to
refer to a jQuery plugin I know is loaded by my layout template, there is no
way for Intellisense to know about that plugin or its API, so it can't help
me. In contrast if I load my app in Firefox and use Firebug's console and
debugger, I can type in some code and it's able to show me the API in real-
time because it's reflecting the live javascript objects as I type. That's the
kind of intellisense I want.

~~~
randomfool
For statically typing Javascript, I strongly recommend Google's Closure
toolset- it uses JS comments to statically type and validate your code, plus
you can either run it compiled or uncompiled.

<https://developers.google.com/closure/>

There are no editors that give you the nice intellisense bells and whistles,
but static typing is by far the most important for me.

~~~
eranation
There were tools ones in eclipse that used comments / annotations to give you
full "static" feeling with JavaScript... I wonder where did it go...

Here is a nice side project, static typed coffee script, with eclipse IDE
support...

I really don't want to go back to GWT or move to Dart...

Scala's Javascript DSL is another hope I have, but it's still under
development

------
TazeTSchnitzel
Wow, very cool. I like C#, and the DOM is actually specified with types, so
statically-typed web dev with this would be awesome.

~~~
Hovertruck
You can get the majority of this functionality with Closure Compiler though,
without needing to abstract the entire language away.

~~~
TazeTSchnitzel
That's true, but I don't really like the closure compiler's syntax.

------
jaz
I came across a similar project on /r/csharp last week. The project's called
Blade, and is available here - <https://github.com/vannatech/blade>

~~~
erik-kallen
Saltarelle is way more complete, though.

------
randomfool
My largest criticism for projects like this is that I absolutely abhor running
into compiler errors. When you don't fully trust the compiler, it suddenly
becomes a suspect when code isn't working like you think it should.

Given decent source maps to allow debugging through the original code, I don't
think solutions like this are terribly different than native Javascript. The
primary difference though is that I trust the browser JS interpreters and VMs
more than I trust many X->JS compilers.

------
consultutah
We use an older version of Script# for a very large site at work. This looks
like it might be worth trying to upgrade to.

But what I really want is a way to convert Silverlight to JS. I don't care
whether it is source or binary level conversion, but it would be awesome to
take projects we've written in silverlight and run them on any browser without
a plugin.

------
0ptr
I totally agree that JavaScript can easily end up being a huge mess especially
when project grows. Using more strict language like C# can help on that. I
have to try this, good job!

~~~
ecocentrik
There are frameworks and best practices for organizing JavaScript heavy
projects. I'm all for solutions to unify front and backend web application
development so cheers to Erik for developing this, I've just never been a fan
of cross language compilation.

~~~
eckyptang
Flash, silverlight, Java, native apps...

------
scorcher
I don't really get this. Surely JavaScript and C# are so hugely different that
any converted code would be horrific? Wouldn't it be simpler to just write
JavaScript in JavaScript?

~~~
jeswin
\- Translating a statically-typed Object Oriented language to JS wouldn't
produce hugely different (/horrific) code. From inheritance to lambdas, there
are comparable features available in JS. Going from JS to C# might be harder
though.

\- It might be simpler to write JS, but I can imagine people wanting to see if
type-safety has benefits.

~~~
erik-kallen
That's right, it doesn't get horrific until you use goto or yield (which don't
exist in Javascript so they have to be emulated).

~~~
TazeTSchnitzel
Some browsers, and ES Harmony, have yield. You could add a compiler switch to
use native support, although only Firefox seems to support this just now.

Curious to see how you managed the emulation - splitting up a function? Web
workers? :)

~~~
erik-kallen
for (;;), continue and switch.

------
hhudolet
Looks cool, but need more docs and samples (for each feature)!

------
NonEUCitizen
Does this include a library for accessing Canvas ? Thanks.

------
prpatel
good grief... just learn some fscking JavaScript already! It's not _that_
hard!

------
goggles99
How does this compare to <http://sharpkit.net> (free for small and open source
projects) Feature wise? SharpKit seems more complete (language support and has
source map debugging support on Chrome). Also support for all popular JS
libraries.

~~~
erik-kallen
SharpKit is only free as long as you want to use it for projects that don't
need it (the limit is like 2k lines or something). When I last tried it I was
not very happy with the code it generated. Additionally, it uses the standard
mscorlib so it is not unlikely that you will end up calling methods that are
not implemented (which is the very problem the tool is designed to avoid). If
it were open source, I would have contributed to SharpKit instead of rolling
my own, but it is not.

When it comes to the language support, I think Saltarelle is slightly ahead,
as it supports goto and yield (I don't count SharpKit's implementation of
yield which translate 'yield return "x"' to '$yield.push("x")' and then
returns the $yield array).

~~~
goggles99
Thanks for the reply, This seems to be a very nice tool. I will definitely try
it out. Though I don't think that I will switch unless debugging is
implemented (via source maps) like SharpKit has. This is invaluable to me at
times.

------
WayneDB
Thanks Erik! I haven't touched Script# due to the fact that development
stalled and it (was) closed source.

Looking forward to seeing how this performs.

~~~
josephcooney
Script# is alive and well AFAIK. It is hosted on github, with about 9 commits
from the primary author in the last week.

<https://github.com/nikhilk/scriptsharp/commits/master>

~~~
erik-kallen
But all those commits are, unfortunately, tiny. Also the compiler is not open-
source only the runtime library (which Saltarelle uses a modified copy of).

