GWT vs. ScriptSharp Pros and Cons [closed]

Question

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

Answer 1

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.