Introducing the Saltarelle open source C# to JavaScript compiler.

Tags: saltarelle-compiler, c#, javascript

I have been writing web applications for a really long time. In my early days I remember looking forward to my employer upgrading from IE3 to IE4 so I could use the brand new feature of dynamically adding rows to a table in what was then called DHTML. Then, later, came Remote Scripting, which was Ajax (just 8 years earlier), implemented with IFRAMEs or Java applets. During all these years, it has become apparent to me that Javascript, while excellent for achieving smallish effects like form validation or conditionally showing text, is not well suited for developing large systems. Of course it is possible to create a great large system in Javascript, just as it is possible to build a computer that directs ship fire from gears and disks, but it is my strong belief that it is not the most cost-effective way of doing it if other alternatives are available. Then, in 2007 or so, I found Script#, a project that takes a C# project and generates a Javascript file as output. I have used this extensively over the past few years, and the idea is excellent! It brings all the productivity tools you have in C# to web development. You can use ReSharper refactorings, get (correct) IntelliSense and you won't ever se an "object does not support this property" error message again.

Unfortunately, though, development of Script# has since then all but ceased, with hardly any compiler features being added over the past 3 or so years. When .net 3.5 was new, not having implicitly typed variables or lambda expressions (or quite a lot of other features) wasn't too bad, but today it feels very old. Once again, server-side programming is an order of magnitude less annoying than client-side programming.

But no more. About a month ago I released the Saltarelle compiler. It is intended as an almost drop-in replacement for Script#, but with almost full support for C# 4. And it is also open source! Over the past weeks it has matured to the point that it is now stable and ready for public use. There is a Getting started guide for those new to the concept, and also a guide for migrating from Script#.

I do not think that this is a tool that is suitable for everything but if you are developing a fat client application in HTML (especially, but not only, if your serverside code is .net) it will make your life easier.


  • erik-kallen said

    The "almost full support" text is a link. Click it and you will get to the list.

  • Ozzie Goldschmied said

    I'm excited to hear about this Erik. I am starting on a very large project and have been playing with JSIL( Script# and SharpKit do not look as promising on the surface ) as the potential contender to help with C# to JS. I've looked through the language features page - did you implement the decimal type in JS ?

  • Pavel said

    Hi Erik,

    Looks impressive, great work. Although I must ask about how are you going to deal with BCL. Because implementing language features is one thing but you don't use the language for the sake of the its semantics (well, not only), you need some (standard) libraries to do something useful.

    What is the scope of the project? Did you abstract (or are you going to abstract) the DOM model (as an example) and expose it in C#? Or do you want to go another way around? For example, if I have some ADO.NET code, will it map to the HTML5 local database/storage somehow? How about System.Xml.Linq? How about I/O? I'm talking about client-side here because you mentioned Script# the use of which as I understand did assume that the code will be executed on the client (as an opposite to be used in node.js for example).

    I understand that this is probably a very exciting project for you and you learned quite a lot about the language internals but for me it looks more like an experiment and frankly I don't see it as something that can be used in real projects. But who knows, of course.

    P.S. Do you use (or did you consider using) Roslyn to process C# source? Seems like a perfect option.

    Anyway, good luck and take care.


  • erik-kallen said

    Pavel, library implementations are just metadata, the API is exactly what the browser has.

    It is very possible to use it in practice, I do it myself and I know of a few others who do, too. And the concept, as pioneered by Script# is well used, according to Nikhil (Script# author) Microsoft uses it extensively. And then, of course, there is GWT.

    No, I did not consider Roslyn because it was not even in beta when I started the project, and NRefactory does the job well and is open source.

  • Salvatore Aiello said

    Great Project! With features like generics, generators (yield), goto, implicit operators, indexers, ref and out params, and simple oop inheritance, the reasons to not use it start to become very slim. The ease of developing with tools like visual studio resharper make coding "javascript" incredible.

    Im using it in a couple of large scale (previously javascript) projects and have fallen in love. I make large changes across large portions of the app SAFELY, deploy with no hickups other than logic mismatches. Development output has increase substantially.

    I cant wait for the future, in particular source mapping!

    Keep up the good work

  • Roy Jacobs said

    Is it also possible to use the compiler programmatically? It would be convenient to be able to invoke the CompilerDriver on an assembly and have it return a stream instead of always writing files to disk.

  • erik-kallen said

    Matthew: Good idea about a forum, I should look into it.

    Daniel: JSIL makes Javascript out of a normal .net assembly and contains a full JS implementation of mscorlib (unless I'm mistaken). Saltarelle uses a custom mscorlib which contains only (well, almost only, it does need its own runtime lib) the methods exposed by eg. String in the browser. With JSIL you write .net code and run it in the browser, with Saltarelle you write Javascript with modern tooling.

    Roy: Not out of the box. Making it return the script as a string would not be a big deal, but in order to generate the output metadata assembly as a stream, some mcs hacking is required. This would likely mean for me to maintain a custom fork of mcs, something I am reluctant to do.

  • Janus said

    How does it compare to SharpKit, other than being open source? What kind of use cases do you consider ideal?

  • erik-kallen said

    Janus: Last time I tried SharpKit, it used the standard mscorlib (can't tell if it still does). This means that their runtime library tries hard to emulate .net, whereas Saltarelle's is a rather thin wrapper of native Javascript functionality. Not all of mscorlib was implemented either, so you'd commonly get errors that some thing or another was not defined during runtime, which is the kind of error that a tool like this is supposed to avoid. Also, I did try a few non-trivial constructs and I was not happy with the code generated by SharpKit (although this might have changed; it was a few years ago that I tried it).

    The use cases I consider ideal is any application where the cost of adding a transpiler is less than the gains you get from static typechecking and IntelliSense. It's up to you to decide where that limit is for you, but if you're writing a 10+kloc single-page application I would definitely say it's a good fit.

  • erik-kallen said

    Tomas: I don't know mono, but I don't think I'm using anything that's not standard so I would expect it to work.

Add a Comment