views:

2265

answers:

6

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?

+2  A: 

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.

altCognito
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.
David Robbins
+9  A: 

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.

Jim Raden
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?
David Robbins
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. (http://en.wikipedia.org/wiki/Fluent_interface)
Jim Raden
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: http://www.thinkfarahead.com/2008/07/tip-script-and-scriptpath_13.html
Jim Raden
jQuery support is allegedly coming to Script# in late 2009.
Nosredna
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.
Jim Raden
+5  A: 

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...

mcintyre321
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.
David Robbins
+5  A: 

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:

zproxy
A: 

Recently I finished my own research on C# to Javascript translation. It seems that I've got a working transparent wrapper for jQuery in C#!

Here is a little presentation of my work: http://tr.im/DnaR (at Google docs)

amartynov
Dude! This looks great! You might be interested in jLinq, a Javascript implementation of Linq for JSON objects. http://www.hugoware.net/Projects/jLinq
David Robbins
I'm creating a post on my blog but what's your name? I'd like to send people over to your project.
David Robbins
David, it's pleasant to hear that you've been interested in my work. My info is available at my OpenID public page: http://amartynov.myopenid.com/ Thanks.
amartynov
A: 

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/

Jerry