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.

8 thoughts on “Script# – Is Script# right for you?

  1. Thank you, Mike..

    I think that Script# will be so popular if there are a lot of Script#-enabled libraries…

    btw, the sidebar of your blog doesn’t look good in IE6 1024×768 resolution

  2. I just wanted to add a couple of clarifications:

    4. Script# as a C# to Javascript Converter
    Script# pretty much converts most of c#… and c# is c# … its not something special. There are a few things not supported for a variety of reasons: to reduce complexity, to reduce likelihood of generating non-performant script, or some things that don’t make sense in the script world.

    5. Script# as a new language
    I think your example is a bit mis-leading. Yes, the DOM metadata is incomplete – you can go and write the metadata type, and use that over and over again… or you can file a bug to get some missing metadata added (since the DOM is so big, not all of it has been done – but will be done as needed, so as to cover what is really in use). Secondly, if its a one off, you can simply use late-bound methods on Type, rather than defining the metadata first. Regardless, of which approach you go, its not a new language, and the generated result is what you’d expect – nothing more.

    6. Debugging problem in Script#
    This is a problem and not a problem at the same time. Agree it would be nice to be able to debug the c# code itself. However, a lot of effort has gone into making the generated code look like the originating source code, so you can in fact debug. One always needs to be able to debug in the target environment, so its good that the generated code facilitates that.

    9. Using the thirt-party Javascript library in Script#
    Ext# already exists. Its on google’s code projects site. What you need to create is a metadata class (which has no runtime overhead) rather than a wrapper class.

  3. I would like to see script# used in a commerical application. I would like to use script# but can’t see how. Why? I can’t see how to bind to data flexibly. For example, I have a editorDataGird and my columns are data driven. That is, my columns are dynamic and so I need to rerender them per session or even within sessions.

    Here’s a column model from the sample:

               ColumnModel cm = new ColumnModel(new object[] {
                    new ColumnModelConfig()
                        .id("common")
                        .header("Common Name")
                        .dataIndex("common")
                        .width(220)
                        .editor(new TextField(new TextFieldConfig().allowBlank(false).ToDictionary()))
                        .ToDictionary(),
                    new ColumnModelConfig()
                        .header("Light")
                        .dataIndex("light")
                        .width(130)
                        .editor(new ComboBox(new ComboBoxConfig()
                            .typeAhead(true)
                            .triggerAction("all")
                            .transform("light")
                            .lazyRender(true)
                            .listClass("x-combo-list-small")
                            .ToDictionary()
                        ))
                        .ToDictionary(),
    
    ...
    
    

    You can’t created an iterator in the say with this psuedo code:

               for (i=0; i<3; i++){
                new ColumnModelConfig() ...
               }
               ColumnModel cm = new ColumnModel()
    

    because the for() loop is rendered into the javascript code

  4. Hi Nikhil,

    Thanks a lot for your comments…

    Ext# already exists.

    Thanks. I will check it out. it’s really goood news..

    I think there are a number of bugs in the script# too.. For example, it keep on removing “}” from my script all the time.

  5. I would like to see script# used in a commerical application.

    there are the list of some early projects in Nikhil’s website.

    for (i=0; i<3; i++){
    new ColumnModelConfig() …
    }

    you are just for-looping, isn’t it? doesn’t use for-each.. As the script# is in early stage, there might be some issues or uncompleted things.. If you have some questions, I think the best would be asking in Nikhil’s forum… He is the one who developed the Script#.

  6. I just saw Nikhil’s comments above. Wrapper vs Metadata class. This is interesting because I would tend to prefer the wrapper class but do wonder about the runtime overheads. In fact, I have written wrapper classes (with unit tests) to the extjs library and found this a straighforward approach. This is an approach used in frameworks such as ruby on rails.

    With the developers I have on my projects Nikhils script# is impressive, comprehensive. But at the same time it locks me in and out – I’m locked into script# and I’m locked out of javascript/extjs because the of the very fact that the developers don’t need to engage with extjs/javascript. What a bind!

    Why I would tend to not to go with script# is that its metaclass approach is a framework that sets up its own lifecycle (by design). Because to extend it means working on the C# code. I have spend a lot of time understanding Nikhil’s libraries through .Net Reflector. It’s clean, understandable and complex. There’s a lot to break too. Why not then stay in the simplier wrapper classes? They must be cheaper over its lifetime?

    I think this is where the rails crew have got web applications right. Stay simple and let yourself build out into the complex. This is why we need extjs in the first place with asp.net. The asp.net page lifecycle is too complex. Extjs gives us simplicity allowing a REST-ful-esque application: I can have html containers (aspx), js configuration of say editors and json data streams and treat all of them as resources (bring on ASP MVC). Yet, script# potentially brings it back.

    If you are going down the wrapper track. Go take a look at script#’s extjs library parser – you’ll save yourself time. I was going to load extjs into the DOM and parse it, but now I don’t need to!

    I started off looking at script# because I wanted to avoid writing lots of unit tests for my wrapper classes and because I liked the intelli-sense of it all. I think that I can get the intelli-sense with wrapper classes by autogenerating the code using Nikhil’s template. I suspect I’ll be back to script# because there are lessons in that code that I don’t even know I need to learn.

    But personally, I want developers to write javascript and know intimately how to construct, deconstruct and debug it. I want them to stop making silly mistakes (eg commas working in Mozilla but not IE). But foremostly, they need to be in control at all times. So, what script# doesn’t do is scaffold. Scaffolding let’s you get started and then build out complexity and difference. And then take over and refine. Script# does it all. But in that, we know that it will never do what it was never anticipated to do. ASP.NET taught me that. I look forward to script# having a wrapper mode!

Leave a Reply

Your email address will not be published. Required fields are marked *