Moved

The content of this blog is now at http://echo.nextapp.com. Comments have been disabled on Blogger due to spam (commenting is possible at echo.nextapp.com).

Comparing the Google Web Toolkit to Echo2

The Google Web Toolkit (GWT) is being compared to Echo2 quite frequently. Some of these comparisons have been fairly accurate, while others contain bits of misinformation. This article, written by the lead developer of Echo2, discusses the similarities and differences between these two frameworks.

Overview

The Google Web Toolkit and Echo2 definitely make for an interesting comparison. Both of these frameworks take a non-traditional approach toward web application development, even considering the latest crop of "AJAX-based frameworks" available today.

The most obvious similarity between GWT and Echo2 is that they both enable the developer to create dynamic, AJAX-driven web user interfaces using only Java. In both projects, UIs are developed in a fashion similar to SWT or Swing: by assembling hierarchies of components and registering event handlers. Neither project requires the developer to work with HTML, JavaScript, or XML.

The most obvious difference between GWT and Echo2 is that all of your GWT code is executed on the client, whereas your Echo2 code is executed on the server. There are advantages and disadvantages to both of these approaches, which will be highlighted throughout the article.

GWT's defining attribute is the Java-to-JavaScript compiler. This compiler allows you to develop the web interface to your application in Java, then compile it to JavaScript. GWT limits the developer to a subset of the Java 1.4 libraries. GWT applications can be served by any web server, such as Apache, without the need for server-side processing.

Echo2 applications are compiled to Java byte code and run on a Java server. Their Java code is executed by Echo2's "Web Application Container" layer, which sits atop a Java Servlet. On the web browser, the Echo2 "Client Engine" communicates user input to the Web Application Container via AJAX requests, with the server responding with directives to perform incremental updates to the state of the client web browser.

User Interface Performance

With GWT, all of your user interface code exists on the client browser. In operations that do not require server communication--that is, that do not require retrieving data from the middle tier--this configuration results in response times that are not dependent on the server. When data must be retrieved from the application's middle tier or business logic layer, the response time is subject to the same criteria as any other AJAX application, i.e., network latency, bandwidth, and server performance.

Echo2 application code is run on the server, so for each user interaction that requires a call to the middle tier or immediate execution of the application's Java code, an AJAX connection is made to the server. Echo2 components are designed to minimize the client/server communication as much as is possible, limiting it to times when the server must be notified immediately of events. For example, simple events such as user input to a TextField component will not result in server contact. The server's response is the minimum set of instructions to incrementally update the client to reflect the new screen state.

GWT applications are served to the client as a single HTML/JavaScript file, containing the entirety of the user interface. The size of this file will be proportional to the size of your user interface code and the toolkit libraries used by your application.

Echo2 JavaScript modules are lazy-loaded to the client, and thereafter cached. A module will be retrieved when a component first appears on-screen that requires it. Application code is never sent to the client, only the state of the user interface.

Middle Tier / Data Retrieval

To access business data or perform a business process, a GWT user interface makes a remote procedure call (RPC) from the browser to a Servlet. GWT provides a mechanism to make the RPC invocation transparent to the developer, allowing the developer to build the application with "Plain Old Java Objects" (POJOs). However, any application that provides an RPC capability is a distributed application -- even when the RPC is accomplished transparently to the developer. Distributed applications in businesses and enterprises usually have security considerations and the remote objects serving the GWT clients must be designed with a focus on security to deflect attacks from imitated or hostile client applications.

Echo2 applications support, but do not require, the use of distributed application logic or a Service Oriented Architecture (SOA). Alternatively, Echo2 applications can be built to run entirely within a single JVM instance, backed by a POJO-based middle tier. This allows Echo2 developers to build applications without the security concerns of distributed application logic -- and leverage the many strong frameworks built around POJO development such as the Spring Framework and Hibernate. Echo2 accomplishes this by keeping the state of a user's web interface on the server so that no remote objects need to be exposed.

Performance Under Load

The Google Web Toolkit is a thick-client UI technology (applications run on the client), whereas Echo2 is a thin-client UI technology (applications run on the server). A thick-client will inherently place less load on the server as the number of simultaneous users increases. This advantage of GWT is most pronounced in cases where applications are simple and data store access is limited, and less so with more complex applications that require more frequent inquiries to the data store. In a typical environment though, either framework will saturate available network bandwidth before server resource utilization, i.e. processing power and memory, becomes an issue.

Run-time Environment

GWT has some limitations due to the fact that applications are run on the client browser. First, GWT applications are limited to using a subset of the core Java class libraries, consisting of 27 classes, 11 interfaces, and 18 exception types found in the java.util and java.lang packages (as of GWT 1.0.21). This limitation prevents GWT applications from linking to most existing Java libraries. Additionally, all Java code must be compliant with the Java 1.4 specification; 1.5 is not supported. Localization-related portions of the Java API are not provided.

Debugging

GWT provides an alternate deployment environment for applications to facilitate debugging. The environment, called "Hosted Mode", allows a GWT application to be run as Java byte code in a local JVM, to which an IDE's debugger can be connected. In this mode, the application's user interface is displayed in a special web browser (a Mozilla/Firefox derivative).

Echo2 applications may be debugged in the conventional manner, by connecting an IDE's debugger to a JVM running a Servlet container.

Licensing

The primary component of GWT, the Java-to-JavaScript cross-compiler, is proprietary, binary-only software. The Java API libraries are open source software, distributed under the Apache License. The API libraries have essentially no value without the proprietary compiler. The (non-critical) hosted-mode browser is also under the proprietary license. GWT is provided free of charge.

Echo2 is open source software, licensed under the Mozilla Public License, and provided free of charge.

Applicability

GWT can be used as a means of creating AJAX components to embed in traditional web applications (or even in static web pages) as well as for creating complete application user interfaces. There are some issues to using it for the creation of large applications, where downloading an entire application to a client web browser in one shot would not be practical. The lack of localization and full Java API support also presents a problem for larger solutions.

Echo2 is practical for creating web applications of any size. It is however not intended to scale downward to function as a platform for simply creating AJAX components in traditional web frameworks (or static web sites).

More Information

Google Web Toolkit:
Home Page, Example Applications, Getting Started Guide, Developer Guide

Echo2:
Home Page, Example Applications, Tutorial

IE7 Beta 1

Well, I've finally had a brief opportunity to take a look at the latest browser from Microsoft: IE7 Beta 1. The good news is that it works just fine with Echo2, and that they've added support for rendering alpha channels in PNG images. Echo2 thus no longer needs to use IE's proprietary "image filter" capability to achieve this effect in IE7 as was required with IE6.

Echo2 sets 11 "quirk flags" if an Internet Explorer 6 browser is detected at startup, to enable alternate rendering to work with the limitations of this browser. With IE7b1, we've been able to reduce that number by only one, as a result of the PNG alpha channel support. I was hoping for a bit more. MS claims they've fixed a couple of the more egregious CSS bugs in 7beta1, e.g., the "peekaboo" and "guillotine" bugs. They also state that they'll be working on more CSS fixes for beta2. I've not noticed any benefit from the beta1 list of CSS fixes yet, though this may be due to the fact that Echo2's rendering code was in some cases built to entirely avoid these scenarios given that IE6 support is a design requirement.

The following is my current list of CSS/rendering bugs that in my humble opinion absolutely must be fixed in the next version of Internet Explorer:

• We still can't do proper CSS positioning using the top/bottom/left/right properties. With IE7, like IE6, you are limited to using either one horizontal positioning property (left/right) and one vertical positioning property (top/bottom). If you do not heed this limitation, IE will simply disregard the bottom or right property. In Echo2, we work around this limitation by using IE's proprietary CSS expression property when an Internet Explorer browser is detected.
  
• <SELECT> elements still wholly disregard z-index settings. This is explained by MSDN's "Dr. GUI" in this article which is a bit frustrating to read, as I believe that it is incorrect to characterize this behavior as anything but a bug. If you're unwilling to call it a bug, then it my book it's a design flaw. As a result of this issue, we still have to use the IFRAME-behind-a-DIV hack to successfully render content above SELECT elements in IE7.
  
• SELECT elements are still very broken when it comes to updating them by manipulating the DOM. We still have to "ban" 100%-wide select elements in MSIE, as they just plain don't work. We still have to use a wholly custom DHTML component in place of a "multiple line" SELECT element to render ListBoxes. (ListBoxes magically turn into SelectFields after DOM manipulations in IE6 and IE7).
  
• The repaint performance flaw mentioned in the previous article, More Fun with Browser Quirks is still in full effect.
  
• 100% wide TABLEs still produce horizontal scrollbars in DIVs whenever vertical scrollbars are present.
  
• Percentage-sized TEXTAREA elements still behave erratically (they sometimes adjust their size by a dozen or so pixels when text is entered).
• Document.importNode() is not provided. The workaround for this limitation is to write a complete implementation of Document.importNode in JavaScript which traverses an XML hierarchy and recreates the nodes in the new Document.
  

A Few Pointers

I wanted to pass along a few general pointers for those writing applications in Echo2 or porting Echo1 apps to the new platform:

• Externalize all Strings as though you were going to support multiple languages. I've found this to be an extremely beneficial practice, even when developing apps that are extremely unlikely to ever be translated. It keeps code cleaner, and enables one to quickly review (and even spell-check) all text that is used within an application.
• JavaDoc every class and method. Maintain the JavaDocs when you update the classes and methods. I believe this to be a worthwhile practice even if you will never actually generate JavaDocs based on the code, and even if you will always be the sole maintainer of a particular piece of code. I've also always found that in the event that I begin to have a difficult time explaining a particular method/class with JavaDoc documentation, then chances are that piece of code could use a good refactoring.
• Use StyleSheets wherever practical. They clean up your code and result in less memory being used on the application server. When you use StyleSheets, a single instance of the defined style properties is shared across ALL application instances on the server, which can result in a substantial reduction in memory usage. StyleSheets can also make it quite easy to change the theme of an application, and/or allow an application to have multiple user-selectable themes.
• Do not use the Grid Component unless you absolutely need to. The Row and Column components will render more quickly, and have substantially more capability to perform fine-grained client-server updates when cells are added and removed. Grids do not have this capability. Also, don't use the Grid Component to render tabular data; the Table component is designed specifically for this purpose.
• Don't perform unnecessary component add/remove operations. The Echo2 "UpdateManager" is watching your application for component hierarchy and property changes in order to determine the simplest course of action to update its state on the client web browser. If you remove and re-add a component, for example, the UpdateManager won't know that in fact nothing has changed, and the re-added component will thus be re-rendered on the client, consuming more bandwidth than necessary.

More Fun with Browser Quirks

First and foremost, I've been informed by a few folks now that blogs are in fact supposed to be updated from time to time. I had previously been of the impression that simply changing the page theme once a year might suffice, but I stand corrected, and will see if I can't manage to update it a bit more often. The lack of attention paid to the blog has not been entirely without cause....extra attention has been scarce these past months due to the sometimes frenzied pace at which Echo2 is being developed.

To follow up on the last entry, Opera 8.01 is in the wild and appears to correct some of 8.0's XMLHttpRequest-related shortcomings. Safari 2.0 is unfortunately still broken. Shortly after the last blog entry I reported a couple of the Safari bugs via bugreporter.appple.com; the more important of them being promptly marked as a "Duplicate" by an Apple staffer. Whether it has actually been resolved or not I cannot say, as their bug tracking system does not provide me access to such information.

I have found a means to workaround the Safari issue mentioned in the last entry, but the workaround only exposes another bug in Safari 2.0: XML attributes appear not to be (un)escaped properly, i.e., ampersands ("&") are returned as "&#38;". While this too can be worked around, at this point I'm willing to wait for Apple to release a fix rather than adding tons of browser-specific quirk code to workaround a set of bugs that will likely be fixed shortly... even if it means that I have to reply to a few more "Why doesn't it work in Safari?" posts in the next n public announcements.

While we're (STILL) on the subject of fun with web browser quirks, it might be an appropriate time to bring up a particular issue that I like to refer to as the "worst bug ever in Internet Explorer 6." I'm sure some may disagree that this item truly deserves that title, but it is most certainly in conetention for it. Anyway, here's the quirk: IE gets unresponsive when the DOM gets complex. More specifically, when a DOM gets linearly more complex, Internet Explorer will get exponentially less responsive. This is a seat-of-the-pants analysis, but when you see the behvaior for yourself, it's pretty darn obvious. The most easily observed example was that when using IE with an Echo2 app (prior to the workaround implementation), the performance of button rollover effects would degrade in proportion to the number of floating WindowPanes visible on the screen at any given time. If no WindowPanes were visible the "rollover performance" was instantaneous. With one WindowPane, the rollovers were a bit slower. With two there was noticable lag. With three or more the rollover effects would only fire if you stopped moving your mouse and waited with the cursor over a button.

This issue received perhaps 40 hours of time spent trying to isolate the issue and find a solution. In the course of this effort, I noticed that the CPU meter would peg if a complex DOM was being displayed and the mouse cursor was moved in circles anywhere within the IE browser window, even over white space to which no event listeners had been registered. It was also observed that no event listeners appeared to be invoked until such mouse movement ceased. And no DOM updates would be performed while the IE browser was seemingly hypnotized by this irrelevant mouse movement. The moment the mouse stopped, IE would resume executing JavaScript, firing events and updating the DOM as necessary.

At this point I'd managed to isolate the behavior but the solution was still nowhere to be found. When the DOM got complex, rollovers got terribly slow as a result. And dragging a WindowPane could be downright painful. But oddly enough, resizing a WindowPane was still fairly smooth, regardless of the complexity of the DOM. I found this to be extremely interesting, especially given that in cases where one resizes a WindowPane from its upper-left corner, the WindowPane JavaScript code is actually moving the window up/left and then resizing it such that the lower right corner appears to remain stationary--i.e., it's doing everything that a move operation does, and MORE. This observation gave way to the solution: it's not that IE isn't firing events or performing DOM updates when the DOM is complex, it is simply delaying the repainting of the screen in such cases. And as it turns out, changing the width CSS property of a DOM element triggers an immediate repaint operation.

In more recent versions of Echo, if you happen to roll your mouse over a button with a rollover effect, and you happen to be using IE, know that the button is being momentarily resized to be one pixel narrower and then put back to its original state. The effect is not visible, other than that rollover behavior is now smooth even when the UI gets extremely complex. This quirk workaround has also been applied elsewhere, such as to moving WindowPanes. The quirk is ONLY enabled when the client browser is determined to be Internet Explorer. If anyone is aware of other writeups on this IE performance impairment and/or a cleaner workaround, I'd be very interested in learning more.

That's all for now. Time to roll the beta2 release.

Opera, Konqueror, and Safari

A significant amount of time this week was spent on the addition of support for Konqueror (3.4) and Opera (8.0) browsers. I'm very excited about the idea of having more browsers supported. In addition to making the software available to a wider audience, they act as an additional check to make sure we're doing things right with regard to Web standards.

The major hang-up for supporting Opera8 turned out to be nothing more than Echo2 misreading Opera's user-agent tag. Opera8 uses a somewhat deceptive user-agent header by default, identifying itself partially as Internet Explorer. Echo2 was failing to notice the "Opera" part of the user-agent header, and was thus turning on all the "quirk flags" in Echo2 associated with Internet Explorer. This causes some significant changes in Echo's rendering behavior, such as rendering using IE's proprietary "CSS expressions" instead of using the conventional CSS2 "right" and "bottom" properties that are unsupported by IE... not a good thing for non-IE clients. A few other issues were run into...notably Opera's lack of support for the setRequestHeader() method in its XMLHttpRequest implementation.

The goal with Alpha9 was to also support Safari, which I was hopeful would be a given once we had Konqueror support in place, as Safari is a derivative of Konqueror. I picked up a Mac Mini this week from the Apple Store, largely for this purpose, and so far I've found Safari support to be frustrating to say the least. Echo2 appeared to work well in limited testing with Safari 1.3 (that which is included with OSX 10.3/Panther). Things took a sharp turn for the worse once I upgraded to Safari2 w/ OSX 10.4/Tiger though. After a bit of testing it seems that there may be a bug in Safari where the document.importNode() does not work as expected when importing HTML fragments from an XML dcoument received via XMLHttpRequest. Safari2 does not seem to import CSS style attributes or element ids from the HTML fragment (and we are setting the namespaces correctly). I've whipped up a simplified test case of this issue, but still need to find a way to get it in front of the Safari devs.

Note that all the above changes aren't quite out yet, though they are in the Echo2 Subversion repository. They will be out very soon, i.e., hopefully tonight, with alpha9.

And as a total aside...wow, is Mac OS X gorgeous! I'm finding myself being sucked toward it more and more from my usual Red Hat Linux / Fedora Core 3 workstation.

Hello

Welcome to the Echo2 blog. I'm getting a bit of a late start on this, 'this' being both blogging in general and blogging Echo2 development.

If you're unfamiliar with Echo2, well, it's a web application framework of sorts... a component-oriented/event-driven/don't-write-any-HTML API backed up by an AJAX-based rendering engine. The idea is to provide an API that looks like a user-interface toolkit so the end-developer doesn't have to concern him/herself with the general nonsense of web development. The AJAX piece on the back-end keeps the state of the browser in-sync with the server-side application by performing fine-grained manipulations to the browser's DOM. Every update to the client is the smallest modification possible, so there are no page refreshes, and thus the response time is very, very fast.

A slightly more thorough overview can be found in this article on TheServerSide. But the best explanation can probably be had from seeing the online demo/test application.

As of this writing, the ninth alpha release of Echo2 is on its way out the door. This release sees the introduction of Checkbox and RadioButton widgets and better support for a couple more browsers, notably Konqueror and Opera. At this point the only truly "critical" widgets that are missing are Tables, SelectFields, and ListBoxes...all of which are coming very soon. The core API has mostly taken shape, but there are a few significant design decisions that have yet to be made.

In any case, I'm very much looking forward to adding blog entires and hope to do so very soon.

Best regards
--Tod Liebeck