What advantages can ScriptSharp bring to my tool kit?

Asked 25/4, 2009 at 13:34 Answered 22/12, 2009 at 9:40

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 was used in their product. What can ScriptSharp bring to the table?

Overlive answered 25/4, 2009 at 13:34 Comment(0)

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.

Comatose answered 25/4, 2009 at 15:46 Comment(8)

Thanks - great level of detail. One follow up though - you say code size doubled, but were there areas that you have substituted a lighter jQuery implementation? – Overlive 25/4, 2009 at 16:7

No -- I haven't done any jQuery development since I started using this. I haven't abandoned jQuery -- I've just used Script# to satisfy the pent-up demand for features that jQuery wasn't sufficiently powerful or easy enough to use. I think jQuery's strengths here are its selectors -- very powerful stuff -- and it's "fluent" coding style. (en.wikipedia.org/wiki/Fluent_interface) – Comatose 27/4, 2009 at 15:0

Here's a blog entry that describes in detail the fact that you must put your ScriptSharp project in the Bin\Scripts directory of the web app or web project: thinkfarahead.com/2008/07/tip-script-and-scriptpath_13.html – Comatose 28/4, 2009 at 22:8

jQuery support is allegedly coming to Script# in late 2009. – Baleful 5/6, 2009 at 20:41

How do you know jQuery support is coming to Script# in late 2009? Nikhil's blog hasn't mentioned Script# since October of 2008. I'm wondering if he hasn't abandoned the project for .NET RIA services. – Comatose 26/6, 2009 at 17:11

Do you still stand by Script# now? I'm interested as your first post was after using it for 3 weeks, so you may (or may not have) run into some of the same problems we did. – Napoli 19/4, 2011 at 13:46

The project I used it for only lasted a few more weeks, but it served me very well on a tricky AJAX feature. I agree with most of your objections, but it is far from dead -- it was featured at MIX11 -- and it's on the verge of being open sourced. (See github.com/NikhilK/scriptsharp.) I feel that using it or not is sometimes a toss-up, in part because of the factors you mentioned. But the other day I used it on a project to whip out a small feature that in raw JavaScript (even with jQuery) would have taken me longer, I just know it. I sense that it might be better for larger projects. – Comatose 20/4, 2011 at 23:12

Regarding the C# 2 "flaw": he has now included support for consuming generics, but so far not declaring them. He says that lambdas and declaring generics are in the pipeline. – Comatose 21/4, 2011 at 4:40

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

Napoli answered 25/4, 2009 at 16:15 Comment(2)

Thanks - While I am a .Net at heart, I see more and more work being done with Javascript that MS is simply ignoring. The core strength of my team is .Net so we would like to build on that strength while we branch out in new directions. – Overlive 25/4, 2009 at 16:22

At his MIX11 talk (channel9.msdn.com/Events/MIX/MIX11/HTM16), Nikhil Kothari announced that he intends to open source the entire project after the V1 release. As of this writing (v0.7.4), some of it is already available at GitHub under the MSPL: github.com/nikhilk/scriptsharp – Gaal 20/11, 2011 at 4:23

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)}

Pammie answered 26/4, 2009 at 8:27 Comment(1)

Licensing is unclear, with implied terms for commercial use ... ? – Zackaryzacks 29/1, 2011 at 13:8

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.

Drogin answered 25/4, 2009 at 13:38 Comment(2)

I agree with your opinion concerning untyped code. When dealing with the DOM you don't have as many or the same type of concerns with type safety. We took note of ScriptSharp since Coveo had used it in their product. – Overlive 25/4, 2009 at 15:22

The biggest advantage I see with Script# is that you can use your refactoring tools such as Jetbrain's Resharper refactor and clean up huge projects, on regular C#. This is very difficult to do with raw JavaScript to my knowledge. – Whenas 12/8, 2011 at 19:10

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/

Mathur answered 22/12, 2009 at 9:40 Comment(0)

Recommended topics

Hot tags