Google Web Toolkit and ASP.NET?
Now that Google’s Web Toolkit is out of beta, I’m looking at ways of integrating it somehow with C# and ASP.NET.
First of all, if you don’t know what Google Web Toolkit is, here’s a quickie: it is a framework for creating Web 2.0 AJAX Web Applications using the Java language, preferably inside an Integrated Development Environment (IDE) such as Eclipse. You then compile this from Java to HTML/JavaScript using the provided tools, and you have a desktop application-like web-page without knowing anything about the W3C DOM, HTML or JavaScript.
What does this have to do with C#?
Well, don’t get me wrong, the ASP.NET AJAX Toolkit is amazing, but being able to visually design a page and use JavaScript behaviors and AJAX from inside an IDE is a step forward.
It seems that Nikhil Kothari from Microsoft is working on a C# to JavaScript compiler, called Script#, as a side project of his. Unfortunately, Script# is not currently supported by Microsoft, and they are really losing ground on the AJAX field because of this. They should promote this to a corporate project, I would love having that same power that GWT has, but directly in the Visual Studio IDE.
Most would argue that AJAX.NET is enough, and they are right, it’s ok for most sites, but for a fully interactive Web application that doesn’t have to postback to the server for every single user interaction – it isn’t. Not if you don’t want to mess with JavaScript anyway.
Script# helps in this regard, but GWT is much more powerful, and writing a RPC web-service in C#/ASP.NET that Google Web Toolkit can use shouldn’t be too hard. I’ll post my findings on this topic in a future post.
Stay tuned!
Technorati Tags: Google, Google Web Toolkit, C#, ASP.NET, Script#
Bookmark on del.icio.us
on August 30th, 2007 at 3:17 am
Just to be clear on a couple of things:
1. Script# does provide Visual Studio support – you use the C# editor, intellisense, and all the rest of the VS goodies when writing your c# code.
2. Script# provides a framework that lets you create and consume RPC/REST services… or you can work at a lower level using the raw XMLHTTP object as you see fit.
on August 30th, 2007 at 5:16 am
Please don’t get me wrong, I’m very thankful for your work on Script#, and I’m sure a lot of people are. I’m just saying it would be great though if it got some real support from Microsoft in the future because I believe it has huge potential.
There are a couple of things at which GWT is a little bit ahead of right now, being better supported, and developed by a bigger team, but I’m pretty sure that Script# can do everything GWT does.
It just lacks some of the ‘Controls’ that GWT has, and debugging in GWT is a little bit simpler because you can run the Java code directly instead of relying on the browser.
on August 30th, 2007 at 4:20 pm
Andrei, sorry, didn’t mean to imply there was something wrong in your post.
As far as larger team/more resources on GWT – that is obviously completely true, and has large impact on depth of the framework. I too sometimes wish that script# was a larger project.
On the debugging front, I completely agree having the source-level debugging is a great plus, but I also think you need the ability to debug in the target runtime environment, i.e. that of a script engine in the target browser(s). I am not sure how much of GWT’s generated output is conducive to script debugging. Given I didn’t have resources to do the debugger part of the story, I spent a lot more focus on getting the generated debug flavor script to be debuggable, look and feel like hand-written script to match the original c# source.