Script# – Is Script# right for you?

I was playing a lit bit with Script# and I have some thoughts that I wanna share you. ( If you have no idea about what Script# is then you can read this post “Script#: C# to Javascript converter[^] “. ) I know that Script# is a great framework but it might not be right for all ASP.NET developers. The reason is that there are a few things which are not so convenience for me while I’m using Script#. But I don’t want to say that this framework is not for you. maybe, you might like it. In fact, I will give some facts that I’ve learnt about Script#. You decide whether Script# is right for you or not.

Contents

  1. Script#’s features
  2. Writing the object-oriented code with Script#
  3. Tools for generating the documentation and compressing the sourcecode
  4. What we meant by Script# as a C# to Javascript Converter is ~
  5. Script# as a new language
  6. Debugging problem in Script#
  7. Script# is not from Microsoft
  8. Script# is not Opensource
  9. Using the thirt-party Javascript library in Script#
  10. Script# for ASP.NET Ajax developers and Vista Gadget developers

1. Script#’s features

Script# supports the compile-time checking, intelliSense, class-viewer, reflection and etc. It helps you not to have any typo-errors (e.g. calling foo'() instead of foo(); foo(arg1, arg2) instead of foo(arg1); ) that the most of Javascript developers used to make. So, the benefit of using Script# is that it will improve your productivity.

intellisense.jpg
Fig: intelliSense

tooltip.jpg
Fig: Tooltip

Script# - Compile-time Validation
Fig: Compile-time validation

2. Writing the object-oriented code with Script#

Writing the object-oriented Javascript become so easy with Script#. As you know, writing the object-oriented code in Javascript and C# are quite different. If you are not so familiar with Javascript, you probably need to find the reference when you need to write the code with object-oriented concept. Now, it’s over. You can just write the object-oriented code in C# and Script# will convert this code to the object-oriented Javascript code.

3. Tools for generating the documentation and compressing the sourcecode

If you are using Script#, you won’t need any third-party tool (e.g. JSDoc, Javascript Compressor) for generating the documentation or compressing your javascript library. Script# already has the build-in feature for that purpose.

4. What we meant by Script# as a C# to Javascript Converter is ~

This is very important thing you need to understand before you start learning about Script#. As I said in my previous article, Script# is able to convert the C# code to Javascript. But it doesn’t mean that it can convert all C# code that you wrote in winform or webform. In order to convert the C# to Javascript via Script#, you have to write the Script#-specific code in C# then those codes will be converted to Javascript…

5. Script# as a new language

The syntax of Script# is not so similiar to the Javascript’s syntax. So, I feel like learning a new language to write the Javascript. Another problem is that it is so hard to find the equivalent syntax in Script#.

For example: How to access ‘document’ of created DOMElement??[^]

In Javascript,

var iframe = document.createElement("iframe");
var doc = iframe.contentWindow.document;

In Script#,

using System;
using System.DHTML;
using ScriptFX;
using ScriptFX.UI;

public class MyScriptlet {

public static void Main(ScriptletArguments arguments) {
DOMElement _iframe = Document.CreateElement("iframe");
DOMElementExt contentWindowElement = (DOMElementExt)_iframe.GetAttribute("contentWindow");
DOMElement doc = contentWindowElement.document;

}
}

[IgnoreNamespace]
[Imported]
public class DOMElementExt : DOMElement {

[IntrinsicProperty]
public DOMElement document {
get { return null; }
}

[IntrinsicProperty]
public DOMElement body {
get { return null; }
}

[IntrinsicProperty]
public DOMElement src {
get { return null; }
}

[IntrinsicProperty]
public DOMElement firstChild {
get { return null; }
}
}

If you look at both examples, you will understand how hard to find the equivalent syntax in Script#. It’s okay if we can find the equivalent one. But what if Script# doesn’t support something that can be done with Javascript?

6. Debugging problem in Script#

Script# does support the compile-time validation but the problem is that you won’t be able to debug the C# code that you wrote. Instead, you will have to debug the Javascript code that generate by Script#. I think that it is the big issue for web developer. I don’t feel comfortable to debug those generated code.

7. Script# is not from Microsoft

Script# is not developed by Microsoft while the GWT is developed by Google. It has too much differences. Even thought Nikhil is an architect from Microsoft, Script# is just one of his pet projects.. So, I don’t think that he is gonna support his pet project all the time.. And I’m not so sure that Nikhil will add more features to this project or not..

8. Script# is not Opensource

Script# is not an opensource project. Actually, it’s absolutely okay for me to use the non-opensource projects (I’ve been using the Visual Studio since long long ago.) but there should be a group of people who are supporting this project, right? What if we need the bug-fixed?

9. Using the thirt-party Javascript library in Script#

The most of Javascript libraries /framework (e.g. prototype, script.aculo.us, Yahoo.UI, ExtJS) are not written in Script#. So, you can’t use those libraries right away from your Script# code. I think you will have to create a wrapper class for those libraries in order to use them in your Script#-enabled projects.

10. Script# for ASP.NET Ajax developers and Vista Gadget developers

I think that Script# might be good for ASP.NET Ajax developers and Vista Gadget developers. As I’m not very familiar with those things, I’m not able to cover about this. I need your contributes for this fact.

Okay That’s all from my side. Feel free to let me know if you have any thought or comment. Thanks.