If you are writing a typical GWT application, which is monolithic and controls the entire viewport of the browser, you probably don’t want to read this post.  Go on, read something else interesting–you probably have emails or tweets or something better to do with your time.

OK, now we just have the people left who are using GWT to build widgets; that is small encapsulated pieces of functionality that integrate into an existing web based application (case #2 outlined here).  If you’re doing this, and you use the “span to enable” gwt mini pattern, you want to upgrade to GWT 2.0 simply to get the new code splitting functionality.  If you don’t want to read that previous link, the synopsis is that code splitting lets you define a number of pieces of distinct code, using GWT.runAsync.  Then, that code won’t be downloaded until it is reached.

Previous to this feature, if you had a number of widgets, you ended up with a large chunk of code to download on every page (this is an issue with GWT that the monolithic applications simply don’t have to deal with).  Some of that code will be run.  Some will not, but you’re still paying for download and parsing of that code.  You had some unsavory options to deal with this–let all the code be downloaded, or manually split up code into separate modules that you managed (either by hand or with deferred binding).  The second solution led to smaller downloads, but meant a lot more management–if you wanted to add a widget to a page, you not only had to add the enabling span, you had to recompile the entire GWT module–and much longer compilation when you deployed your entire web application.  However, if your widgets were static, this path might have been an option.

My client used the former solution (entire code download on every page), and was very excited about the code splitting, since that essentially automates the second choice above.  In the space of about one half hour, I was able to reduce the initial download size of the GWT javascript by 10%, and there’s scope for much more, since the code is pretty naturally split up into separate chunks for each widget.

It’s not perfect, however. The two concerns I’ve had so far:

  1. The XS linker is not supported.  This means that if any of your widgets need to be cross domain, you need to create an additional module specifically for that.  For example, if I have one module, A, which is used to start up all the widgets on the site, and inherits from both module B, which has some GWT code split calls, and module C, which needs to be cross domain, the compiler will error out when compiling module A.  I need to create a second module XSModuleC which inherits from module C and is compiled by the XS linker, and then use that module for all cross domain purposes.
  2. If you call GWT.runAsync from an event handler, like onClick, you will not have a valid event on the first call (when the module is loaded) but will on all subsequent calls.  This is easy to fix, but was a bit mystifying to me.  Basically, if you have code like this:

onClick(ClickEvent event) {
if (event.getSource() instanceof Image) {
// do something with image
}
}

you need to replace it with:

onClick(ClickEvent event) {
if (event.getSource() instanceof Image) {
// save event.getSource into an instance variable
GWT.runAsync(new RunAsyncCallback() {
// do something with image in instance variable
}
}
}

I'm sure there are other complications I'll find once I do more code splitting.  (Here's an interesting post about code splitting in large applications, and simplifying the API of code that is split (plus, you get to see the word cromulent in context).)  But, for now, code splitting and GWT widget development seem like a match made in heaven.

Technorati Tags: ,

Subscribe to my newsletter to get new blog posts in your inbox.

One thought on “GWT widgets and code splitting, a match made in heaven

  1. moore says:

    Note that issue #1 is going to be solved in the GWT 2.1 release.

Leave a Reply

Your email address will not be published. Required fields are marked *


one + 1 =

 


© Moore Consulting, 2003-2014 +