问题
We have determined it's too difficult for us to maintain the bulk of javascript we need to write full-scale "single page" javascript "applications". Relying on programming conventions still has left us wanting... especially in the area of refactoring. For developers new to these projects, they find it very difficult to change anything because they have no faith they know who else is truly relying on the component (things easy to do with "find all references..." and code access levels in strongly typed languages).
We've been playing with GWT, but one of our developers wants to use Script#. We are already a Microsoft-based shop, and do all of our server-side work in C#.
I don't consider java to be a show-stopper for GWT, as it's extremely similar to C#.
My initial concerns with Script# primarily revolve around support and documentation.
On one hand we have Google, on the other... "Some Dude". Script# is also closed-source... so if the developer stops working on it, are we S.O.L.? I also feel GWT has more documentation and community support.
Anyways, have you worked with both? Thoughts? Pros/Cons?
(To head this off at the pass: the question is not whether to go with a compiler or not... the question is which compiler)
Similar, but different, questions:
What advantages can ScriptSharp bring to my tool kit?
Should I use ScriptSharp
回答1:
I have been using GWT for several years. I have never heard of Script# so I will just tell you why you should stick with the Google solution.
Active development. Google has a paid team of engineers both actively fixing defects and working on new functionality. I am currently in discussions with some other developers on how to implement a new feature for GWT.
Large institution. Google has invested this project and used it to implement large-scale solutions. They're eating their own dogfood, in other words. They have a vested interest in not letting it stagnate or become obsolete.
Community. There are plenty of people working on add-ins/third-party/etc libraries and APIs to use alongside the vanilla distribution. These same people are also testing, filing, and fixing defects.
Compatibility. GWT can work with anything that the browser can do. There are also plugins for jQuery and other major JavaScript libraries that just make it plain easier to manage the complexity of your project when working with JavaScript.
Open. You touched on this yourself.
Notice how I didn't touch on issues of language choice. I don't think that's really relevant at the level you describe. Remember that the first time you run into a limitation or road block with Script# you'll become quickly stuck due to the things that both you and I described.
Of course, I recommend GWT just because of the track record.
回答2:
I use Script# and previously used GWT. They're really two different things. GWT is meant to provide a client and server solution, with RPCs and everything else. It is definitely more mature and you can get going on complex applications faster. Simply put, there's a lot more code and examples in the wild.
However, I think if you're developers are both server side and client side, using two different languages and two different platforms can be very, very burdensome. This is why I moved to Script#. Everything I do is in C# and in Visual Studio, it allows me to be a lot more productive. If you're not taking advantage of GWT's backend capabilities, it is really overkill.
I like to think of Script# as Javascript written in C# 2.0 spec (which it is). It is completely clientside and any sort of mapping has to be done by hand (though automapping can be used extensively). It is very complete in its support of Javascript and jQuery, in fact it is so complete this surprised me at first. It seemed like it was doing less than it was.
angryundead's points are valid, especially in regard to community and openness. While this has been a bit of a thorn in my side, I really, really like using Script#. I don't have to change IDEs, I don't have to look up how to do things in Java, etc. jQuery has a huge plugin library and it is very, very easy to hook these into Script#. You simply throw a few objects to represent the properties, annotate them as "imported" and have it returning null. In your code you cast an object as the plugin and your output is exactly as it would appear in Javascript. Script# doesn't care / know how the plugin works.
Don't let Script# lack of community support fool you. While it is a problem, the product is very mature and feature rich. If your developers are using C#/VS why make them use a separate program for the clientside? I found that was a huge productivity hit.
As an aside, I've become a lot better at Javascript since using C#. A lot of the problems with Javascript are the lack of language features that you don't really need but on large projects it is the only way to make it manageable.
回答3:
If you want to use C# for your JavaScript code, I'd suggest SharpKit. It has a feature comparison with other C# solutions. Also as an example of its application, you might want to check out CodeRun which is created using SharpKit.
回答4:
Unless you're building an full-on in-browser application, my preference is Script# because it sticks to what it does best -- compiling C# to JavaScript -- rather than trying to be a comprehensive client/server toolkit. Web paradigms change quickly, and investing the project in GWT can leave you with overhead or technology commitments you wish you didn't have. But I would add that it really depends on the type of web application or web experience that you are trying to build.
Personally, I'm already intimately familiar with jQuery, WCF, and am beginning to use new HTML5 capabilities directly. Script# is the perfect missing peice because I can continue to use jQuery and WCF very easily, and I don't need to go through the hassle of switching to or integrating with the paradigms or requirements of GWT.
Also, on the UI building side of things, you might consider Sharp UI that I recently open-sourced, which makes it easier to build reusable controls in a jQuery+Script# setting.
来源：https://stackoverflow.com/questions/3303853/gwt-vs-scriptsharp-pros-and-cons