JSIL vs Script# vs SharpKit
What are the pros and cons of each JSIL, Script# and SharpKit?
My project is a MVC4 project using razor engine and C#, if it matters.
If you're looking to integrate directly with an MVC project, something like Script# or SharpKit or something is probably your best bet - I know for a fact that Script# has stuff built in to make that sort of integration easier, so I would start there.
If you do want to try using JSIL, it probably has the core features you need, but things that you might want - like visual studio integration, automated deployment, etc - are not there. At present it is primarily targeted at cross-compilation of applications, so it does a good job of that but not as good a job of other use cases.
I'll try to give a summary of reasons why you might want to consider JSIL over those other alternatives - I can't really comment on the pros and cons of those alternatives in depth since I haven't used them:
JSIL has extremely wide support for the features available in C# 4. Notable ones (either because other tools don't support them, or they're complicated) include:
Some of the above, of course, don't have complete support - to get an idea of things that absolutely will work, you can look at the test cases - each one is a small self-contained .cs file that is tested to ensure that JSIL and native C# produce the same output.
The reason for this extensive support is that my goal is for JSIL to enable you to translate a completely unmodified C# application to working JS. For all the demos up on the JSIL site, this is true, and I have a few nearly finished ports of larger real games in the wings for which this is also true.
When you want to call out from C# to JS, you can do it a few ways:
Okay, now for some downsides. Don't consider this list exhaustive:
- As mentioned above, no visual studio integration. JSIL is pretty easy to use - you can feed it a .sln file to get a bunch of .js outputs automatically, and configure it automatically with a configuration file next to the project - but it's nowhere near as polished or integrated as say, Script#.
- No vendor or support staff. If you want a bug fixed yesterday or you're having issues, I'm pretty much your only bet at present (though there are a few prolific contributors helping make things better, and more are always welcome!)
- The static analyzer is still kind of fragile and there are still gaps in the language support. Each big application I port using JSIL usually reveals one or two bugs in JSIL - not huge game breakers, but ones that definitely break a feature or make things run slow.
Hope this information is helpful! Thanks for your interest.
- Open source
- Supports a subset of C# 2.0 language only
- Can be compiled only in a separate project, cannot mix / re-use code between client and server
- Low frequency of version updates
- Does not offer support
- Not open source
- Commercial product
- Supports full C# 4.0 language
- High frequency of version updates
- Support is available
- Client / server code can be mixed and re-used within the same project
- Supports basic C# debugging for Chrome browsers
- Has a free version with no time limit, but limited to small / open-source projects
- Not open source (only libraries are open-source)
- Converts from IL (intermediate language), not from C#, which means a lower abstraction layer since code is already low-level.
Answers to feedbacks:
Developer can choose to create more complex code generation and gain more features, like support for compile-time method overloads. When specified, SharpKit generates method suffixes to overloaded methods.
Script# requires .NET 4 in order to run, but it does not support full C# 4.0 syntax, like Generics, ref and out parameters, namespace aliases, etc...
Another alternative is WootzJs. Full Disclosure, I am its author.
WootzJs is open-source and strives to be a fairly lightweight cross-compiler that allows for all the major C# language features.
Notable Language Features Supported:
- yield statements (generated as an efficient state machine)
- async/await methods (generated as a state machine like the C# compiler)
- ref and out parameters
- expression trees
- lambdas and delegates (with proper capturing of this)
- generics support in both the compiler and the runtime (invalidly casting to T will throw a cast exception)
It is implemented using Roslyn, which means it will be first in line to take advantage of future language improvements, since those will now be implemented via Roslyn itself. It provides a custom version of mscorlib so you know exactly what library functionality is actually available to you in your scripts.
What Are its Downsides?
- Because of its extensive support for core libraries and reflection, the generated output is not the smallest on the block. Minification should produce an ~100k JS file, but minification is not yet supported.
Comparisons with Other Cross-Compilers:
However, due to its custom parser, it is still stuck in C# 2.0 (without even the generics found in that version of C#). This means that the modern C# developer is giving up an enormous set of language features that most of us depend on without reservation -- particularly the aforementioned generics in addition to lambdas and LINQ. This makes Script# essentially a non-starter for many developers.
This toolkit too implements a custom mscorlib, again allowing you to know what capabilities are available to you. However, it has poor Visual Studio integration, forcing you to create all the custom build steps necessary to invoke the compiler and copy the output to the desired location.
For example, the type system is shallow and does not support representing generics or arrays (i.e. typeof(Foo) == typeof(Bar), typeof(List<string>) == typeof(List<int>)). The support for reflection is limited, with various member types incapable of supporting attributes. Expression tree support is non-existent, and the yield implementation is inefficient (no state machine). Also, a custom mscorlib is not available, and script C# files and normal C# files are intermingled in your projects, forcing you to decorate each and every script file with a [JsType] attribute to distinguish them from normally compiled classes.
We have SharpKit for two years and I must say that's upgraded the way we write code. The pros as I see them:
- The code is much more structured - we can now developed infrastrcture just like we did in C# without "banging our heads" with prototype.
- It is very easy to refactor
- We can use Code Snippets which results in better productivity and less development time
- You can control the way the JS is rendered (you have several modes to choose from).
- We can debug our C# code in the browser (Currently supported on Chrome only, but still :->)
- Great support! If you send them a query you get a response very fast.
- Support a large number of libraries & easily extensible
- The documentation is a bit poor, however once you get a hang of it you'll boost your development.
Glad if this could help!
For ScriptSharp, this stackoverflow link could be of help. What advantages can ScriptSharp bring to my tool kit?
If you have any SVN tool, please download a sample from https://github.com/kevingadd/JSIL, this is a working source code and can help you go miles.