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!
[tags]Google, Google Web Toolkit, C#, ASP.NET, Script#[/tags]
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.
on April 9th, 2009 at 10:36 am
I have used both (ASP.NET and GWT). I can tell you that Google has it dead on with GWT. There is no way in hell I want to see another line of Javascript and if I have to sell my soul to do that , I happily will.
It is time to move beyond this childish computer science mentality that one has to be able to understand the lower lifeform languages like JavaScript, C, and now more and more c++.
Nikhil, get busy, compete with GWT and produce a product that is a direct competitor and quit whining about your need to debug javascript.
on June 10th, 2009 at 11:02 am
Interesting topic. I have a .NET application and am rewriting the web interface to it. I had used ASP.NET web forms and 3rd party controls from Telerik. I found them to be powerful. However they are bulky, especially since they use AJAX.NET which requires a large javascript download. Not to mention that web forms are only ‘slightly compatible’ with MVC are not in the spirit of MVC and unit testing. So I started rewriting the web UI using jquery and ASP.NET MVC… Until I read about Google Web Toolkit. The concept of writing web UI in a higher level language like Java, that then compiles to Javascript is too hard to pass up. I have complex UI requirements and muddling with Javascript by hand, no matter how great the Javascript library is, is daunting. So my question is, can I use GWT to access my server side .NET library? I would think this is possible, but can anyone who has done this give some tips? I would still have to write my web UI in Java using one of their MVC frameworks, which will have a significant learning curve, but at least I won’t have to port my entire application code to Java.
on August 7th, 2009 at 4:29 pm
An elegant alternative to both GWT and Ajax.Net is Visual WebGUI by Gizmox.
(www.visualwebgui.com).
It handles all the client side update for you and allows .Net developers to develop web applications as if developing WinForm applications.
on November 11th, 2009 at 9:52 am
I think Asp.net MVC plus GWT on the client side will be a killer combination.
with MVC we can easily translate backend busniess logic into a REST api can be consumed by any client (and GWT). that is equally helpfull. Or we can simply follow the Ajax pros model and directly ganerate client side subs for our Controllers. which we can wrap in GWT helper classes.
I am doing that in my next project. GWT rocks.. feel sad for Script#.. i was really hoping it will standup to GWT.
On another note. visual web gui i dont like their approach. sending every event though wire seem little freaky to me.
Shamol