We're excited to have another guest blog post for you, brought to you by Jeet Kaul, VP of Sun's Developer Products and Programs. He's here to talk about using NetBeans to build web apps with GWT.

We're excited to have another guest blog post for you, brought to you by Jeet Kaul, VP of Sun's Developer Products and Programs. He's here to talk about using NetBeans to build web apps with GWT.

Google Web Toolkit is getting a lot of attention in the web developer community thanks to its interesting way of avoiding the need to write JavaScript code for interactive web applications. Developers from the NetBeans community recognized the benefits of such a solution and created a plug-in which integrates GWT support into the NetBeans IDE. NetBeans users can now choose GWT as one of the supported web frameworks, and NetBeans then helps them with all the important tasks such as editing, building, running and debugging GWT applications. Here's how to get started with GWT development in NetBeans and where to find more information about the plug-in.

Although GWT is not supported in NetBeans 6 out of the box, you can download this GWT plug-in and start developing GWT-based applications in NetBeans.

The first step is to install the plug-in using the Plug-in manager. Go to the "Tools | Plugins" menu action, switch to the "Downloaded" tab and locate the plug-in on your disk drive. You don't even have to restart your IDE - GWT support is instantly available for you!

The plug-in is seamlessly integrated into NetBeans IDE. That means that when you create a new web application GWT is shown as one of the available frameworks in the last step of the New project wizard. Here you can specify the GWT installation folder and choose the main entry point class of your GWT module.

You can use the plug-in both if you start from scratch or if you want to work on an existing GWT application. So if you used a different IDE than NetBeans before, it is easy to switch the GWT application to NetBeans. You just point the wizard to your existing GWT application and create a new project from existing sources.

Once you get the project created you can run the application simply by hitting the Run button. There are two options – you can either use the default Run action which deploys the application to the application server and opens your default web browser. The other option is to run GWT in hosted mode and then the GWT development shell is opened and you can see your application inside of it.

Debugging is also supported, so you can just run the Debug action and then the runtime is ran in debug mode. You can simply add breakpoints, step into, step out, etc. as you would expect in a regular web application.

NetBeans already provides lots of tooling out of the box that you can take advantage of, like a powerful XML editor, HTML editor and of course a Java editor with code completion and quick fixes. NetBeans 6 made huge strides in improving the editing experience and it shows when developing GWT applications, too. All GWT APIs are available for you including javadoc documentation, because the GWT jars get automatically added into the project during it's creation.

To learn more about GWT support in NetBeans, the project homepage and screencast can help you get started. Sang Shin, a member of the Sun technology evangelism team, also created a free course for GWT and NetBeans, so you can learn from his examples and do the hands-on lab.

The plug-in was developed as an open source project so we encourage developers to join the project and contribute. There are many ways you can contribute, even submitting an issue or request for enhancement counts.

The future roadmap contains exciting features such as refactoring for GWT and GWT-specific quick fixes in the editor which will make developing GWT code even more comfortable. We are always looking for feedback, so if you try out the project let the developers know what you think.

Another project that may be of interest is jMaki, an AJAX framework that provides a lightweight model for creating JavaScript centric AJAX-enabled web applications using Java, Ruby, PHP, and Phobos. jMaki has an integrated NetBeans module for all the above languages, and some new features are being developed that will expose all the jMaki widgets as GWT java components, easily accessible to GWT application developers using NetBeans.

There's also Project Woodstock, which provides the next generation of User Interface Components for the web, based on Java Server Faces and AJAX. This open source collaboration enables a community of developers to create powerful and intuitive web applications that are accessible and localizable, and which are based on a uniform set of guidelines and components, to help ensure ease of development and ease of use. These components enable visual web application development in NetBeans. Just drag and drop from the palette into the designer canvas and visually bind them to heterogeneous back end data sources (e.g. databases, Web Services, EJBs). Build powerful applications in minutes.

The NetBeans community has been growing a lot in past several years and NetBeans became a truly universal IDE, so if you haven't tried it recently, you may be surprised about the progress it has made. After all, it won't cost you much - it's free and open source. So give it a try today!

Pearson's Voices That Matter: Google Web Toolkit conference is only a few weeks away, and we're eager to meet folks from the GWT community there. For those of you looking for a little financial assistance, we've worked with Pearson to put together a GWT Scholarship. It's meant to reward folks who have built neat things with GWT, made it better by submitting bug reports and patches, or simply actively discussed GWT in the forums. If you receive a scholarship, you can attend the 3-day conference for a reduced rate of just $150.

Pearson's Voices That Matter: Google Web Toolkit conference is only a few weeks away, and we're eager to meet folks from the GWT community there. For those of you looking for a little financial assistance, we've worked with Pearson to put together a GWT Scholarship. It's meant to reward folks who have built neat things with GWT, made it better by submitting bug reports and patches, or simply actively discussed GWT in the forums. If you receive a scholarship, you can attend the 3-day conference for a reduced rate of just $150.

We'll be handing out 25 scholarships to folks who have worked hard and contributed to the GWT community. Examples of contributions are:

  • Deploying a product using GWT (or even prototyped something neat)
  • Reporting and debugged some of the issues
  • Submitting a patch (to help Make GWT Better)
  • Participating in the discussions on the developer forum

If you're interested in applying for the Pearson GWT Conference Scholarship, send us an email explaining how you've contributed and how the scholarship would benefit you (no more than 300 words, please!) at gwt-pearson@google.com no later than Friday, November 16, 2007. We'll announce the recipients on Wednesday, November 21, 2007.

And we're looking forward to seeing you at the conference!

Update: scholarships still available

As an update: there are still scholarships available to attend the Voices That Matter: Google Web Toolkit conference in a few weeks in San Francisco. While we've seen several compelling entries, we'd love to see what else is lurking in the GWT community. We'll update this thread when we've run out; in the meantime, please drop us a line if you're interested.

We've got another guest blog post, this time from Russell Ivanovic, Software Developer at Groundhog Software. He's here to talk about his experience building a new product using GWT.

In 2006 Groundhog Software partnered with education specialists to deliver an electronic portfolio solution. As fate would have it, GWT was released by Google during the R&D phase of this project. Groundhog recognised that, even in its infancy (version 1.0), this was a product that could deliver the usability, scalability and ease of development that we needed. A proof of concept prototype was built successfully, and after funding was secured, full scale production began.

We've got another guest blog post, this time from Russell Ivanovic, Software Developer at Groundhog Software. He's here to talk about his experience building a new product using GWT.

In 2006 Groundhog Software partnered with education specialists to deliver an electronic portfolio solution. As fate would have it, GWT was released by Google during the R&D phase of this project. Groundhog recognised that, even in its infancy (version 1.0), this was a product that could deliver the usability, scalability and ease of development that we needed. A proof of concept prototype was built successfully, and after funding was secured, full scale production began.

Today, Groundhog Software's solution ePo Builder is successfully deployed in a pilot of over 80 schools, catering for over 16,000+ users.

So what benefits did GWT bring to the table? Let's look at a few:

  • Scalability & Bandwidth
    With over 16,000 users in the pilot phase alone, it rapidly became obvious that ePo had to be scalable. The beauty of GWT is that the client loads all of the presentation code in one hit (about 380kb) when the user first logs in. Once loaded (and cached by the browser) only very small packets of data need to go back and forth. Compare this to the traditional model of sending all your display code as well as data every time the user clicks on something, and you can quickly see how GWT saves us bandwidth, and makes it much easier to scale. This has the added advantage of making ePo 'dialup speed friendly' with none of the long page load times associated with sending your HTML code to the browser every time. This might seem trivial, until you consider that some of the most active schools on ePo share their bandwidth across many users, and are located in remote areas of Australia.
     
  • Focus on Usability, not Browsers and Syntax Errors
    Because GWT is coded in Java and compiled to cross browser JavaScript, the ePo dev team was able to use industry leading IDEs like NetBeans and Eclipse. With compile time checking, many levels of automation, and easy re-factoring, we were able to focus on design and usability and let GWT worry about the low level details. Working in Java has one other side benefit. While ePo was initially built in GWT 1.0, it transitioned to GWT 1.1, 1.2, 1.3 and finally 1.4 without any hiccups. The compiler flagged any errors immediately at compile time, and made fixing any small API changes a breeze. Also, the compiler has been improving over time, meaning that the final ePo code shipped on 1.4 ran faster, with smaller RPC packets than the original one, without our team needing to lift a finger!
     
  • Easy, Light AJAX
    GWT also makes AJAX easier than any other library, which makes building reusable, functional widgets a lot easier than ever before. Consider one quick example: when building ePo we wanted to create a stack panel, where many panels are in the stack, and you display one at a time. The first iteration was just a panel that hides and shows its contents, but we found the instant transitions confusing -- you click and your data disappears and is replaced by something else. So the logical choice was a 'slide' style transition. In traditional JavaScript development this would mean using a library like Dojo or Scriptaculous, each of which are extra downloads for the end user. Using GWT, Groundhog Software created an Effects framework that, once compiled, adds only 2kb to the size of the code - this is because the GWT compiler only compiles the code that you actually use. This allowed us to create a large, reusable framework for slides, fades and movements that we use across multiple projects without worrying about the overall size of the library, knowing the compiler would only take the bits we use.


     
  • GWT Magic - RPC and ImageBundle
    This last section I've title GWT Magic, and here's why. The back end of our project uses J2EE for all of our business logic and persistence. Traditionally to hook JavaScript or Flash into this framework, you have to get fancy with either XML or JSON. With GWT, you just use the built in RPC mechanism. The beauty of this is that you can pass your value objects directly from the back end, and use them on the front end without any need for modification or serialization; GWT does all this for you. The ImageBundle is an even more impressive bit of magic. It allows you to work with all your individual images as you normally would (for buttons, logos, status indicators, etc). When you compile your code, GWT combines all of these individual images into one big image, and adds all the smarts to your code for cutting the image up on the client side (using offsets). This has one massive benefit: instead of your browser making lots of little requests for each and every image (each with their own latency) only 1 request is made. This also has the added benefit of removing the 'jumpy' effect you get in browsers when you load in lots of little images at once.

Our website has more information about ePo Builder and Groundhog Software.

We wanted to highlight another success story for GWT. Lombardi Software has created an innovative modeling tool called Blueprint that they recently built using GWT. Rather than having me tell the story, here are the details from Alex Moffat, Engineering Manger at Lombardi:

We wanted to highlight another success story for GWT. Lombardi Software has created an innovative modeling tool called Blueprint that they recently built using GWT. Rather than having me tell the story, here are the details from Alex Moffat, Engineering Manger at Lombardi:

Lombardi Blueprint includes around 28,500 lines of our Java code that gets compiled to JavaScript by GWT. We think that's quite a lot but the largest page is 50% smaller, at 480K, than the less functional Dojo based prototype, and it was much easier to develop.

The challenge handed to us was to create a tool that the average business user could use to document and manage their business processes. It had to be easy to use, encourage collaboration between team members, and provide a shared repository for all of a company's process documentation. Workflow functionality had to be on par with our competitors: Microsoft Visio, IDS Scheer's ARIS, IBM's WebSphere Business Modeler, and other desktop modeling tools. But we also wanted wiki & shared whiteboard capabilities to store information. Editing should use the drag and drop interaction users of desktop apps are familiar with. We ended up with some additional features that really set us apart:

  • An intuitive map view as a high level visualization of a process
  • Automatic workflow diagram generation
  • PowerPoint generation for easily presenting the process
  • Online chat functionality

All that was a significant task for us to tackle and without GWT we wouldn't have accomplished it. It turned out that coding in JavaScript just wasn't an option for such a complex application. If you're developing a browser based app we'd highly recommend using GWT. And we've seen great success, with thousands of users in Fortune 500 companies around the world. And opposite the Web 2.0 / Enterprise 2.0 concern, users actually pay for our app!


(see the larger video)

Back when we began developing Blueprint, we started with a combination of HTML and Flash 8 for the interactive parts. We ended up abandoning that fairly quickly for a couple of reasons:

  • Flash is a plug-in. Even in this day and age, not everyone has the latest version of Flash installed on their machines. Lots of our users are at big corporations where their boxes are locked down tight enough that installing/upgrading browser plug-ins is a nonstarter.
  • Browser plug-in behavior is unpredictable. Weird browser interaction bugs made cross platform Flash support harder than we thought.

Our next iteration was pure HTML and JavaScript using Dojo. This approach fixed the problems we had with Flash, but had its own issues:

  • Execution speed and network performance. Dojo is a great and full featured framework, but that's a double edged sword. When we were done, we were including a JavaScript library on every page that was over a MB and a lot of that was dead code.
  • It felt like a black box. While Dojo is open source, without a good debugger it was very difficult to figure out what was going on under the hood. We got pretty good at using firebug and venkman with Firefox but that still left IE and neither solution was terribly easy to use.

Around that time, GWT 1.3 was released and we decided to take the plunge. Fortunately we didn't have to convert all of our JavaScript code to GWT at once. By using GWT's JSNI facilities, we were able to migrate areas gradually as we needed to make functional changes. Compared to our earlier efforts, GWT has allowed us to be far more productive and flexible. The big wins for us have been:

  • Great tooling. The fact that you can develop a GWT app using Eclipse or IntelliJ and use their refactoring support is huge. Whereas with the pure JavaScript solution we never did even simple changes like renaming methods for fear that we'd break things, now we can do that and far more aggressive changes with confidence.
  • Massively improved debugging. Hosted mode debugging is wonderful.
  • Elimination of memory leaks, especially in IE6. While the circular reference leak in IE6 was partially fixed in July with Microsoft security bulletin MS07-033, many of our clients (corporate users) have not installed it yet. Using GWT means the generated JavaScript code doesn't include the leak producing patterns.
  • Easy browser specific code. While GWT does a good job of hiding browser differences from us in most scenarios, there are always edge cases that we have to handle with our own code. GWT makes it really easy to add browser specific code and have that code only be served up to the appropriate browsers.
  • Code size and execution speed. The amount of JavaScript that we serve up on each page is far less with GWT. We're down to about 480K with GWT 1.4 for our largest page from over a MB since GWT compiles in only the code we need. In addition GWT 1.4 produces JavaScript that is about 70% of the size of the GWT 1.3 output for our pages, and the compilation process is about twice as fast. That's a nice benefit to get for what's turning out to be a very easy upgrade for us.
  • Unit tests. GWT makes it easy to run unit tests on our client side code without having to launch a browser. Testing the visual appearance of the screens still needs other solutions though.

Line count comparisons between the Dojo and GWT based versions of Blueprint are invidious, not least because the GWT version of Blueprint includes much more functionality than the Dojo based one did. However, for our last Dojo based release we wrote around 8,500 lines of JavaScript, and at this point we've written 28,500 lines of Java code, excluding comments, which GWT compiles to JavaScript. There's no way we could have built the equivalent functionality using JavaScript, and as mentioned before the resulting downloads are still smaller.

Overall we believe GWT has enabled us to write a much more reliable and efficient application and build it faster than we could have otherwise. Since its release just 120 days ago, people in 60 countries have begun using Blueprint; this represents more than 750 companies and thousands of individuals. You can check it out for yourself and let us know what you think!

Over the summer we blogged about a conference dedicated to the Google Web Toolkit (GWT) that the folks at Pearson Education are planning. We're happy to announce that the agenda has been posted.

Over the summer we blogged about a conference dedicated to the Google Web Toolkit (GWT) that the folks at Pearson Education are planning. We're happy to announce that the agenda has been posted.

Voices That Matter: Google Web Toolkit will take place December 3-6, 2007 at the Palace Hotel in San Francisco. The week kicks off on Monday, December 3rd, with (optional) preliminary workshops on JavaScript and AJAX development to prepare attendees for the rest of the week. Starting Tuesday morning, core conference sessions include:

  • Performance: Joel Webber, co-creator of GWT, will discuss best practices for web application performance and explain how to implement them with GWT
  • Usability: how to design GWT applications that make your end users not just happy but ecstatic
  • AJAX Security and GWT: a comparison of the security features of GWT applications and applications built with other AJAX frameworks like Prototype and Dojo as well as their susceptibility to attacks
  • Panel Session - Tools for GWT: creators of GWT-specific development tools will discuss how their products can improve your productivity by simplifying everything from RPC to 118N (internationalization)
  • Panel Session - GWT Apps in Production: learn from real-world projects about how to launch a large-scale GWT application and get the most from your serving infrastructure

In addition to the talks and panels, there will be several opportunities for more casual interactions with members of the GWT community, including the conference speakers. Nearly all of the GWT team will be speaking and participating in the conference including co-creators of GWT Bruce Johnson and Joel Webber. Feel free to check out the complete list of speakers.

Be sure to register before October 27th to receive the "early bird" discount. We'll see you there!

In our not-so-humble opinions, we think that the Google Web Toolkit (GWT) and the Apple iPhone are two very cool technologies. Because we're all highfalutin computer-scientist types (as well as being irrepressibly geeky) we wanted to see what happens when you mix them together. Would it be like peanut-butter and chocolate, or hot-sauce and poison ivy? Our approach was to build an application that primarily targets the iPhone and to use that as a test-bed for new ideas.

In our not-so-humble opinions, we think that the Google Web Toolkit (GWT) and the Apple iPhone are two very cool technologies. Because we're all highfalutin computer-scientist types (as well as being irrepressibly geeky) we wanted to see what happens when you mix them together. Would it be like peanut-butter and chocolate, or hot-sauce and poison ivy? Our approach was to build an application that primarily targets the iPhone and to use that as a test-bed for new ideas.

So what kind of application should we build? The application should:

  • demonstrate a well-defined purpose that is useful to developers using GWT
  • take advantage of the always-connected iPhone platform
  • present a UI that is familiar to iPhone users and geared towards information presentation
  • demonstrate integration between GWT and other Google technology

And so the GWT Feed Reader was created. It combines the Google AJAX Feed API with a user interface geared for use on the iPhone. The source code to GWT Feed Reader is available under an Open Source license from a Google Code project.

The primary take-away from this project is to say this: The Google Web Toolkit can be used to create applications that, in the same code base, work well on an iPhone and a traditional desktop browser. You can read more about the development of the GWT Feed Reader in a Google Groups article.


Enjoy.

It's a really big day for Google Web Toolkit: GWT 1.4 is now available -- and, with more than a million downloads under our belt, GWT is no longer in beta!

It's a really big day for Google Web Toolkit: GWT 1.4 is now available -- and, with more than a million downloads under our belt, GWT is no longer in beta!


New to GWT?

Let's start with what some folks have to say about their experience using GWT during the past year...

The toolkit is more than a pleasure to use and made my web-app development actually FUN again.
- Dean S. Jones
This year, for the first time, I have started to learn AJAX. To get my feet in the ground, I have attended several seminars and talked to many friends knowledgeable on AJAX. I came across a lot of frameworks and tools. Dojo, Prototype, Rico, Scriptaculous, jMaki - you name it. I had everything installed in my laptop. After struggling for a month, I realized that I was not learning anything new, let alone building an application using AJAX. Then, I looked at GWT. Things slowly started moving in the positive direction. I was able to leverage my 8-10 years of Java experience to build AJAX applications using GWT. I didn't have to bother learning javascript or other AJAX internals. GWT made sure that the application I am writing is cross-browser compatible.

Thanks to the Google team for building this wonderful piece of technology. You must realize how many new people are benefited everyday from your hard work and creativity. I have completed my second AJAX project using GWT. I couldn't have done this without you.
- Sudhansu Pati
Q: Can anyone provide a ball-park numeric estimate of how much time the use of GWT saved you?
- John Gunther [asked on the GWT Developer Forum]

A: 100% + faster. Easily. And this number goes up as application complexity goes up.
- Ryan Dewsbury

A: GWT will -really- save you time in maintenance (try and refactor browser dependent javascript if you dare!), and GWT is a great tool for scaling your server, because it allows you to ship off a lot of state info to the client.
- Reinier Zwitserloot
For a while we had an AJAX-style solution using JavaScript hand-coded by a contractor. The contractor left, the code was the most hideous thing I've ever seen...that sure wasn't the answer. [...] The original application was developed over a period of several years, [yet] we have basically rewritten the user interface in GWT with three Java developers over about five months. There is no way we could have done that writing in any kind of scripting language, and still have it be maintainable and flexible (which is very important to me).
- Tim Ihde
Keep up the good work...this project is the best I've seen in a long time! It's already saved me weeks of tedious javascript coding and revolutionised the way my company writes technology demos.
- Sam Halliday

If you're interested to learn more, here are some links to help you get started:

What's new in GWT 1.4?

There's lots and lots of cool new stuff in GWT 1.4, so it's hard to know where to start. How about application performance?! This release includes several breakthroughs that make your compiled GWT code significantly smaller and faster. Many users are reporting that after a simple recompile with 1.4, their applications are up to 30% smaller and 20%-50% faster. And startup time in particular is now highly optimized thanks to a new bootstrapping technique and the availability of image bundles. To see the new hotness in action, try visiting the new-and-improved Mail sample a few times. It's darn fast the very first time you visit it, but subsequent visits are insanely fast. That's because, in addition to a fast initial startup, GWT code uses a clever caching technique to prevent applications from making unnecessary HTTP requests. As Joel Webber (Tech Lead of GWT Core Libraries) would say, "The fastest HTTP requests are those that do not, in fact, occur."

Here's a broad overview of the major enhancements:


New widgets and libraries
  • RichTextArea, HorizontalSplitPanel and VerticalSplitPanel, SuggestBox, DisclosurePanel, PushButton, ToggleButton, and an enhanced Image widget make advanced applications easier than ever.
  • ImageBundle automatically consolidates multiple images into a single HTTP request.
  • NumberFormat and DateTimeFormat make easy work of complex internationalization and localization.
  • You can finally use java.lang.Serializable with GWT RPC, and the GWT RPC server-side subsystem is no longer intimately tied to servlets. You can easily wire it into any Java back-end infrastructure. Spring fans, rejoice.
  • A new JUnit-based benchmarking subsystem makes measuring and comparing the speed of code snippets as easy as writing unit tests.
New deployment options and optimizations
  • Adding GWT modules to an HTML page is now simple: just add a <script> tag.
  • You can now include GWT modules across domains. Note that including scripts from other sites that you don't fully trust is a big security risk.
  • External JavaScript files referenced from your GWT module load synchronously now, so script ready-functions are no longer needed.
  • Auto-generated RPC whitelist files are now produced during compilation to help catch accidentally responding with objects that compiled GWT client code wouldn't be able to deserialize.
  • The GWT distribution now includes a DTD for the GWT module XML format, making it easier to configure modules in an DTD-aware XML editor.

Additional details on these new features and bugfixes are in the blog post announcing the original GWT 1.4 Release Candidate.

For all you GWT veterans ready to download GWT 1.4, see the new FAQ section "How do I upgrade to GWT 1.4?" for step-by-step instructions on the update.

And for anyone totally new to GWT, on behalf of the awesomely cool developer community and the GWT engineering team at Google, welcome!

At long last, Google Web Toolkit (GWT) 1.4 Release Candidate 2 is now available for download. Though it has taken some time since 1.4 RC1 was released, we've fixed nearly 100 bugs since then. This may well be the best and most solid GWT release to date, and we expect this build will become the final 1.4 release. Still, until we designate a "final" 1.4 release, we strongly recommend against using it in production applications. If you run into problems, please let us know in the issue tracker. And if you don't run into any problems, please take a moment to thank all of the GWT open source contributors who have made such a big impact on GWT 1.4. :)

At long last, Google Web Toolkit (GWT) 1.4 Release Candidate 2 is now available for download. Though it has taken some time since 1.4 RC1 was released, we've fixed nearly 100 bugs since then. This may well be the best and most solid GWT release to date, and we expect this build will become the final 1.4 release. Still, until we designate a "final" 1.4 release, we strongly recommend against using it in production applications. If you run into problems, please let us know in the issue tracker. And if you don't run into any problems, please take a moment to thank all of the GWT open source contributors who have made such a big impact on GWT 1.4. :)

Looking ahead, we plan to start on GWT 1.5 quickly, the main thrust of which will be Java 5.0 language support and all that entails. We intend to make a wholesale shift to 5.0 syntax for all GWT client code; with luck this won't be problematic, since Java 5.0 syntax is largely backwards compatible. An open question is whether we will continue to produce Java 1.4-compatible server-side components. Feel free to join in the discussions on the Developer Forum.

With all of the excitement around Google Developer Day, we didn't have a chance to tell you about a subtle point regarding the launch of the Google Mashup Editor: the editor's front-end was built using the Google Web Toolkit (GWT). Given that, we invited Rich Burdon, Tech Lead of the Google Mashup Editor team, to write a post detailing why they chose to develop using GWT. Here's Rich:

With all of the excitement around Google Developer Day, we didn't have a chance to tell you about a subtle point regarding the launch of the Google Mashup Editor: the editor's front-end was built using the Google Web Toolkit (GWT). Given that, we invited Rich Burdon, Tech Lead of the Google Mashup Editor team, to write a post detailing why they chose to develop using GWT. Here's Rich:

At Google Developer Day, we launched the Google Mashup Editor -- a quick way to build simple applications. The Mashup Editor lets you create mashups without having to do much coding; instead, you use standard HTML and extended tags, which correspond to UI controls that can display and manipulate RSS, Atom and GData feeds.

The product consists of three parts:

  • The Mashup Editor, which is itself an AJAX application.
  • A server-side hosting framework, which provides developer services (e.g., source code management via Google Code project hosting) and mashup services such as Google Base and a data store that can be accessed via feeds.
  • A JavaScript client library that implements the mashup UI controls and data processing functionality. The server-side components leverage Google's scalable infrastructure and provide access to Google services via the Google data APIs protocol; the client-side components were developed exclusively using the Google Web Toolkit.

Before starting the project, our team already had a lot of experience building complex AJAX applications by hand -- and had experienced many of the problems associated with this approach. Here are some of the reasons why we chose to use GWT rather than rolling our own native JavaScript framework this time around:

  1. Tools matter. As a veteran of the long-ago vi versus emacs debates, it's interesting to see the same enthusiasm go into the Eclipse vs. IntelliJ IDE arguments. Whichever side you're on (I fought for the latter in both cases, but we have members of both camps on our team), tools can make a huge difference in terms of developer productivity. You used to think twice before refactoring a large component that needed attention; having the tool take care of these kinds of complicated, repetitive (and error-prone) tasks makes life easier and can lead to better quality.
  2. OO is a good idea. I remember figuring out how to make JavaScript objects polymorphic and finally understanding what a closure is. Indeed, my colleague Stephan Meschkat, who works on the Maps API, often reminds me of JavaScript's inherent power and elegance. However, I like to have keywords like "interface," "private," and "final" at my disposal -- even better to have my compiler (and my editor) remind me that I'm attempting to call a function with inappropriate arguments. Type safety saves debugging time, and OO abstractions can help to reduce complexity in your code.
  3. Compatibility. Java's original slogan of "write once, run anywhere" fell victim to the intense competition between browser developers. Although JavaScript, being a smaller core language, has fared somewhat better, the complexities of juggling different DOM implementations over a growing number of browser platforms makes writing cross-platform AJAX components difficult. GWT's ability to insulate you from much of this complexity probably makes it a no-brainer for this benefit alone.
  4. The client is only half the story. Both the Mashup Editor and the resulting mashups themselves interact with Google services; being able to code both sides of a remote method call in the same language has some obvious benefits. Aside from the relative simplicity afforded by the GWT RPC mechanism, both client and server components can share constant definitions and in some cases, simple functions.
  5. Open systems are less scary. A programming framework is something that introduces abstractions. The benefits include making complex concepts simple and quicker to implement; the downside is that if you want to do something that the framework wasn't designed for, you're on your own. It was important for us to be able to get under the hood and tweak the native JavaScript. For example, the Mashup Editor's template-processing functionality uses a native JavaScript library that we borrowed from the Google Maps API.

Of course, the other huge benefit of open systems (and especially open source projects) is learning from the collective wisdom of everyone who uses the technology. And so we're looking forward to incorporating the ongoing developments of GWT within the Mashup Editor.

Interested in playing around with the Google Mashup Editor? Head over to its homepage to sign up for the limited beta, and then check out our mashup gallery and developer forum for sample mashups built by the community.

OSCON 2007 is starting now! As you may have already read, Google is quite involved with OSCON this year. On the Google Web Toolkit (GWT) team, we're especially excited as this is the first OSCON since GWT went open source.

OSCON 2007 is starting now! As you may have already read, Google is quite involved with OSCON this year. On the Google Web Toolkit (GWT) team, we're especially excited as this is the first OSCON since GWT went open source.

Joel Webber, Bob Vawter, Rajeev Dayal, and I are heading to Portland to be on hand for Wednesday evening's Google Web Toolkit Hack Session. We hope it'll be a lively discussion about what people are already doing with GWT, what important questions are lingering, and suggestions for future improvements. Attendance is limited at this event, so please arrive promptly.

And beyond the numerous other talks Googlers are giving, Joel Webber will speak on Thursday about Writing Big Apps with GWT.

Also on Thursday, at the AJAX Experience in San Francisco, Dan Morrill will be presenting Fast, Easy, Beautiful: Pick Three -- Building AJAX Apps with GWT.

Outside of conference participation, we wanted to let you know that we're in the home stretch for the second release candidate for GWT 1.4. If you've not already had a chance to see GWT 1.4's first RC, we'd recommend you read up on what's new, and try it out. For GWT 1.4 RC2, you can watch the progress on GWT's issue tracker as open issues dwindle.

A little while ago, we heard from the folks over at Pearson Education who said they were impressed with the interest in the Google Web Toolkit (GWT) and wanted to produce a 3-day GWT conference. After a few conversations to flesh out topics and program logistics, we’re pleased to report that Voices That Matter: Google Web Toolkit is set for December 4-6, 2007 in San Francisco. We couldn’t be happier to be working with Pearson on this event.

A little while ago, we heard from the folks over at Pearson Education who said they were impressed with the interest in the Google Web Toolkit (GWT) and wanted to produce a 3-day GWT conference. After a few conversations to flesh out topics and program logistics, we’re pleased to report that Voices That Matter: Google Web Toolkit is set for December 4-6, 2007 in San Francisco. We couldn’t be happier to be working with Pearson on this event.

While we’re still discussing the nitty-gritty details of the schedule, nearly all of the GWT team will be speaking and participating in the conference, so we hope we’ll be able to have a chance to talk with you. You can be certain that the topics will include:

  • Performance: How to design for high performance and get the most out of your applications using GWT by taking advantage of features like ImageBundle in GWT 1.4.
  • Usability: Designing for a friendly user experience and making use of GWT's Widget library.
  • Security: Building off of Dan Morrill’s article, we'll discuss best practices for building secure applications with GWT.
  • Production: Tips on deploying and operating a GWT app.
  • Integration and interoperability: How to leverage things like the JavaScript Native Interface (JSNI) to extend existing AJAX apps or interoperate with JavaScript APIs.
  • Productivity: Leveraging existing tools to bring software engineering to AJAX.

If there are specific topics you want to learn more about, please speak up on the GWT Developer Forum. And in case you just can’t wait until December, you’re in luck:

Now that we've almost recovered from Google Developer Day, it's time for a quick review of some recent GWT sightings in the blogosphere:

  • Fast, Beautiful, Easy: Pick Three

    The Google Web Toolkit talk that Bruce Johnson and I gave at Google Developer Day is now online. As you might have guessed, it emphasizes end-user experience, GWT usability features, and several of the big improvements made in GWT 1.4 RC.

  • GWT Demystified

    This is an in-progress blog series talking about the nuts and bolts of GWT by Ray Cromwell, CTO of Timepedia. Timepedia recently released Chronoscope, a GWT charting and visualization platform. In his first post, Ray delves into some of the theory and practice of the GWT compiler, explaining many invisible-but-important details that don't typically get a lot of fanfare.

  • GWT a Year Later

    AgileAjax recently posted an interview with Dr. Adam Tacy and Robert Hanson, authors of GWT in Action. With the benefit of a full year's experience, they thoroughly answer some of the initial doubts about the GWT approach expressed on Ajaxian soon after GWT's initial launch.

Now that we've almost recovered from Google Developer Day, it's time for a quick review of some recent GWT sightings in the blogosphere:

  • Fast, Beautiful, Easy: Pick Three

    The Google Web Toolkit talk that Bruce Johnson and I gave at Google Developer Day is now online. As you might have guessed, it emphasizes end-user experience, GWT usability features, and several of the big improvements made in GWT 1.4 RC.

  • GWT Demystified

    This is an in-progress blog series talking about the nuts and bolts of GWT by Ray Cromwell, CTO of Timepedia. Timepedia recently released Chronoscope, a GWT charting and visualization platform. In his first post, Ray delves into some of the theory and practice of the GWT compiler, explaining many invisible-but-important details that don't typically get a lot of fanfare.

  • GWT a Year Later

    AgileAjax recently posted an interview with Dr. Adam Tacy and Robert Hanson, authors of GWT in Action. With the benefit of a full year's experience, they thoroughly answer some of the initial doubts about the GWT approach expressed on Ajaxian soon after GWT's initial launch.

It is quite rewarding to see increasing awareness of just how well the GWT approach works in practice and how much value the GWT compiler and code generators bring to the AJAX development process.

To add to the excitement around Google Developer Day, just a hair after our one-year launch anniversary, it turns out that Google Web Toolkit (GWT) has been downloaded more than 1 million times!

To add to the excitement around Google Developer Day, just a hair after our one-year launch anniversary, it turns out that Google Web Toolkit (GWT) has been downloaded more than 1 million times!

We're especially excited to see the amount of interest since GWT went open source. With advances like those in GWT 1.4, we feel we're making solid progress towards our mission "to radically improve the web experience for users by enabling developers to use existing Java tools to build no-compromise AJAX for any modern browser" (you can read more about our mission to make GWT better).

So try out GWT. You'll be in good company.

We hope you saw the recent announcement of Google Gears, which is being unveiled at Google Developer Day.

Well, we were so excited about the possibility of AJAX applications working even while offline, we went ahead and put together the Google API Library for Google Web Toolkit with support for Google Gears. This open source library allows developers writing applications with Google Web Toolkit to take advantage of the Google Gears APIs to develop applications that work offline — on a plane or anywhere else you happen to be.

We hope you saw the recent announcement of Google Gears, which is being unveiled at Google Developer Day.

Well, we were so excited about the possibility of AJAX applications working even while offline, we went ahead and put together the Google API Library for Google Web Toolkit with support for Google Gears. This open source library allows developers writing applications with Google Web Toolkit to take advantage of the Google Gears APIs to develop applications that work offline — on a plane or anywhere else you happen to be.

Since interoperability is at the very core of GWT, we wanted to take this opportunity to show an example of how GWT applications can be built with JavaScript APIs, taking advantage of GWT's JavaScript Native Interface (JSNI).

Please keep in mind that this is an early prototype of this library, and so your mileage may vary. We are planning to add support for other Google APIs; if you'd like to help, please check out Making GWT Better, and contribute your ideas. If you're curious to get started, check out the project on Google Code.

I'm very happy to report that Google Web Toolkit (GWT) 1.4 Release Candidate is now available for download.

This is undoubtedly the biggest GWT release yet. In addition to 150+ bugfixes, GWT 1.4 RC includes a ton of new features, improvements and optimizations. You'll find the complete itemized list of changes in the GWT issue tracker, but here's the short(er) version:

I'm very happy to report that Google Web Toolkit (GWT) 1.4 Release Candidate is now available for download.

This is undoubtedly the biggest GWT release yet. In addition to 150+ bugfixes, GWT 1.4 RC includes a ton of new features, improvements and optimizations. You'll find the complete itemized list of changes in the GWT issue tracker, but here's the short(er) version:

  • Size and Speed Optimizations
    • New size improvements in the GWT compiler produce JavaScript that is 10-20% smaller when simply recompiled with GWT 1.4 RC.
    • An enhanced startup sequence reduces the size of your module's startup script by 80%! Even better, the new startup sequence removes an entire HTTP round-trip, reducing latency during those crucial first few hundred milliseconds at startup. According to our measurements, modules load about 33% faster as a result.
    • The above optimizations combined with ImageBundle, described below, make it possible for GWT-based applications to load surprisingly quickly. To see for yourself, check out startup time of the Mail sample included in the GWT 1.4 RC download.
  • Deployment Enhancements
    • GWT RPC is no longer tied to exclusively to servlets. New modularized RPC server code makes it easy to connect GWT RPC to your choice of Java back-ends.
    • Adding GWT modules to an HTML page has been simplified: just add a <script> tag. You no longer need to use <meta name="'gwt:module'"> and <script src="gwt.js">. Just reference your module and go.
    • Cross-site script inclusion is now supported. The compiler produces a "-xs" (meaning "cross-site") version of your module's startup script that can be included without being restricted by the same-origin policy. Be careful, though. Including scripts from other sites that you don't fully trust is a big security risk.
  • Widget and Library Enhancements
    • RichTextArea allows "drop in" functionality for rich text editing.
    • SuggestBox makes it easy to add auto-complete functionality.
    • Splitters! HorizontalSplitPanel and VerticalSplitPanel allow users to resize portions of the user interface.
    • PushButton and ToggleButton are easy-to-customize button widgets that can enhance the look-and-feel of your UI.
    • DisclosurePanel is a simple, nice-looking panel that lets users easily hide and show portions of your application UI.
    • DateTimeFormat and NumberFormat make it easy to parse and format dates, times, and numbers for users all over the world.
    • IncrementalCommand helps you implement long-running tasks in your client code without triggering "slow script" warnings.
    • A new benchmarking subsystem integrates with JUnit to let you record and compare the speed of code snippets across multiple browsers and multiple parameter ranges. Benchmarking is a powerful way to identify bottlenecks and compare performance of alternative implementations.
    • The oft-requested java.io.Serializable is now included in the JRE emulation library and is synonymous with IsSerializable for the purpose of GWT RPC.
    • Mouse wheel events are now available on a variety of widgets.
    • And lots and lots of other enhancements.
  • ImageBundle
    • ImageBundle is the single biggest have-to-see-it-to-believe-it feature of GWT 1.4 RC. Image bundles make it trivially easy to combine dozens of images into a single "image strip", collapsing what would have been dozens of HTTP requests into one: a single, permanently-cacheable image file.
    • Image bundles manage everything for you automatically, from computing clipping rectangles to making transparent PNGs work in IE6. You can even choose to get the clipped image as an Image widget or as pure HTML for inclusion in a larger HTML template.
    • In addition to enabling a blazing-fast startup, image bundles help make the UI look better during startup, too. Typical AJAX apps exhibit "bouncy relayout" as individual images are loaded one-at-a-time. To fix this problem has traditionally required laboriously pre-initializing the width and height of each individual image ahead of time. Image bundles do the same thing automatically. The dimensions of each clipped image are computed automatically during compilation as the bundled image file is being created. Voila! The result is a fast, non-ugly user startup experience that requires no extra work on the part of the GWT developer to keep up-to-date.

GWT 1.4 RC is the first release developed with major participation from the GWT open source contributors. Many of the biggest improvements in GWT 1.4 RC came from ideas and patches contributed by the community. A big congratulations and thank you is in order to everyone who has worked so hard to make GWT 1.4 RC happen.

In other GWT news...

  • JavaOne:
    • A few weeks ago at JavaOne, several of the GWT team members had the pleasure of meeting — and, of course, talking shop with — several active members of the GWT community. It's great to actually be able to talk about all this cool stuff in person now and then :-)
    • In case you weren't able to attend, check out a review of the JavaOne GWT talk.
    • We're also really pumped to see that GWT in Action was a best-seller book at JavaOne.
  • GWT in the classroom:
  • Video of GWT conference session:
    • The video of my talk "What, Why, and How" from JavaZone 2006 is now available online. It's a good introduction to GWT because it explains the motivation for AJAX itself — focusing on end-user experience, of course.
  • Technical review of GWT:
    • In case you're curious to hear what other people think about GWT, take a look at this review.

It seems like it's been one major event after another lately. Next up: Google Developer Day! It's happening Thursday! Please join us in Mountain View if you can, or if you'd rather, go to GWT sessions in Beijing, London, Paris, Sao Paulo, or Sydney.

With that, I'll leave you to go play with GWT 1.4 RC. As always, let us know what you think in the GWT Developer Forum.

Since JavaOne is where we first introduced you to the Google Web Toolkit (GWT), we're quite excited about all that we're doing at JavaOne this year. If you're attending the conference, be sure to check out Bruce and Joel's GWT session (Wednesday, May 9 @ 1:30pm). We hope you'll also be able to stop by the Google booth to chat. Feel free to let us know on the GWT Developer Forum, so we know to look for you.

Since JavaOne is where we first introduced you to the Google Web Toolkit (GWT), we're quite excited about all that we're doing at JavaOne this year. If you're attending the conference, be sure to check out Bruce and Joel's GWT session (Wednesday, May 9 @ 1:30pm). We hope you'll also be able to stop by the Google booth to chat. Feel free to let us know on the GWT Developer Forum, so we know to look for you.

For those of you near Seattle, Washington, if you've been waiting for a GWT presentation to get your feet wet, I'm happy to report that Bob Vawter is presenting at SeaJUG next week (Tuesday, May 15 @ 7pm).

We've also recently discovered a very elegant application built with GWT: eTripBuilder.com. Not only is their application small (136K, uncompressed) and speedy, but they're taking advantage of some of GWT's benefits: they are using history, they've built custom widgets (e.g. a date picker), and they've made great use of CSS. We're proud that GWT is a part of such a great app.

I know we've been a little quiet lately about Google Web Toolkit (GWT) product development, but, don't worry, we're feverishly polishing up the codebase for GWT 1.4. We've checked in all the source code for the new features, and we'll produce a release candidate once we address all the Critical and High priority issues tagged as 1.4RC.

I know we've been a little quiet lately about Google Web Toolkit (GWT) product development, but, don't worry, we're feverishly polishing up the codebase for GWT 1.4. We've checked in all the source code for the new features, and we'll produce a release candidate once we address all the Critical and High priority issues tagged as 1.4RC.

On the app development side of things, we're really excited to see a new application called QueWeb Customer Care, which is a Customer Relationship Management tool built with GWT; go ahead and play with a demo (you have to register, but it's free). They've done some fancy stuff and the app is still quite fast.

In other news, we'd like to give a warm welcome to Rajeev Dayal and Bob Vawter, two relatively new software engineers on the GWT team. Given logistics, Rajeev, Bob and Joel Webber weren't pictured previously, but we didn't want to leave them out of the fun:

Of course, if you just can't wait to get started, you can always download GWT 1.3. Or if you'd like to throw in a few bug fixes of your own, you can get started on Making GWT Better.

This year, the Google Web Toolkit is participating in the Google Summer of Code. We were absolutely amazed by the turnout. We received over 100 proposals in response to our request for ideas! We wish we could have accepted everyone, but we had to pick three.

This year, the Google Web Toolkit is participating in the Google Summer of Code. We were absolutely amazed by the turnout. We received over 100 proposals in response to our request for ideas! We wish we could have accepted everyone, but we had to pick three.

Here are the students who will be working with the GWT team this summer, and their projects:

  • Aleksey Lagoshin: Sockets for GWT
  • Aleksandar Pantaleev: API Compatibility Tool
  • Tomasz Kolodziejczyk: GWT for Gadgets

The competition was fierce -- we had a really tough time narrowing down the field to those three. Thanks to everyone who applied!

We hope you'll help us welcome Aleksey, Aleksandar, and Tomasz as they get started on their projects. They'll be basing their work on the current version of GWT, and we look forward to adding these exciting features to a future version.

Recently I've been working on some Google Web Toolkit (GWT) libraries that involve JSON and JSONP. While working on this project, I've been reminded just how tricky AJAX can be. It's no secret that there are a lot of people out there who spend huge portions of their lives thinking up ways to steal your data (or worse). Unfortunately, the same cool tricks that let you build AJAX sites and mashups also make it easy to build unsafe web applications. Some of the attacks evildoers have come up with are downright devious!

Recently I've been working on some Google Web Toolkit (GWT) libraries that involve JSON and JSONP. While working on this project, I've been reminded just how tricky AJAX can be. It's no secret that there are a lot of people out there who spend huge portions of their lives thinking up ways to steal your data (or worse). Unfortunately, the same cool tricks that let you build AJAX sites and mashups also make it easy to build unsafe web applications. Some of the attacks evildoers have come up with are downright devious!

One of the key goals of GWT is to let developers focus on their users' needs, instead of on JavaScript and browser quirks. However, the consequences of a security exploit can be serious, so it's important that GWT developers understand how such attacks work, and how to prevent them.

To help get the word out, I've put together an article on my experiences. Eventually we'll merge its contents into the GWT Developer Documentation, but we thought that it was important to get this out to GWT developers rather than wait for the next documentation update.

You can find the article here: Security for GWT Applications. I hope you find it useful; if you do (or even if you don't), please feel free to let me know in the GWT Developer Forum!

Last week, I had the pleasure of visiting the Google Web Toolkit (GWT) engineering team in our Atlanta Engineering office and participating in our Atlanta open house (read about how it went). This was a fun event mostly designed to let the Atlanta community hear about what our engineers are working on in Midtown Atlanta. That is, what we're working on outside of hiring more people.

Last week, I had the pleasure of visiting the Google Web Toolkit (GWT) engineering team in our Atlanta Engineering office and participating in our Atlanta open house (read about how it went). This was a fun event mostly designed to let the Atlanta community hear about what our engineers are working on in Midtown Atlanta. That is, what we're working on outside of hiring more people.

I'm eager to share some photos, which include an appearance by President Jimmy Carter, but before we get to that, let me update you all on the happenings in and around GWT:

  • A few weeks back Bruce gave a well-received presentation at QCon in London.
  • In preparation for the GWT tutorial at EclipseCon, Kelly and Miguel used GWT to build Chattr, an instant messaging app that runs in the browser. The source is posted so that you can play around with it if you'd like to see how it works.
  • Scott and Bret Taylor presented at AJAXWorld in NYC last week.
  • Immediately following the Atlanta open house, Bruce hopped on a plane to join Rajeev at The ServerSide Java Symposium, and gave a presentation.
  • Just a couple days ago, Dan Morrill spoke at the Emerging Technologies for the Enterprise conference in Philadelphia.

Now I'll leave you with a few photos:

(Photo credit: Clark Savage)

The Google Web Toolkit team (from left to right):

  • Back row: Miguel Mendez, Kevin Scott, Toby Reyelts, Dan Peterson, Bruce Johnson, Dan Morrill, Alan Eustace
  • Front row: John Tamplin, Scott Blum, Emily Crutcher, Kelly Norton
  • Not pictured: Joel Webber, Rajeev Dayal
(Photo credit: Clark Savage)

During the office tour, Scott demonstrated a new kind of "diplomacy" to President Carter with one of the GWT team's lightsabers... er... conflict-resolution facilitators.

As we had hoped, GWT 1.3 RC 2 has proved stable and is ready to graduate today, making build 1.3.3 the official GWT 1.3 distribution. If you've been waiting to upgrade to 1.3, it's ready when you are.

As we had hoped, GWT 1.3 RC 2 has proved stable and is ready to graduate today, making build 1.3.3 the official GWT 1.3 distribution. If you've been waiting to upgrade to 1.3, it's ready when you are.

In case you missed the news, GWT 1.3 is the first fully open source version of GWT. Our open source charter, "Making GWT Better," explained that GWT development would take place in the open, and that we'd even publish our engineering meeting notes. We're happy to report that it's working out really well. We've had many fruitful discussions on the contributors forum, and we've already received and accepted some patches that will make it into the next version of GWT.

There have also been a few noteworthy developments in the larger GWT community:

What's next for GWT? We've published our development goals for GWT 1.4 on the GWT project wiki. Please take a look and let us know what you think on the GWT user forum.

We're thrilled with the response to the 100% open source launch last month: lots of people downloaded GWT, the activity picked up on the Developer Forum, and we've received some great advice on the Contributor Forum (which helps make GWT better).

We're thrilled with the response to the 100% open source launch last month: lots of people downloaded GWT, the activity picked up on the Developer Forum, and we've received some great advice on the Contributor Forum (which helps make GWT better).

Now that the holidays are behind us, we've packed up the second release candidate for version 1.3. We expect that this binary will actually turn into the final 1.3 release, but we want to give it some time in the wild before we label it as such. If you're curious to know what's being addressed in 1.3, please look at [milestone:1_3_Final].

As to what's next, for 1.4, we plan to focus on improving performance and cleaning up bugs (especially the critical ones), though we might throw in a few new widgets. This will lay a rock-solid foundation for a feature-packed 1.5.

So, now is the time to act: if you've spotted any issues or have any feature requests, please make sure to enter them into the GWT issue tracker.