Taking a look at Nikhil's Script#

May 24, 2006 @ 3:07 am

I've been playing around tonight with Nikhil Korthari's new Script# language plug in and I think for the first time am seeing the light at the end of the tunnel here. What this tool does is take compiled C# code using specialized .NET libraries that describe the capabilities available and crank out browser independent JavaScript code in the form of a class.

It's a shame that this so closely follows Google's release of their Google Ajax Toolkit which takes a similar approach of using Java code to generate JavaScript and will invariably have some people screaming – rip off. Still I think this is a cool idea that provides some really interesting possibilities especially in light of ATLAS for the future.

Nikhil's stuff is pretty raw at this point and it doesn't have a lot of functionality (and some odd behaviors like renaming your members to enforce JavaScript naming conventions?), but I played around with a few basic scenarios that deal with making some remote XmlHttp calls and retrieving validation data and returning the results back. It works beautifully and it's quick and easy to write code. You get Intellisense on the C# code you generate and the compiler does compile time type checking to verify typesafety and other syntactical errors. The compiler generates an assembly and a .JS file, but the actual JavaScript is loaded at runtime through assembly resources. A server control library provides the support services that makes the generated JavaScript type(s) available to your page and handles loading the script resources both for your generated code and the core library which looks at the moment to be a small subset of the ATLAS runtime.

Now before you get too excited – no, you don't get the idea that the CLR is running on the client. So no, you can't start running Windows Forms like code in the browser. Instead this mechanism basically maps JavaScript and DOM functionality to a couple of .NET assemblies that provide the core logic you can code against it with C#. It's a very limited subset of C# no doubt, but it's C# and provides Intellisense and compile time error checking. The compiler turns the code into .NET IL code and part of the compile process then parses that IL code into JavaScript.

Right now there's not a lot there – a couple of basic controls (TextBox, Label, Button) and an XmlHttp object so you can make easy AJAX callbacks. What's also there is the ATLAS like extender functionality, where you assign a standard DOM control to a 'framework' control that provides the core functionality. If you want to find out more check out Nikhil's Post that shows both the C# and generated JavaScript and walks you through the mechanics of the process. It's straight forward. I was able to get everything up and running with my own class in a few minutes...

What does it mean?

I'm still mulling around the implications of this in mind, but I think I see where this is heading and I like where it might be going (if I'm right). It looks to me like this sort of script implementation provides a powerful abstraction layer that is needed somewhere in the Microsoft ATLAS stack anyway.

To date this abstraction layer has been XmlScript which is embedded on the client side. If you've been following some of my thoughts on ATLAS a while back you probably know that I was rather put off by the XmlScript syntax which is unintuitive and to 'scattered' where too many choices need to be made in different seemingly unrelated places. Xml and markup are just bad choices for describing behavior in my opinion at least in human usable form (a designer or generator might help but that's not happening now).

Well, let's back up and think about an abstraction layer built using this script engine using this sort of Script# or similar technology! You can now write your code using compiled C# that runs against runs against specialized libraries – in this case the ATLAS client and Server libraries. The libaries now become the abstraction layer that can parse the syntax the actual user sees into what the underlying JavaScript code or libraries require – namely the fairly complex AJAX client side BCL wanna be implementation <g>.

All components consist of some client library code (just like we have now with all the Atlas Component implementations) and .NET assembly implementations of those same components to provide the mappings for compilation. The .NET code is basically a façade for the JavaScript libraries.

I think THAT right there is something that has tremendous value. With something like this it becomes possible to build a fairly complex library and expose it through the much more accessible interface of a .NET library with full Intellisense support and compilation safety and still have good usability of it out of the box, which seems to be the biggest problem we face with ATLAS at the moment. It also will let ATLAS get away with working without extensive new tool support – these components don't require a full new designer etc. merely some add-in components for Visual Studio. It seems like a big win situation.

It'll be interesting to see where Microsoft takes this if anywhere. Right now it's Nikhil's pet project. Nikhil seems to be a one man show over at Microsoft to crank out tools that rock the MS boat. Cheers to you Nikhil, keep it coming!

Feedback for this Weblog Entry

re: Taking a look at Nikhil's Script#
by AsbjornM May 24, 2006 @ 6:35 am

The things GWT and Script# does looks promising, but it gives you an strange way of doing things..
Yes, it helps you write javascript, but I'm not shure if this is the correct way.

ComponentArt has made an interresting thing when it comes to this, you can add an attribute to an method in an webpage,when this webpage is rendered javascript proxy's are generated, so you can call serverside methods just as if they was javascript on the client.
It works very well if you look away from the shortcommings.. like.. you can't send objects/classes, arrays etc, only simple types..

re: Taking a look at Nikhil's Script#
by DuncS May 24, 2006 @ 6:49 am

I think he's actually parsing the source code, not the resulting IL...

re: Taking a look at Nikhil's Script#
by DuncanS May 24, 2006 @ 6:51 am

... no you're right - he's processing the IL...

re: Taking a look at Nikhil's Script#
by DuncanS May 24, 2006 @ 6:55 am

.. actually no - I was right the 1st time :-) "...Hence the translation works at the C# level, as opposed to converting from IL to script, and the converter doesn't add any levels of abstraction itself."

re: Taking a look at Nikhil's Script#
by Canerli May 24, 2006 @ 8:15 am

I agree with you, the stuff is raw and needs time to become useful.

re: Taking a look at Nikhil's Script#
by Rick Strahl May 24, 2006 @ 1:00 pm

Asbjorn,

The Page Callback menchanism you describe in ComponentArt is part of ATLAS and a number of other tools like Anthem as well. That addresses one part of process which is the AJAX callback and executing server side code to retrieve data.

This addresses the potential of dealing with the actual code that is needed on the client to update the page. Some layer of abstraction is needed here to deal with the mess that is the cross browser DOM and acts as a front end to the ATLAS client libraries.

re: Taking a look at Nikhil's Script#
by Rick Strahl May 24, 2006 @ 1:04 pm

Duncan, I didn't check real close at what goes on behind the scenes. I assumed it was the IL code and I thought I read that in Nikhil's post. In the end it doesn't matter much how this is accomplished as long as the concept works fairly reliably.

The key to the success of this mechanism is how well it holds up in a complex scenarios and how well you can map certain concepts like say array management and RegEx expressions in C# so that it can translate to JavaScript. It bears some playing with and currently the tool is too limited to really see the whole picture.

It seems a little odd that C# was chosen over JScript.NET which would at least support similar language semantics. I suspect it's the lack of integration in VS...

re: Taking a look at Nikhil's Script#
by Nikhil Kothari May 24, 2006 @ 3:59 pm

Great to hear your thoughts, Rick. Thanks for the favorable review ;-)

Agree its still early... and needs a lot of work.

Let me confirm on the inner workings - this is a source to source translation. The regular assembly is also a useful by-product of the compilation. There is also a thought around using generated scripts without packaging as web resources. I am writing a doc I'll publish that should clarify this.

I chose C# because a) IDE support, and b) it was the language of choice, i.e. what I wanted to be able to code in. If I was more familiar with jscript.net, and used it much more, that would have been picked; in fact if I was in that position, others would be likely be there too, and there probably would be good tools support. Sort of a chicken and egg problem in some ways.

re: Taking a look at Nikhil's Script#
by csharpProgrammer May 25, 2006 @ 2:04 am

Agreed, it could still be early days but Nikhil has come out with something innovative which could go a long way in providing better interoperatibility. I would say his efforts are full of promise and should be backed by the community.

re: Taking a look at Nikhil's Script#
by Bill Rapoza June 01, 2006 @ 5:28 pm

I like what I've seen so far. I haven't had a chance to put it through its paces, but will do so shortly.

I've been thinking for a while that this is the "correct" approach for doing AJAX-style programming; that is, think of Javascript as the "machine language of the browser". This style of programming allows a "higher level" of thinking about the application but still getting the "benefit" of the "lower level" code implementation (Javascript, in this case).

re: Taking a look at Nikhil's Script#
by Bertrand Le Roy June 01, 2006 @ 5:55 pm

About the "rip-off" remark: that would be a very ridiculous thing to say... Even Nikhil can't code that fast ;)
And if anyone ripped anybody off, it must be Google: XAMLON was generating DHTML from .NET IL in exactly the same way Google is doing with Java at least back in September at the PDC.

DotNetSlackers: Taking a look at Nikhil's Script#
by DotNetSlackers Latest ASP.NET News October 26, 2006 @ 7:40 am