Skip to content

Why GWT? Part I: Moving beyond the page metaphor

by on October 18, 2010

Hello everyone. My name is Erik Kuefler, Accevia’s technical co-founder. I’ll be joining Smita in writing for the blog, focusing on the technical details of creating a web application like Accevia. To start with, I want to talk about the main technology powering Accevia: Google Web Toolkit. I’ll talk about what it is, why we chose it, and why you might want to use it for your projects.

In a nutshell, Google Web Toolkit (usually abbreviated to GWT and pronounced “gwit”) is a set of tools and libraries for creating web applications in Java. You create your entire client and server using Java libraries, then GWT compiles the client-side code into Javascript and fills in the details to make it talk to the server nicely. Why would you want to do this instead of writing your own Javascript, or using a framework like Rails or Django? That’s what I’ll talk about today and in my next post.

Before I talk about GWT itself, it’s important to understand how the web has evolved over time. One of the most important trends in the web’s evolution is a movement away from static, unchanging pages and towards dynamic pages that can change the content they display. We can look at this in three steps. First, we have static pages with static content: with these, every time you type a URL into your browser, it will show you the exact same page. The only way things would change would be when a human went in and updated the page directly. In the initial days of the Internet, this made a lot of sense. The web was designed for people to share complete documents with each other, and documents don’t change that much.

The next step was the major breakthrough that allowed the web to do more than just show documents. By using static pages with dynamic content, the power of the web exploded: people could now create full-fledged web applications. By generating page content dynamically, you could create a section of a university’s web page allowing students to see their grades, updated every semester. You could create an email inbox that showed only unread messages addressed to you, allowing you to fetch new messages by refreshing the page. The ability to generate dynamic content changed the web from a passive document viewer to a vessel for interactive application deployment.

This is as far as most people go when they talk about interactive web applications, but I believe there’s one more important level: dynamic pages with dynamic content. Before, servers were able to decide dynamically what would go on the page, but the page couldn’t change after it had been created. For a change to happen, the user would have to request a new page from the server, and the server would rebuild the whole page. This works, but it’s not an optimal use of resources. Consider the Google search results page. Its focus is on the dynamic results of your search query, but it also has a lot of static content.

So what happens when the user enters a new query here? In the past, Google and every other website would have thrown the current page away and asked the server to build a new one for the new query. But this is wasteful! The header, sidebar, and page layout aren’t changing at all; we don’t want a whole new page, we just want to see new search results. Sending a whole new page wastes the user’s time since he has to download an entirely new HTML document and his browser has to render it. It wastes the server’s time since it has to build a new page and send it to the user. When you serve as many queries per day as Google does, the extra time required to do all this starts to add up.

People still think of the web in pages, but that’s only partially true these days. Most of what’s on the web now is applications, each with a complex stream of input and output. The term “Web 2.0” was overused a few years ago and no one could agree on what it meant or whether it had been achieved. On the modern web, we need much finer-grained control over the users’ experience than sending them a sequential stream of pages. This is the crux of the issue to me: a Web 2.0 application is one that moves beyond the page metaphor, acting like a desktop application by reacting directly and immediately to the users’ actions. The page metaphor still pervades most of web development, but I see it as a harmful abstraction that limits what we can do with the web.

I haven’t even mentioned GWT yet, but this sets the stage for what I’ll talk about in my next post: how GWT lets us break free from the page metaphor and why it is an especially good tool for doing so. See you then!

Leave a Comment

Leave a Reply

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

You are commenting using your 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 )

Connecting to %s

%d bloggers like this: