Skip to content

Why GWT? Part II: The right tools for the job

by on November 3, 2010

Last time I talked about moving beyond the page metaphor to create truly dynamic and interactive web applications. Today I’ll talk about why I think GWT is a good means to this end.

When I talk to people about Accevia or my other projects, they often ask why I decided to use GWT instead of common frameworks like Django or Ruby on Rails. I’m a big fan of both, but I don’t actually see them as direct competitors to GWT. Both are designed around the page metaphor and are excellent tools for creating sites that can be structured in this way. But they just aren’t the right tool for dynamic web applications. Let’s take a look at why this is.

Imagine creating an application like Google Calendar in Rails. Rails makes heavy use of the Model-View-Controller pattern, so we need to break our application into different views. Obviously we can make a view for the main calendar page, and probably a separate view for creating a new event. Maybe we can make one for the settings page also. These three views cover pretty much everything, now it’s just a matter of implementing them.

Well, first we need to draw a bunch of rectangles on the screen. That’s probably best done with JavaScript. We want to be able to click between different months on the calendar without reloading the page, so that’s going to be some more JavaScript. We want to be able to turn different calendars on and off to change which rectangles are gone and show and hide the task list, which we’ll do with JavaScript. We want to save new events to the calendar and task list as the user types them without submitting a form, so we’d best send a request to the server using JavaScript. JavaScript, JavaScript, JavaScript. Wait, weren’t we doing this project in Rails?

The problem is that once we’ve laid out our pages in Rails (or Django), the framework can’t do much more for us. This is fine for a lot of web sites where the interaction is defined by clicking through a bunch of pages, but it’s not enough for an application like Google Calendar. All of the interesting stuff happens within a single page, so we end up just having to write a ton of JavaScript and stick it in that page. Rails hasn’t really done anything for us at all.

So why not just write then entire application in JavaScript? That’s definitely an option. But again, JavaScript wasn’t really designed for writing complex web applications. As its name implies, it was originally conceived as a scripting language for doing simple manipulations on web pages. No one expected that people would end up writing tens or hundreds of thousands of lines of JavaScript to drive a single web application, and the language’s design reflects this bias towards small programs. For example, dynamic typing makes it difficult to maintain large programs, and developers typically try to warp JavaScript’s arcane prototype-based object model to resemble a more traditional class-based language. Libraries like jQuery and Closure do a great job of making web applications more palatable in JavaScript, but they can’t solve the fundamental problem.

Enter GWT. GWT is a set of tools and libraries for writing web applications in Java: it compiles your code down to JavaScript, so the user’s experience is the same as if you’d written the entire application in JavaScript. But as the programmer, you have all of the benefits (and pitfalls) of writing in Java. Rather than thinking about pages and the DOM, you can lay out your application using Swing-like panels. Static typing means that you’re safe from a huge class of errors that might otherwise be difficult to track down. And you have access to Java’s very mature set of tools including Eclipse, Guice, jUnit, and FindBugs.

By integrating with Java Servlets, GWT also allows for complete consistency in your application’s implementation. As previously stated, it’s misleading to say that an application is written in Ruby: what you actually end up with is an amalgamation of Ruby on the server, JavaScript for complex client-side interaction, HTML for basic page layout, and CSS for styling. Using GWT, it’s entirely possible to create a web application completely in Java. The distinction between the client and the server blurs, and developers have a much easier time understanding the entire system rather than having to declare themselves as “front-end developers” or “back-end developers”.

GWT and Java may not be perfect, but they solve all of the problems laid out above and allow for a fundamentally different way of thinking about and designing web applications. The real benefit of GWT is that it allows you to think of web applications in the same way as desktop applications, rather than unnaturally as a series of pages. JavaScript also solves these problems, but it is lacking as a language. I think it’s time we stop thinking of JavaScript as a language for the everyday web programmer and start viewing it as the “assembly language of the web.” By compiling other languages to JavaScript, we can increase the choice available to developers and decrease the difficulty of writing web applications. GWT is perhaps the first implementation of this approach, and I hope there are more to follow!

Advertisements
2 Comments
  1. It would be good to also know the pitfalls (if any) of using GWT on the server side integration – i.e. how easy or difficult would it be to integrate with non java frameworks

  2. Erik Kuefler permalink

    Good question. GWT’s primarily a client-side framework. The most common way to integrate with the server is via GWT-RPC, which lets you define asynchronous interfaces on the client and implement them on the server in Java. But there are definitely other ways to do it and it’s not at all necessary to use GWT-RPC to use GWT. I know of other projects that have used separate mechanisms to make POST requests directly for communicating with a server. In that case, it wouldn’t matter what the server is written in. I haven’t tried this myself, though.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: