Description
I love C#, every time I think of a project I try to write it on C#, even for Android or iOS, for that Xamarin has a solution. Here is where Script# comes in, I love writing my web application's client in C#, and I which I could always use Silverlight.
I have never been successful in making Script# accepted by web ("front-end") developers. And I have learnt not to fight them but to listen and try to blend in.
There is a new emerging technology for static programming Java Script with wide support, and the same web developers are more familiar with and willing to take: TypeScript.
If Script# could generate TypeScript, just as a flavor, a project template, then my assets written in Script# could be both in C# and TypeScript, and then my first choice would be to type in Script#, so maybe I (or someone else) would later extend it by writing some code directly in TypeScript using the classes I already defined in C#.
There is another scenario:
Since my code is an asset, I want my data contracts to be unique. I want the piece of code I define for the server to communicate with SilverLight using WPF, to be the same to what I use to communicate with the Java Script client, and there is where for me Script# brights, and it would not only export those clases for itself, but for TypeScript projects as well. Three or four flavors in one solution, everyone is happy. That is a good reason for me to implement DataContract and DataMember attributes.