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
- Script#’s features
- Writing the object-oriented code with Script#
- Tools for generating the documentation and compressing the sourcecode
- What we meant by Script# as a C# to Javascript Converter is ~
- Script# as a new language
- Debugging problem in Script#
- Script# is not from Microsoft
- Script# is not Opensource
- Using the thirt-party Javascript library in Script#
- 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.
Fig: intelliSense
Fig: Tooltip
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.
I like “Soloar System”. What is your favorite theme?
