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!

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#.

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.

Here’s a column model from the sample:

[code]
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(),

…

[/code]

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

[code]
for (i=0; i<3; i++){
new ColumnModelConfig() …
}
ColumnModel cm = new ColumnModel()
[/code]

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

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.

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