Ajax
Should I Be Developing Ajax Applications using Google Web Toolkit(GWT)?
0So why should an Ajax developer be interested in the recently released Google Web Toolkit(GWT)? One possible reason could be to overcome the shortcomings of the typical Ajax web development model as noted in my earlier post. Firstly, a framework always provides a head start to a project, allowing the developers to worry only about writing the application logic; user interface elements, the plumbing work needed for the communication between the client and the server are provided by the framework itself. The more specific benefits of using the Google Web Toolkit are:
Refer to points 2 & 3 in my earlier post.
Developers can use a more modular and statically typed programming language in Java to create the interface and other components instead of hacking their way out with Javascript. Ultimately, its still the JavaScript code that is generated and served to the web browser, but GWT provides an abstraction layer that shields the developers from having to do much with the JavaScript language. The flip side of this is that for pure interface code, Javascript might offer a more natural solution than Java language when it comes to creating web pages; see the discussion below.Refer to point 1 in my earlier post.
Being able to use Java to create Ajax applications also means better integration with the rest of the Java web development technologies like JSP, JSF, etc(note that code written using GWT uses the Java Web UI class library which is not related to any of the Java standard libraries and this code is statically translated to Javascript and HTML code before making available to the server. Integration would be limited to sharing something like a Java component between a JSP page and the code written using GWT). This may not appeal to those who are using other server-side technologies like PHP and ASP.NET.
Java language also boasts of better programmer IDEs and tools with good support for Unit Testing and Refactoring. In fact, GWT itself has good JUnit integration through easy to use class libraries in the package com.google.gwt.junit.
Javascript code can still be embedded within the Java code if only the services of the Javascript language are going to solve a particular problem, by using the Javascript Native Interface(JSNI)(on the lines of JNI). See this for more information.
The biggest advantage of using GWT for creating Ajax applications is the relative ease with which the data can be communicated between the server and the client by just creating serializable Java objects. Good support for debugging. Eclipse IDE and GWT host mode form a good combination for convenient debugging of the GWT applications.Having said all this, I am not a big fan of static translation of one programming language to the other. If it were as unified as in ASP.NET(see ASP.NET WebParts; all the translation happens at run-time), I would have welcomed it whole-heartedly. But different programming languages are created to solve different problems, and they are optimized to that specific job. I hate Javascript language for many reasons(as I do in case of Java) but still believe that Javascript is better oriented towards creating client-side code for the web browsers than Java language is(when the intention is to create a web interface). Are we going to use Java idioms here or are we going to try to imitate the Javascript idioms in the Java code? How many Java libraries are supported by the GWT SDK tools? What about the unsupported libraries whose functionality is needed for the application?
Secondly, the entire translation process is lengthy and inefficient: create an empty GWT application using the GWT SDK, fire up your favourite Java editor(eg: Eclipse) and create the Java source files in it, translate these Java files to Javascript + HTML files and finally integrate them with the rest of the server-side code(PHP, JSP etc). But there are advantages we get out of this investment as noted in the above mentioned points.
Not all the standard Java libraries are supported by GWT. For example, only java.lang and a part of java.util are supported by the GWT tools, which means the code written using Java libraries not supported by GWT cannot be translated by the GWT tools. The developer needs to make a call whether to achieve the desired functionality by writing custom Java code or by writing the code in Javascript.(I would be tempted to go the second way as that would allow me to use the same code in other applications that don’t make use of GWT).
By the way, why don’t we have the access to the GWT source code? Isn’t Google a big supporter of the Free Software community?
For developer centric GWT related discussion, go to the GWT Support Forums.
Related Post: A Case Against Ajax Web Development Model
A Case Against Ajax Web Development Model
2Ajax is the hottest buzzword today on the web development scene. Everyone is trying to port their existing websites to now make use of the Ajax technologies or just including the name ‘Ajax’ somewhere on the website to claim that they too are in the loop too. I am not totally impressed by the Ajax technologies though.
My primary reservations are with the complete diversion of the path that web development is currently taking towards the Ajax based development style. I have the following concerns:
No bookmarking should be needed in either of these cases. The same is not the case with the Ajax based websites.
It breaks the ‘Back’ button of the web browser. Once again, this is not a new restriction; many websites break at many places if the ‘Back’ button of the browser is used, but the problem is compounded to the extreme level when using Ajax. I can’t right click on a link to open the target page in a new window. This point may look silly but this in fact is my biggest irritation when using the otherwise excellent Google Mail interface. Web developers need to be taught to learn new interface design guidelines. With the liberty of being able to create and destroy any part of a web page dynamically, a bad design can easily leave the user clueless and confused if enough indications are not left regarding what each part of the page tries to accomplish(Flickr demonstrates an example of a good interface). Easy to navigate interfaces are critical for any kind of applications, but the issue gains more importance with Ajax based interfaces.Its not that I see only drawbacks of using the Ajax technology – with so many great application interfaces being created using this technology every day and so many Ajax applications gaining such widespread adoption, it cannot be without its virtues. It allows some cool effects to be achieved(game website) without having to invest a lot of effort in it – just a basic knowledge of HTML, DOM and Javascript(a skill set that every web developer should be comfortable with) is sufficient. Ajax is not just coolness though; it also helps in creating better interfaces than possible with the traditional web development model, for similar kind of functionality; improves response times giving a more interactive feel to the users; it saves bandwidth, saving time and money in turn.
So when would I use Ajax and when would I prefer to stick to the traditional web development style? For simple web tools(eg: a file uploader/manager, a simple online game, a calculator etc), I would go all the way to use the Ajax technology as it would enable the user to experience the same convenience as that of a desktop application. For complex/moderately complex applications, it should be a tough call based upon the following question: what is most critical for the application, the interface and responsiveness, or the development and the maintenance of the application? Let us admit the simple fact that its not a much pleasurable activity to implement feature after feature using heaps of Javascript code, then writing just enough php code to merely pull the data from the database to return it to the client in some obscure data structuring format.
I would still use Ajax based techniques to pepper up certain parts of the interface though, if I feel like none of the above mentioned disadvantages weigh heavily over the gains that the application can make with them. For example, I wouldn’t use Ajax technologies heavily if I were creating a website like Amazon, though I would still use Ajax to pop up the balloons whenever a user holds the mouse over a product, providing the user with fresh and useful information about it(how many in stock, latest discounts etc).
All the Ajax frameworks that are propping up on the Internet in recent times should help the web developers escape from having to write large amounts of Javascript code, test them, debug them and also from having to maintain them. Such frameworks also use the best practices, thus removing the scope of many design errors that the web developers might commit if they write the Javascript code manually. The Ajax framework that Google has released recently is definitely worth trying out, and I will try to write about it in a future post.
Recent Comments