As far as larger team/more resources on GWT – that is obviously completely true, and has large impact on depth of the framework. I too sometimes wish that script# was a larger project.

On the debugging front, I completely agree having the source-level debugging is a great plus, but I also think you need the ability to debug in the target runtime environment, i.e. that of a script engine in the target browser(s). I am not sure how much of GWT’s generated output is conducive to script debugging. Given I didn’t have resources to do the debugger part of the story, I spent a lot more focus on getting the generated debug flavor script to be debuggable, look and feel like hand-written script to match the original c# source.

There are a couple of things at which GWT is a little bit ahead of right now, being better supported, and developed by a bigger team, but I’m pretty sure that Script# can do everything GWT does.

It just lacks some of the ‘Controls’ that GWT has, and debugging in GWT is a little bit simpler because you can run the Java code directly instead of relying on the browser.

1. Script# does provide Visual Studio support – you use the C# editor, intellisense, and all the rest of the VS goodies when writing your c# code.

2. Script# provides a framework that lets you create and consume RPC/REST services… or you can work at a lower level using the raw XMLHTTP object as you see fit.