As the lead architect of Thinwire, I’ve had a lot of people ask me to explain some of the differences between ThinWire and the Google Widget Toolkit (GWT), so I finally sat down and outlined some points that you should consider when drawing comparisons between the two. I think ThinWire offers many unique benefits, but in this article I’ll outline seven points that I think are most important. Keep in mind, this has been well researched, but as is always the case with comparisons, there may be some fine points that are not articulated properly. If this is the case, then please post a comment or send me an email.

  1. Full Java API Access – The Google Web Toolkit (GWT) takes the approach of compiling a Java application into JavaScript. This limits the number of Java features that a developer can use to the set of API’s that GWT currently supports. As it stands now, only two core packages are supported (java.util and java.lang). When you consider that the latest version of java has over 150 packages, two is a very small number and rather limiting. In contrast, a ThinWire application executes all program logic on the server and therefore gives the programmer direct access to anything the Java API or J2EE API’s offer. Additionally, since the GWT emulates the two packages of the GWT at compile time, there is nothing that would prevent a developer from accidentally using unsupported Java API’s, thus causing frustration.
  2. Linear Flow of Logic – With GWT, accessing anything that is outside the scope of the two supported Java packages (java.util and java.lang), requires the developer to implement a server-side service that performs a given task. Then, to actually utilize the service, the application code must use a rather complex async callback RPC mechanism that the GWT offers. While GWT tries to make this fairly simple, there is no mistaking the complexity added by this break up in logic. Further, Async programming is complex in itself and even GWT provides a page discussing this fact Getting Used To Asynchronous Calls. In contrast, since a ThinWire application executes all program logic on the server, the developer is never bothered by this issue. If they need to access something from Java Messaging Service (JMS) or call an XML parser, they just do it… no fuss. The ThinWire UI does use Async calling to update the screen, but it’s completely abstracted away from the programmer.
  3. Single Development Language – With GWT, the developer still routinely writes JavaScript client-side code and HTML as part of building an application. For instance, since the capabilities of the built in components are rather limited, you would have to extend a component using client-side code if you want pull off something outside of the scope provided. In contrast, ThinWire intentionally prohibits the developer from using client-side code or HTML in the development of an application. There are ways to get around this for super-rare cases, but as far as the developer is concerned, you develop in a single language throughout your application. This simplifies the application code and decreases the skill level necessary to build a powerful web application. Another side effect of a pure server-side model like ThinWire is that it supports having other programming languages such as Python, Ruby, Perl or any other language supporting a Java binding.
  4. Richer Set of Dynamic Component Widgets – If you look at the GWT “Kitchen Sink” example that demonstrates each GWT Component, you’ll quickly realize that GWT only provides a bare minimum of functionality for each of its components GWT Kitchen Sink Demo. Buttons don’t support images, text editors don’t have real-time edit masks, item lists and dropdowns don’t support multiple columns and have no sorting feature and no support for checkboxes, and the tree widget and menu widget and tab widget do not support images. The list really does go on, but suffice to say that ThinWire supports all of these features and more, plus all the components in the ThinWire framework support keyboard navigation.
  5. Full Scale Debugging – With the GWT, debugging is improved because you debug using an actual IDE and the GWT’s debug layer. This is a great step, but since much of an application’s functionality is built using async services, the debugging effort is more complex. This is further amplified by the hybrid programming approach that GWT condones where you use some HTML, some CSS and some client-side JavaScript. With any of those pieces, the debugging effort breaks down. In contrast, the unified programming model that ThinWire uses allows the developer to step through code using an IDE debugger in a very natural way. Application logic flows top down and there are no async services that may execute in other threads.
  6. Easiest Learning Curve – While GWT does simplify web application programming in some ways, it adds complexity in other ways such as via async services. ThinWire on the other hand is intentionally built to mimic the programming model used by tools like Visual Basic, Java Swing, Windows Forms & IBM SWT. Therefore, experienced client-server developers who have never built a web application, can easily transition to using ThinWire without having to learn any new concepts. Additionally, web programmers who have been fighting through the complexity that makes up modern web applications will welcome the simplicity and richness that ThinWire brings with its unified development model.
  7. Security – Many Ajax frameworks and techniques exasperate traditional web application security issues, and in some case, they introduce new issues. In the case of GWT, there are two main security issues. First, since your Java code is compiled into client-side code, you are basically exposing the inner workings of your application for all to see. Second, since the GWT uses async services to handle server-side processing, you are inadvertently exposing those services to malicious use; potentially without user-validation. Now, technically you could argue that these two issues are not new issues. However, the problem is that with most Ajax applications, you are creating a much larger number of these kinds of issues. Further, the technical expertise necessary to protect against such exploits is potentially high and therefore many applications will likely go unprotected. With ThinWire, all application logic executes on the server and is therefore hidden from end-users. Additionally, since there is no requirement to use services, none are exposed to end users. The only data sent to the client is that which must be displayed in the UI. No hidden values or application state is sent over the wire. Effectively, ThinWire apps are much more secure by default.

Like I said, that’s not the authoritative list of everything, but it touches on the most important parts. At some point, I’ll follow up with more details and describe other area’s where differences lie as well as include any feedback from the community.