Errai: The browser as a platform

Wednesday, November 23, 2011

Setting the Record Straight on GWT

Since joining the Errai team, I've been telling lots of people about our project. Every time I do this, I find myself dispelling some common misconceptions about what GWT is and how it can be used. I also find people are surprised that GWT code has easy access to the browser's native environment: although GWT smooths out implementation details between browsers, it is not a firewall that cuts you off from the underlying environment.


So what is GWT?

GWT, the Google Web Toolkit, is a project with many independent parts. Here's a partial list:
  1. A Java-to-JavaScript compiler
  2. A class library providing:
    • a subset of the Java SE 5 standard library (most notably java.lang and java.util)
    • A programmatic UI framework (somewhat like Swing)
    • Java wrappers for native browser functionality such as JSON and XML manipulation, XMLHttpRequest (AJAX and Comet), and HTML 5 features like Canvas, Local storage, Audio and Video.
    • An RPC mechanism you can use if your application's backend happens to be written in Java (GWT RPC can't easily be retrofitted on an existing object model, but you can use it to build a server-side RPC layer)
  3. GWT Designer, a visual UI layout tool that generates code for the Swing-like UI framework
  4. UiBinder, a system for declarative UI (you define layout in files that are essentially XHTML interspersed with GWT widgets, with named elements automatically bound to fields in a companion Java class)
  5. Plugins for Eclipse, Maven, and Ant that help with creating, building, testing, and debugging GWT applications
The compiler itself is fundamental to any usage of GWT. Everything that follows is optional: you can take it or leave it, mix and match, use third-party alternatives, or invent your own replacements.


And what isn't GWT?

Now that we've listed off the highlights of what is included in GWT, it's important to address what it's not:
  1. GWT doesn't mandate a single, prescribed way of creating user interfaces. In particular, you don't have to create UIs in a "Swing for the browser" mindset unless you want to.
  2. GWT is not a server-centric system like JSF. Your GWT application compiles down to a collection of static files: HTML, CSS, images, and JavaScript. The application runs autonomously in the browser, communicating with the server only when it wants to. If you're not using GWT RPC, your apps need not be hosted on a Java web server.
  3. GWT does not require any browser plugins. Your compiled app is just one or more standards-based web pages.
  4. GWT does not prevent you from writing JavaScript directly. You can write inline JavaScript in your Java classes using JSNI, you can expose your Java APIs to JavaScript, and you can call JavaScript APIs from Java.
  5. GWT is not a dead project. Rumours of its demise are greatly exaggerated. 


If my GWT app just boils down to JavaScript and HTML, why bother with all this?

That's a great question. Thanks for asking. There are many compelling reasons to use GWT over raw HTML and JavaScript. I will address my favourite reasons in a future post, along with another question that I hope is burning in your mind: if GWT does all this, what does Errai add to the mix?

1 comment:

  1. Great post, Jonathan.

    I'd like to add one more point here. Modern web browsers are no longer just HTML/CSS viewers with limited scripting capabilities. They are, in fact, fully-capable web application platforms, with JavaScript being the dynamic language of modern web.

    Whether using the single-page dynamic web app approach, or designing your apps using progressive enhancement strategy, JavaScript and asynchronous server communication through XHR make web apps better for everyone: optimized client-server data transfer, improved responsiveness and better user experience, and use of advanced HTML 5 features such as local storage.

    And that's why I like tools such as GWT in the first place.

    ReplyDelete