GWT Blog

Introducing Google Web Toolkit 2.0, now with Speed Tracer

Tuesday, December 08, 2009

Earlier tonight, we wrapped up a very exciting Campfire One at which we announced that GWT 2.0 is now officially available. In addition to major improvements in the GWT SDK and the Google Plugin for Eclipse, GWT 2.0 includes a brand new performance analysis tool for Chrome called Speed Tracer. Introducing Speed Tracer We hinted at it a few weeks ago, and now it's available: Speed Tracer is a powerful new performance analysis tool for Chrome that gives you unprecedented insight into the inner workings of any web application — not just those created with GWT. Want to know why your web app feels sluggish? Speed Tracer can help you find the answer. It's fun to see Speed Tracer in action, so here's a quick introductory video...

As an aside, Speed Tracer has a pretty snazzy user interface, eh? It was built with GWT. Faster development, faster apps Here's another quick overview video that highlights some of the cool new features in GWT 2.0...

Now let's talk in more detail about what's new in the GWT SDK and the Google Plugin for Eclipse... Fast edit/refresh with new development mode and draft compiles

GWT 2.0 greatly improves the edit/refresh cycle by introducing a new method of debugging called development mode that allows you to debug your project with the browser of your choice — yes, your browser, not one dictated by GWT. Development mode relies on a new browser plugin, called the GWT Developer Plugin, that makes it possible for your Java project to create a debugging bridge to any browser into which it is installed. Technical details aside, this new way of debugging really just feels right.

By moving your debugging experience directly into the browser, development mode makes it possible to use each browser's own unique development tools in combination with Java debugging. That's right, you can now debug your Java source code in Firefox while simultaneously using great tools like Firebug to view DOM structures and experiment with CSS. Ditto for Safari and Inspector, and so on for other browsers.

The new Google Plugin for Eclipse includes streamlined support for launching and controlling development mode, including a new view that embeds development mode logging messages directly as an Eclipse view. It's also possible to launch development mode manually, which utilizes a Swing-based user interface and can work completely outside the context of Eclipse, including in IDEs other than Eclipse.

Development mode also supports multi-browser debugging, meaning that you can connect to more than one type of browser from a single debugging session. This dovetails especially well with the ability to leave a development mode session running for an extended period of time, allowing you to simply refresh the browser to see the results of changes to your Java source. It's a great way to quickly ensure that your project works properly across all the major browsers without needing to restart the Java debugger.

And, finally, development mode works across a network. Why is that cool? Because you can easily test browsers on operating systems different than the one on which you're developing. For example, suppose you are developing in an IDE on Linux. You can, in a single debugging session, connect across the network to see your app running — and debug it — in Internet Explorer on Windows as well as Safari on OS X. Or Chrome on Windows. Or Firefox on OS X. The point is that you can develop using whichever platform you prefer while still debugging on each of the browser/OS combinations that your users may have.

If you do need to compile to JavaScript often — though hopefully development mode will dramatically reduce your need to do so — you can use the GWT compiler's new -draftCompile flag, which speeds up compiles by skipping optimizations. To be clear, you definitely shouldn't deploy JavaScript compiled that way, but it can be a time saver during non-production continuous builds.

Declarative UI with UiBinder

GWT 2.0 introduces a powerfully productive new way to construct user interface code called UiBinder. UiBinder makes it easy to separate the visual aspects of the UI from its associated application logic. To construct your UI, simply mix HTML and widget elements declaratively in a UiBinder XML template — a .ui.xml file. You can then place application logic in an associated .java file.

UiBinder makes it much easier to involve web designers more directly into the development workflow. For example, developers can copy/paste from HTML mocks provided by a web designer. We've also seen that some web designers like to edit UiBinder XML templates directly and use development mode's fast edit/refresh cycle as they experiment with the UI design. It's a lot more fun to design using interactive widgets rather than passive HTML mocks.

It isn't as if there's a canned set of widgets that can be used with UiBinder, by the way. Incorporating your own custom widgets into a UiBinder template is exactly the same as using any of the built-in widgets.

UiBinder also helps prevent subtle bugs, such typos in IDs, from making it into production by validating all cross-references between the .ui.xml and .java files at compile-time.

The Google Plugin for Eclipse now provides UiBinder-aware wizards, code completion, red squigglies, and refactoring to help you use UiBinder effectively.

Pixel-perfect visuals with layout panels

Getting the exact look and feel you want in your UI is something that has traditionally been tricky with HTML and CSS. Prior to GWT 2.0, even GWT's widgets were not able to fully abstract away some of the layout headaches that can occur. However, GWT 2.0 introduces layout panels that actually do make it possible to reliably create the layout you want. The Mail sample application in the GWT SDK has been updated to show you how this works.

Layout panels create a predictable constraint-based layout system on top of standard CSS. Because it works with CSS, rather than in spite of it, layout panels continue to work predictably in the presence of custom CSS styles that you might need to include. And because CSS-based layout is handled natively inside the browser's rendering engine, no JavaScript needs to run during layout. As a result, layout is fast and fluid — you can especially notice the speed when resizing the browser window.

As you'd expect, layout panels work especially well with UiBinder. With only a few lines of XML, you can create really sophisticated layouts, including animated transitions, splitters, and more.

Compiler improvements

A key new feature in GWT 2.0 is developer-guided code splitting. It's easiest to explain with an analogy: when you're watching a movie online, you definitely don't want to download the whole thing before it starts playing, right? You want the movie to start instantly, and the rest should download incrementally. The same is true for web applications. Starting a web apps shouldn't feel like you're installing something; it should just start instantly when you click on a hyperlink. Code splitting is a very high-leverage tool to help you achieve exactly that.

It may sound complicated, but code splitting is actually easy. Just find a spot in your project where you'd like to chop out some code and use the magic new GWT.runAsync() method to create a split point. By continuing to add split points wherever it makes sense, you can easily and safely slice and dice your application to ensure that the initial download includes only the bare minimum of code necessary to start. The compiler automatically arranges for additional code fragments to be downloaded later. And, unlike manually splitting JavaScript across <script> files by hand, the GWT compiler does the hard work of ensuring that all necessary dependencies are downloaded in the correct order automatically. For an example, see the Showcase sample application included in the GWT SDK, which has been updated to demonstrate code splitting.

In addition to code splitting, there are also fundamental improvements to the compiler's ability to produce JavaScript. With each new release of GWT, we add compiler optimizations to make compiled JavaScript smaller and faster. That's a big benefit if you have existing GWT projects, because you can simply upgrade, recompile, and — poof — your applications start and run more quickly. Indeed, GWT 2.0 includes some high-impact new optimizations, and we have already seen size reductions in compressed JavaScript ranging from 3% up to over 20%.

Optimized resources with ClientBundle

ClientBundle extends and generalizes the resource-bundling pattern that began with ImageBundle in GWT 1.4. With a simple interface declaration, you can at compile-time optimize and embed resources directly into your compiled JavaScript. For example, by bundling images, you can avoid costly HTTP round-trips. ClientBundle supports bundling a wide variety of resource types, including images, text, and even CSS.

You heard that right, CSS. CssResource is a powerful new framework for managing styles. It supports a new extended CSS syntax for defining sprites, named constants, scopes, conditional selectors, and more. It also aggressively optimizes your CSS by stripping comments and whitespace and by obfuscating class names.

ClientBundle is also extensible. You can create your own resource types and hook into the ClientBundle framework to keep resource interfaces coherent and succinct while bundling any sort of resource you can find a use for.

Special Thanks GWT 2.0 is the culmination of many months of collaborative development, and on behalf of the the entire GWT team, we'd like to thank the WebKit team, with whom we've worked closely to add the low-level instrumentation necessary to make Speed Tracer possible. And, as always, a huge thanks goes out to the GWT developer community, many of whom have bravely followed the tip of the GWT trunk in svn, trying out new in-progress features and helping find bugs — and even submitting patches to fix them. Get Started Believe it or not, we've still only scratched the surface of what's new. As always, GWT is open source and free to use. We hope you'll give GWT 2.0 a spin. Download Google Web Toolkit 2.0 Happy coding! See you online.

New insights into web application performance

Wednesday, November 04, 2009

I've sometimes thought that optimizing web applications is as much a science as dowsing. (No offense intended, dowsers of the world — but you have to admit it's a hard thing to explain even when it does work out.) Even when you are completely willing to invest time and energy into optimizing an application, how do you actually go about it? Our team, along with everyone else in the world who cares about web application performance, has had to essentially guess at where time goes inside the browser. We've spent countless hours debating each others' wild-eyed speculations as to the true sources of latency afflicting a wide variety of applications. Indeed, web apps can be slow for all sorts of opaque and unintuitive reasons. Don't be fooled into thinking that bloated, slow JavaScript is the only culprit. We've seen pathological situations in which a few seemingly insignificant CSS tweaks can improve performance by a factor of 5 or more. Another dark gem: rearranging a mere few lines of JavaScript that were inadvertently calling DOM-related methods in an unfortunate sequence (which caused multiple redundant layouts) turned a life-negating 5 second operation into a sprightly 50 millisecond blink of an eye. That one took 5 days to find the offending 4 lines of JavaScript and then about 3 seconds to actually make the code change. #nowiamwaybehindingooglereader We couldn't take it anymore. We decided we had to find a way to transform the witchcraft of optimizing web apps into a legitimate engineering task, once and for all. My team began working on a series of changes to WebKit and Chrome to collect precise metrics on where time is, in fact, going within the browser. When, exactly, does layout occur? How long does each layout take? Can layout happen synchronously while my JavaScript is executing, or is it deferred? How much time is spent on CSS selector matching? How long does parsing (versus executing) JavaScript take? Does the process of actually painting pixels on the screen take much time? We instrumented the browser way deep down inside to produce a stream of such metrics, being very careful to keep observer effects to a minimum. Happily, we've managed to land these changes into both WebKit and Chrome over the last several weeks. Soon you'll see the first examples of tools that make these metrics available to web developers using WebKit-based browsers. Of course, we have a lot more instrumentation planned, but the ball is really rolling now thanks to lots of help from the friendly folks on the WebKit and Chrome teams (especially Pavel Feldman and Timothy Hatcher). We've gained many new insights, some of which I mentioned in my Measure in Milliseconds talk at Google I/O earlier this year. When you see these metrics yourself for your own web apps, you'll likely be surprised — and you'll almost certainly wonder how anyone tried to write high-performance code without this sort of insight. Be sure to keep an eye on the Chrome Dev Channel and the WebKit nightly builds for new Inspector features based on our work.

The enterprise (apps) in your pocket

Monday, October 19, 2009

send me an emailSocialwokhttp://socialwok.com/

http://app.socialwok.com/

1. Think about the devices you want to support.user.agent.gwt.xml<set-property name="user.agent" value="safari">
Of course, during development we enjoy GWT's quick edit-refresh-test model thanks to Development Mode (formerly Hosted Mode) which lets us test our code in a real browser while executing and debugging in Java..menuPanel { width: 100%; \-webkit-transition: opacity 500ms ease-out 100ms;}here2. Optimize for the screen that your users are using.VerticalPanelFlowPanel

3. Share as much code as possible between versions.JavaScriptObjectThis pageGWT profile on Socialwok on YouTubeImmutableResourceBundleClientBundledata:CssBundleFlowPanel tags. Layouts also seem to be more predictable with these tags than the others on the mobile phone.

GWTQuery - Ray Cromwell's excellent port of JQuery to GWT provides most of the JQuery functionality to allow you to modify CSS, and perform other actions with ease. In the case of the mobile web interface, there are times when it is definitely necessary to modify CSS dynamically, and this library will make that process much easier on you as a developer.

GWT Google APIs (Gears) - Google Gears is a browser plugin installed in the Android Web Browser used to provide extra functionality, particularly offline support which is very import for mobile browsers which don't always have a permanent connection. Google provides a GWT library that can be used to access the Gears plugin.

-- Navin Kumar, CTO, Socialwok

Building Enterprise web apps in the cloud

Thursday, October 08, 2009

An important decision to make when building a web application is how to coordinate state between client and server. This includes how to create appropriate representations of your data to send over the wire.

There are many possible approaches. I'd like to present a straightforward one from Jerome Breche, CEO of TimZon, who was kind enough to share it with us today.

When we started our first GWT project (TimZon.com), we found out that one of the major benefits of using GWT is its ability to transfer complex object data structure between client and server through the RPC mechanism. So when we initiated our second project (SnapABug.com) combining GWT and Google App Engine, we were very excited by the prospect of passing datastore objects directly though RPC.
We quickly realized that this is not very practical. First one of our JDO objects includes images binary representation that we wouldn’t want to communicate through RPC. And then while making the JDO class serializable for GWT RPC may seem like a simple task, it created all kind of new problems since the JDO class will have to be configured as transient (using detachable = "false") and we would still need to copy the object when passing it through the RPC. Instead we decided to simply create intermediary classes for the data objects used only for RPC communication. This way we can exactly control and optimize the data payload used by the RPC both for size and speed. On the JDO side, we simply created a getter and setter function to translate the JDO data into an RPC data format.

Here is an example of how this works in client side code.

1. Employee class: contains JDO objects definition and getter and setter to translate them to GWT RPC serializable format
@PersistenceCapable(identityType = IdentityType.APPLICATION) public class Employee {
@PrimaryKey @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY) private Long id; @Persistent private String name; @Persistent private String email; @Persistent private Blob image; /**
* Constructor * @param name * @param email */ public Employee(String name, String email) { this.name = name; this.email = email; } /** * Set Employee from RPCDataEmployee */ public void setRPCDataEmployee(RPCDataEmployee employee) { name = employee.name; email = employee.email; } /** * @return Employee data in RPC format */ public RPCDataEmployee getRPCDataEmployee() { RPCDataEmployee employee = new RPCDataEmployee(); employee.name = name; employee.email = email; return employee; } }

2. RPCDataEmployee class used by GWT RPC calls

public class RPCDataEmployee implements IsSerializable {
public String name; public String email; // Note: image Blob not included in RPC payload }

Here is an example of how this works in the server

3. RPCDataEmployee server service implementation
public RPCDataEmployee getEmployee(String email){ RPCDataEmployee employee = new RPCDataEmployee(); // create data store connection PersistenceManager pm = PMF.get().getPersistenceManager(); // query datastore to get emmployee data String query = "select from "
+ Employee.class.getName()
+ " where email == "
+ email;
List employees =
(List) pm.newQuery(query).execute();
if (employees.size() == 1) { // record found employee = employees.get(0).getRPCDataEmployee(); } else { // do something else... }
pm.close();
return employee; }

While I am sure there are many other ways to achieve a similar result, maybe even avoiding duplicating the data classes, this solution was the easiest for us to get going quickly, keep our code very maintainable and control the amount of data exchanged between client and server.
There is also a very interesting discussion about this subject on the GWT Google Group.

-- Jerome Breche, CEO & Founder of TIMZON, LLC

If you would like to share your experiences with GWT and Google App Engine, either privately or on this blog, I'd like to hear from you.

Making AJAX Crawlable

Thursday, October 08, 2009

Search Marketing and Expo East ConferenceGoogle Webmaster Central Bloglet us know your thoughts

GWT helps developers innovate in the enterprise

Monday, October 05, 2009

TechCrunch50 Demopit winnersSocialwokGoogle AppsGoogle App EngineGoogle Web Toolkithere

Riding the Google Wave

Wednesday, September 30, 2009

began inviting the first 100,000 users to preview Google Wavemake Google Wave a realityGoogle Wave Backstage - Q&A with Dhanji Prasannamission statementdeveloper productivity and user performancemuch to dodeveloper previewsamplesGoogle Wave API Documentation

Web Toolkit Blog