Script# Vs. Google GWT: May the Best Ajax Tool Win
 Darryl Taft
On the heels of Google's announcement of a Java-based development framework for Ajax, a Microsoft Web architect has unveiled a tool designed to provide C# developers with similar Ajax programming capabilities. Nikhil Kothari, an architect on Microsoft's Web platform and tools team, posted for download in late May a first prototype of Script#, his home-grown C# framework and tool for Ajax development. "Yep, I am finally publicly sharing a spare time project I've been working on the side in an off and on manner for some time now," blogged Kothari. Ajax is the name of a Web programming model, which translates roughly to "asynchronous JavaScript and XML." Adaptive Path, a Web design consultancy, coined the Ajax moniker. C# is Microsoft's object-oriented .Net programming language that many consider a head-to-head competitor with Sun Microsystems' Java. Google, for its part, unveiled a rival Java development framework and tool, known as the Google Web Toolkit (GWT) at the JavaOne conference in mid-May. Dion Almaer, an Ajax expert and co-founder of Ajaxian.com, said he believes Script# will go head-to-head against Google's GWT for developer mindshare. "I think that Script# is combating the same need: Developers on platform X want to stay using the language/tools that they like," Almaer said. "If X equals Java they will use GWT; if X equals C# they will use Script#" Microsoft's Kothari did not respond to a request by the time this article was published for additional information on how, when and whether Microsoft is interested in commercializing Script#. But Kothari did blog some details on his plans for his pet project. "Essentially the Script# compiler is a C# compiler that generates Javascript instead of IL (Intermediate Language). A key driving goal of the design is to produce readable Javascript that you may have authored yourself, and would be ok deploying into real apps," explained Kothari. Currently, Script# is not integrated with Atlas, Microsoft's Web client programming framework for Ajax, which is currently in beta test. Kothari told one poster that he "still need(s) to figure out the exact Atlas story and how these two (Atlas and Script#) unify over time. As and when that happens, I am sure I'll blog about it…. currently these two aren't integrated as you note. There is a fair amount of work to be done before I can really get to things like LINQ (Microsoft's Language Integrated Query Project), and some of the other things you mention. Other projects: time will tell." "Like Atlas, the idea behind Script# is oriented at providing an engineering approach and superior environment to developing applications using HTML/CSS and Javascript in a more productive, scalable and maintainable manner," Kothari blogged. Some posters asked Kothari whether he planned to make Script# available on Microsoft's recently unveiled CodePlex code-repository site and/or release the code under a Shared Source or open-source license. He did not provide a definitive answer. If Microsoft ends up bringing Script# in-house, it might opt to it as a Microsoft product – the way the company is planning to do with the IronPython programming language developed by Jim Hugunin. In 2004, Hugunin joined the Microsoft Common Language Runtime team, but he has continued to work on evolving the IronPython language from inside the Redmond software giant. The various IronPython beta builds are available under the Microsoft Shared Source license, and soon will be hosted on CodePlex. Script# is another in the growing family of C# spinoffs under development by Microsoft and third-party entities. Microsoft Research is working on several such variants, including F#, Spec# and Sing#. While many developers said they welcome tools like Script# and GWT with open arms, other programmers say they aren't so sure they will be the Ajax-development panaceas they are cracked up to be. Ajaxian's Almaer said tools such as GWT and Script# are sometimes just too good to be true. "I am not sure about the entire approach (Script#, GWT) and said so on," Almaer said. "I think that for a certain type of developer this approach can make sense, but it also scares me. It sounds great. Write code in C#, or Java, or ... and it all just works, right? We all know that isn't the case. A developer will try something and get: JavaScript error: line 2304. (However,) the developer isn't meant to know about the JS [JavaScript] piece. He can't debug it well as even if he goes to line 2304 it is gobbledygook that the framework spit out," Almaer said. Moreover, "You also feel like since you are in Java you can use any Java class right?" he said, "No. You are really on the web so you only have access to a subset of libraries." Dimitri Glazkov, in a comment posted on Kothari's Web site, agreed: "I gave it some more thought and I think the idea of Script# and GWT is abominable. It creates an abstraction layer where the developer doesn't need it. All this will do is create an opportunity for abuse. If you shield the developer from learning JS and knowing how it works, you will only get loads of insanely crappy code in return. It will work (some|most of the time), but it will cause countless hours, headache and induced hatred of technology of those who come behind." Next Page: Script# Vs. Google's GWT: May the Best Ajax Tool Win
"I can't see Microsoft investing a whole bunch in a different technology to let C# code run in client browsers," DiMichillie said. Plus, "the idea of translating C# to Javascript sounds like a real headache." Say a developer "writes some C#, converts it to Javascript and it doesn't work," DeMichillie said. "Now the poor guy is faced with trying to debug some machine generated code that uses a language that he didn't want to write in in the first place."
There's no question, however, that developers are interested in tools to limit JavaScript coding.
"Javascript code is a pain," said Coach Wei, chief technology officer at Nexaweb. "While trying to achieve the Ajax effect, we should avoid manual Javascript coding as much as possible." GWT and Script# are two examples of solutions that could minimize the amount of JavaScript coding developers need to perform, Wei said. "Another approach is Apache XAP [Extensible Ajax Platform] – a declarative way of writing Ajax applications," Wei added. "Developers author XML which is in turn rendered into Javascript and DHTML," he added.
Nexaweb donated XAP to Apache. Scott Dietzen, co-founder and chief technology officer at Zimbra, said he belives Script# would be "a good fit for those with existing C# investments" in terms of either applications or programmers. "But it is unclear how well you can realize the full richness of the Ajax model. I think it ought to be open source to have hope of getting traction." Alex Russell, president of the Dojo Foundation and project lead for the Dojo Toolkit, a popular Ajax development framework, echoed Dietzen's sentiments.
"It'll be interesting to see if or how these closed-source compilers are adopted by developers, especially in lieu of other tools," Russell said. "Like the Web itself, they'll succeed insofar as they reduce costs. The race is on to see what model can make developers more productive without running afoul of the web's constraints." Indeed, Russel said that with technologies such as Morfik, GWT, and now Script# "we have this weird 'compiling up' solution that treats the inherent complexity of developing applications in a browser as the largest stumbling block to application developer productivity, and I think that for some large subset of Web application developers that might be spot on."
However, the overall goal is not to hide the complexity entirely, "it's to provide an additive tool that helps improve the productivity advantages already inherent in the Web," Russell said. With that in mind, Script# might be a "better compromise than GWT since it seems to rely on markup for laying out components but preserves the advantages of toolability," Russell added.
"What I think the jury is still out on, however, is whether or not the abstraction will prove too leaky for large-scale (portable) development and whether or not imposing a compile/deploy cycle is too much of a burden on developers for the advantages that Script# might provide in terms of developer comfort." |
Create, Communicate, Collaborate with IT Professionals at Ziff Davis Enterprise IT Link.
Comments (4)
As far as debugging is concerned, GWT provides excellent support to debug the Java (which later becomes javascript) and support for unit testing. This should allow you to test your javascript code just as you would test your back-end server code.
I dont see why "JavaScript error: line 2304" should be hard to figure out.
Besides that, GWT provides a way to implement "component based" web page development. You can assign markups where to insert/not insert your javascript components (functional little apps).
This opens up a nice way to render a page.
Plus, your web-app can be incremental. You can create an app, and if you want to extend it, you just plug in some more pages (with extended app), and use that to replace old ones (with server side code)
I see a very huge potential for developing extremely good web apps. Although GWT is still in its childhood (or infancy?), as it matures, and hopefully browsers are allowed to execute javascript more efficiently, this will transform the way pages are developed
Posted by Dev | March 30, 2007 10:26 AM
I agree completely about the whole code generation thing being the wrong approach. I say we toss the whole compiled code notion out on it's ear. These silly compilers shield programmers from learning how things really work and leave them stranded when the compiler generates buggy code. I mean if you can't get in and figure out why the broken assembly code the compiler generated doesn't work then what good are you anyway?
Obviously everyone should work at the absolute lowest level possible at all times just to make sure the tools don't get in the way of progress. And while we are at it we should toss out all the stupid IDEs since they just shield the week minded from the complexities of building a project. Why not just ditch the GUI all together and go back to the CLI across the board just in case the GUI might break down at some point and strand us. Real programmers don't need compilers or IDEs or GUIs, they just see the code.
Posted by Richard Rowell | June 25, 2007 11:17 AM
It is not difficult to argue that "the whole code generation thing [is] the wrong approach".
Javascript has some very useful and powerful features, like open classes, and a Javascript's style of function closure. These features cannot be expressed natively in languages like Java and C#.
And why do we need an abstraction layer? Javascript is a relatively small language, and should be learnable by anyone who can learn Java or C#. Why put a pointless layer of code over the Javascript?
A few years ago one could have argued that the tools for developing in Javascript were non-existent, making it very difficult to build, and particularly debug javascript applications. That is no longer the case. There are several good quality Javascript debuggers, and there are some ok (getting better I am sure) Javascript editors with code assist, code coloring, syntax error hilighting, etc.
"Real" programmers are made more effective with quality IDEs and GUIs (aka dev-tools). "Real" programmers are also more effective when they can master the technologies required by the platform they are developing for.
Posted by Steven Barkdull | October 17, 2007 7:00 AM
If you're defied by AJAX and want to have better experience, then you may want to try AJAX Webshop because it features IDE and visualization and allows beginners to develop Rich Web applications quickly. Let's look at some of its features:
Based on standard component library it allows Ajax IDE in the pattern of rapid application development (RAD)
Integrated development and management tools are available. Easy-to-use visual Unified Modeling Language and visual IDE; complete component and object-oriented development pattern
Rich Web component library
Troubleshooting IntelliSense support, code editing support, project release and deployment support.
Java, PHP, C#, VB support
Compatible with IE, Firefox
Best Wishes,
Guys
Posted by Aleen | January 8, 2008 11:02 PM