Google Web Toolkit

Writing web apps today is a tedious and error-prone process. Developers can spend 90% of their time working around browser quirks. In addition, building, reusing, and maintaining large JavaScript code bases and AJAX components can be difficult and fragile. Google Web Toolkit (GWT), especially when combined with the Google Plugin for Eclipse, eases this burden by allowing developers to quickly build and maintain complex yet highly performant JavaScript front-end applications in the Java programming language.

Using GWT, developers can rapidly develop and debug AJAX applications in the Java language using the Java development tools of their choice. When the application is deployed, the GWT cross-compiler translates the Java application to standalone JavaScript files that are optionally obfuscated and deeply optimized.

GWT does not revolve only around user interface programming; it is a general set of tools for building any sort of high-performance client-side JavaScript functionality. In live presentations, the developers of GWT emphasize that “GWT is not its libraries” and that it only includes a library but is not fundamentally yet another AJAX library. This open-ended philosophy sometimes surprises developers new to GWT who expect it to provide an end-to-end “on rails” application framework. Indeed, many key architectural decisions are left completely to the developer. The GWT mission statement clarifies the philosophical breakdown of GWT’s role versus the developer’s role. History is an example of such: although GWT manages history tokens as users click Back or Forward in the browser, it does not prescribe how to map history tokens to an application state.

GWT applications can be run in two modes:

Hosted mode: The application is run as Java bytecode within the Java Virtual Machine (JVM). This mode is typically used for development, supporting hot swapping of code and debugging.
Web mode: The application is run as pure JavaScript and HTML, compiled from the Java source. This mode is typically used for deployment.

The major GWT components include:

GWT Java-to-JavaScript Compiler
Translates the Java programming language to the JavaScript programming language.
GWT Hosted Web Browser
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 debug purpose.
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.

Comic : Eigth Stages of Programming

From, MY 25 PERCENT

Apache Wicket

Apache Wicket makes developing web-apps simple and enjoyable with proper mark-up/logic separation, a POJO data model, and a refreshing lack of XML. Wicket will not allow you to stop thinking about server state, it goes a long ways towards making it easy and often transparent to manage that state. In Wicket, all server side state is automatically managed. You will never directly use an HttpSession object or similar wrapper to store state. Instead, state is associated with components. Each server-side page component holds a nested hierarchy of stateful components, where each component’s model is, in the end, a POJO (Plain Old Java Object). Wicket maintains a map of these pages in each user’s session. One purpose of this page map (and the component hierarchy on each page) is to allow the framework to hide all details of how your components and models are accessed. You deal with simple, familiar Java objects and Wicket deals with things like URLs, session ids and GET/POST requests.

Wicket does not introduce any special syntax to HTML. Instead, it extends HTML in a standards-compliant way via a Wicket namespace that is fully compliant with the XHTML standard. This means that you can use Macromedia Dreamweaver, Microsoft Front Page, Word, Adobe Go Live, or any other existing HTML editor to work on your web pages and Wicket components. To accomplish this, Wicket consistently uses a single id attribute in the Wicket namespace (“wicket:id”) to mark HTML tags that should receive special treatment by the toolkit. If you prefer not to render Wicket namespaced tags and attributes to your end-users, Wicket has a simple setting to strip them all out, resulting in ordinary, standards-compliant HTML.

Wicket has been designed to work with POJO persistence frameworks such as JDO or Hibernate. This can make database driven web applications quite easy to write.

REF, The Apache Software Foundation
REF, Apache Wicket