Wednesday 25 August 2010

Google Web ToolKit (GWT) - (Java => Javascript really worth?)

Google Web Toolkit (GWT) is an open source set of tools created by Google for web developers in order to allow them create and maintain rich and complex Javascript front-end applications in Java. It is licensed under the Apache Licence V 2.0.
In a J2EE Architecture, GWT emphasizes reusable, efficient solutions to recurring Ajax challenges, namely Asynchronous Remote Procedure Call, history management, bookmarking, internationalization and cross-browser portability.
The major GWT components include:
  • GWT Java-to-JavaScript Compiler
    • Translates the Java programming language to the JavaScript programming language.
  • GWT Emulation Library
    • Allows the developers to run and execute GWT applications in hosted mode (the app runs as Java in the JVM without compiling to JavaScript). It is commonly used for debugging.
  • JRE emulation library 
    • JavaScript implementations of the commonly used classes in the Java standard class library (such as most of the java.lang package classes and a subset of the java.util package classes)
  • GWT Web UI class library
    • A set of custom interfaces and classes for creating widgets.

Pros

  • Java solution to build web GUI and Ajax-enabled applications
    • This means you can use such features like debugging, refactoring, unit testing for your UI in the same way as you do this on the server-side.
    • In a typical web development or Ajax app, one has to know to code in HTML/DHTML, Javascript, JSP/ASP, JSTL etc. With GWT it is all Java. Developers do not need to know JavaScript technology, CSS, or DOM. The GWT Java-to-JavaScript technology compiler compiles the client-side Java code into JavaScript technology code and HTML.
    • Sharing the same language between the client and server (ability to use a shared Java package)
    • Deal only with POJOs – no JSON/XML/DOM stuff. Can leverage typical OO design patterns.
    • Can use complex Java on the client
      • Turned into JavaScript, but you still use String, array, Math class, ArrayList, HashMap, custom classes, etc.
    • Supports refactoring and promotes reusability
  • Communication between browser and Server well handled
    • Can send complex Java types to and from the server
    • Data gets serialized across network
  • Development environment support
    • Developed UI components can be unit tested and reused
      • One can write client and server side JUnit tests like any other java app.
    • Tooling
      • Integration with Eclipse and IntelliJ. One can develop a GWT app like developing any other java app.
      • Can test within Eclipse without installing a server
      • Using statically typed language (Java) to develop the client-side of the app allows to catch various problems even before the code is compiled (tools, IDEs, static analysis tools are available)
    • Provides GWT hosted mode, an environment that enables debugging.
      • You can run your Ajax-enabled application in hosted mode. This allows you to use your IDE's debugging facilities to test and debug the application.
      • hosted mode (you can make changes in Java on the fly and just hit "refresh" in the hosted mode browser)
      • Like any other java app, ide debugging into both client and server side code. No need for separate tools for different browsers ( IE vs Firefox )
      • Debugging tools like any other Java app (can set breakpoints and debug the app in hosted mode)
    • Full IDE-based Java support for development/debugging
  • Handles browser incompatibilities in processing Ajax.
    • The GWT Java-to-JavaScript technology compiler generates browser-compliant JavaScript technology code by DOM abstraction, saving developers from having to code for browser incompatibilities.
  • Performance
    • Code size (javascript footprint) is much smaller and execution speed is much better.
    • Time to deliver is much faster and fixing issues are much faster than typical jsp/javascript apps.
  • Open Source and Apache Licenced
    • Many free widgets, Support for many AJAX widgets.
  • Support by major company : Developed and supported by Google
    • Good documentation
    • Has good community support

Cons

  • GUI code is written in Java and GWT compiler generates javascript
    • Well, the advantage of writing GUI code in java has own disadvantages. For adding any small modifications in UI even, the whole cycle of writing in java and compilation has to be followed. The process is slower with increase of size of the application.
    • Usually the GUI developers are specialized – the java developers have to be accustomed to UI.
    • Generated JavaScript technology code has its drawbacks. Even though you don't need to know JavaScript technology to use GWT, you might sometimes need to examine the generated JavaScript technology code -- for example, if the browser displays a JavaScript technology error. For developers who are unfamiliar with JavaScript technology, understanding the JavaScript technology code that GWT generates can be difficult. Also because GWT generates the JavaScript technology code, you lose fine-grained control over the processing.
    • Just because one can write in java doesn't mean all java api's are supported. This is not a restriction of java – rather it is of javascript. Since GWT compiles the java code into javascript, only features that are supported in javascript can be implemented on the client side code in GWT.
    • Some syntax quirks around passing complex java objects between client and server. Like Collections have to defined in the javadoc
    • Since generated code is javascript/html, one needs knowledge of css/ html for setting styles to the rendered page elements – can be set in separate css file or can be set directly on the Element.
  • Learning curve of nonstandard approach and initial mindset shift
    • Fundamentally different strategy than all other Ajax environments makes evaluation and management buyoff harder
    • Most Ajax environments do JavaScript on the client and have a choice for the server. GWT is based entirely around Java.
    • You never put direct JavaScript in your HTML. Instead, you use JSNI to wrap JavaScript in Java. Very powerful in the long run, but hard to get used to at first.
    • Need to design presentation layer architecture very carefully. When building large complex web application with GWT you end up with a huge number of classes. To be able to maintain and extend application code you will have to use some architectural patterns for building GUI (like HMVC, PAC etc).
    • Concept of modules can be confusing.
    • Jumping between secure to unsecure modes can be quirky – ie have to move between web apps because of app context.
  • GWT compiler restrictions
    • Currently only Java 1.4 syntax and subset of Java core packages is supported (though this is going to change in GWT 1.5)
    • GWT compilation is rather slow comparing to standard Java compiler.
  • Development cycle (deploy, test, adjust, redeploy) time
    • When the code has been deployed to Google's 'hosted mode' browser, many code changes can be tested within a matter of seconds, by 'refreshing' the webapp. Think of it as automatic hot redeploy. Deploying the code to that browser currently takes around a minute, which wouldn't be a problem, if it weren't for the fact that not all code changes can be tested without a redeploy. A minute per development cycle is just too long, even if it affects only 10% of the cycles.
  • Cumbersome deployment
    • Clumsy and poorly documented process to deploy on a regular Java-based Web server.
  • Web indexing
    • Web indexing of Javascript is difficult, often developers need to create a HTML-only version of the app just to allow search engines to index it

References

No comments:

Post a Comment