What advantages can ScriptSharp bring to my tool kit?

Question

Currently we use jQuery to add RIA goodness to our apps, but recently we have been implementing the Coveo Search engine into our Sharepoint portal and found that ScriptSharp

Answer 1

I'd like to share my jQuery wrapper classes for Script#. You can access and use the powerful features of jQuery in your Script# project, right now.

Get it from here: http://www.springsys.com/blog/

Answer 2

I am using ScriptSharp as we speak, having discovered it about 2-3 weeks ago. Honestly, I love it. Native Javascript is a challenge, and the DOM model makes client-side programming even worse. Then I discovered jQuery about six months ago, and I thought it was a godsend. jQuery increased my productivity, but I still get bogged down often with jQuery because you still have to write and debug and tweak Javascript.

Enter ScriptSharp. It has boosted my productivity over jQuery and reduced my headaches immensely. The biggest advantages I can see are the fact that the power of C# and Visual Studio are yours while you're writing code. The power of this cannot be understated. Now the niggling little Javascript errors that used to take hours to debug are eliminated at compile time. The lines of code are probably about twice as many than with jQuery, but the productivity is so much higher, so who cares? You basically just write code, with many fewer compile/test/debug cycles. Hours become minutes.

I will say it was quite a struggle initially to get ScriptSharp to work with Microsoft AJAX until I learned of a very important step you must take in order to work with it. I pulled my hair out for days before I knew about this. (I believe this is documented in ScriptSharp's 61-page PDF Readme, but it's very easy to gloss it over.) The key is to choose the project type "Script# Class Library inside a Web Site" (or "MS Ajax Class Library Inside a Web Site") when creating a ScriptSharp library. This places the ScriptSharp project in the Bin/Scripts directory of the website, and -- very importantly -- directs the compiled output to that directory instead of to the default "bin" directory of the ScriptSharp project. Perhaps an example will be instructive:

Web Site or Application directory\
   Bin\ 
      Scripts\           <-- "..\\" config setting sends .js files here.
         ScriptSharp Project directory\
            Bin\         <-- will not be used at run time
               Debug\    <-- will not be used at run time

In short, I found this project worthwhile. I'm going to write up my own HOW-TO (which in my case involves using Web User Controls) on how to bind everything together, and post an URL back here. Now that I've figured ScriptSharp out, it's made me very productive in my RIA development. If only it were more visible, and if only the CodePlex site were still there.

Answer 3

At my last company I used Script# very extensively. I managed to write some cool controls (in fact an entire client side MVC stack) which I couldnt have done with my knowledge of javascript. However, I wouldn't use it again for several reasons

• The project is closed source and the support is not great (practically non existant since the forum was closed). There are quite a few annoyances when you use it in great depth which could be fixed if you have the source. This becomes a bigger and bigger problem the more you have invested in s# code.
• It's limited to a subset of .NET 2.0, and even then its a leaky abstraction
• Recently Javascript unit testing and VS intellisense for javascript has got a lot better so the importance of static typing is somewhat reduced
• Using it limited my learning of jquery and javascript

The tooling for js is only getting better and until Script# is open sourced, it's at a standstill.

If you're interested in cross compiling, you could also take a look at the http://jsc.sourceforge.net/ project, which lets you use .net 3.5 and compile to JS, Java, Flash or even PHP! Not sure how efficient the code that gets produced is though...

edit: there is a new project called JSIL which also rewrites .net code to JS

Answer 4

Script sharp Prototype: Microsoft’s GWT

According to this page:

• A clean language with the natural constructs.
• Easier refactoring and exploration.
• Ability to generate documentation.
• Ability to customize the script code easily.

I'm not sure if I agree with all of these, but that's the sales pitch anyway. Seems like it's typed with some OO features. Opinion follow:As I've mentioned at other times, Java and C# developers seemingly want to toss out the prototyped/untyped aspects of Javascript because they are uncomfortable with writing code that way. Untyped prototyping languages have their place.

Answer 5

The jsc compiler project enables these scenarios:

• C# to MSIL to JavaScript for browser
• C# to MSIL to JavaScript for AppJet
• C# to MSIL to PHP5 for hosting solutions
• C# to MSIL to Java for browser applets
• C# to MSIL to Java for applications
• C# to MSIL to Java for JavaCard
• C# to MSIL to C99 for native stub applications
• C# to MSIL to ActionScript3 for Flash 9
• C# to MSIL to Adobe Alchemy C for Flash 9
• C# to MSIL to C# 2.0

With some effort Visual Basic could also be used as a source language. The jsc compiler never reads your source code even if GWT and Script# do that. My compiler reads your IL.

jsc compiler is

• an experimental project
• one mans effort yet
• rather useful already.
• 3 years old.
• awaiting donations to optimize compilation time and output itself

The latest example is a plasma animation where a single implementation can be used between those platforms:

• Flash 10
• Java Applet (via canvas element)
• JavaScript
• Windows Forms
• Windows Presentation Foundation

_{(source: sourceforge.net)}