可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效，请关闭广告屏蔽插件后再试):

问题:

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?

回答1:

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.

回答2:

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

回答3:

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

FlashPlasma http://jsc.sourceforge.net/examples/web/FlashPlasma/assets/FlashPlasma/Preview.png

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