Code splitting is one of the features of GWT that make it worth your while.\u00a0 See, using GWT is really a choice–do you want to use one of the lightweight javascript libraries like jquery, with all the agility that implies, or do you want to use GWT which lets you leverage all kinds of java tools and optimizations, but saddles you with a compile cycle?<\/p>\n
I’ve talked before about the situations that I think are good fits for GWT<\/a>.\u00a0 I just re-read that post and don’t feel that things have changed too much in the past 3 years, though I might argue with point 4 of that post.\u00a0 Code splitting<\/a> is an optimization that would be hard to do with a more normal javascript library (dojo has something like it, but it looks like you are responsible for maintaining dependencies<\/a>).<\/p>\n I talked before about code splitting, and how it is a great fit<\/a> for the widget based html enhancing GWT development that I’ve done a lot of recently.\u00a0 I wanted to talk a bit more about my process for finding code to split.<\/p>\n With code splitting, the main goal is “never have the user download javascript that isn’t used”.<\/strong><\/p>\n The first thing to do is run your GWT compile with the -compileReport option, as outlined here<\/a>. This will show you your module code, and therefore let you focus your effort where it makes sense.<\/p>\n The second thing to do is to find code dependencies.\u00a0 The compile report shows you that in a text format if you navigate all the way down to the class level in a class that is downloaded in the inital fragment via the “see why” link.\u00a0 I had a hard time understanding those dependency lists, so I went looking for a tool to help.\u00a0 After trying a number of open source dependency analyzers<\/a>, I stumbled on the Class Dependency Analyzer (CDA)<\/a> which is free as in beer, not as in speech.\u00a0 The key difference between this tool and others was its included dependency graphs<\/a>.\u00a0 You should set CDA up to ignore all the google code, as well as any third party tools you have.\u00a0 More documentation on CDA here<\/a>.\u00a0 (This is another example of leveraging java’s tool set.)<\/p>\n Using CDA, you can see which packages (since modules are grouped in a java package) have dependencies on others.\u00a0 Packages that don’t have dependencies on any of your other packages are great candidates for code splitting, as well as packages that depend on other packages that are code split.\u00a0 However, if your packages depend on utility classes, especially those that share business logic between client and server side code, that’s OK.\u00a0 (This exercise can also help in general code quality.)<\/p>\n Now you have a number of candidate modules.\u00a0 The next thing to do is dive into the code and see if these modules execute on every page.\u00a0 If they do, then doing code splitting is not a win.\u00a0 All you’ve done is forced GWT to make an extra network call.\u00a0 If, on the other hand, this code only executes when someone clicks a button or takes some other action, then you have a great candidate for code splitting.\u00a0 And if the module only executes on certain pages (perhaps using a DOM element to signal whether it should execute or not<\/a>), you have a good candidate–because with splitting that code will never be download on pages where it is not used.<\/p>\n Now, add the following code around the candidates:<\/p>\n I actually added this code block to my eclipse templates ( more on templates here<\/a>) so it is super easy to set up a split point.\u00a0 Note that I haven’t found a generic good action to take on failure.\u00a0 For most widgets providing enhanced functionality, a safe fallback might be to just let the HTML execute.\u00a0 A custom message display might be ignored, and using The next step is to run the compile report again and see if the GWT compiler agrees with you that your candidate code is not reachable by any other path.\u00a0 If it does, you should see split points show up underneath the permutations menu.\u00a0 (BTW, the -compileReport flag easily doubles or triples the time it takes to compile GWT–I’d recommend focusing on one user-agent and doing other things to speed up your compile, as outlined here.<\/a>)\u00a0 You can also test this by just compiling your GWT without the -compileReport switch and looking under the deferredjs directory; it is quicker but doesn’t help you determine which modules are being downloaded.\u00a0 Firebug also lets you see the files downloaded on demand.<\/p>\n I was able to decrease the initial download size of a project I’m working on by 20%.<\/p>\n I’ve mentioned the caveats before<\/a> but they are worth mentioning again.<\/p>\nGWT.runAsync(new RunAsyncCallback() {\r\npublic void onFailure(Throwable caught) {\r\n\/\/ handle error\r\n}\r\n\r\npublic void onSuccess() {\r\n\/\/ do something\r\n}\r\n}<\/pre>\nWindow.alert<\/code> can confuse your users (and lock up a browser for a time if all of your code or the network suddenly becomes unavailable).<\/p>\n
![dependency graphs<\/a>.\u00a0 You should set CDA up to ignore all the google code, as well as any third party tools you have.\u00a0 More](\"http:\/\/www.mooreds.com\/files\/samplegraph.jpg\"){kind=link}