Tip:
Highlight text to annotate it
X
>> GLAZER: Hello, everyone. Welcome to, welcome to tonight's campfire. Excited to see everyone
here, it was a fun sort of gathering of the tribe, mingling with people, seeing lots of
people that I tend to see at these kinds of events and more importantly seeing you all
see each and connect with people that you see occasionally, so. It's one of the things
that I like about this kind of events, just remembering that we are a community of developers
and we care about a lot of the same things and it's nice to be able to get together.
Thank you all for turning out on a cold night. I'm a--you know, I was kind of disappointed
it was inside until I stuck my nose outside and then I tried to warm my hands over one
of these fires and realized that a, that this was good idea. I'm Dave Glazer, director of
engineering here at Google, responsible for a bunch of our developer products. One of
the best things about my job is when I get to at events like this, brag about and introduce
and show off the great work done by some of our engineering teams. And I'm going to talk
for a couple of minutes and then get out the way and let the, the product team get up here
and show you what it is that they've been working on with Google Web Toolkit. The last
time we did a campfire and talked to you about some of the features in Google Web Toolkit
was about eight months ago back in April, and the team has been working before, since
and, you know, during and since that, that and enhancing Google Web Toolkit. And we've
been using it a lot internally here at Google. A lot of our product teams here at Google
and you've heard about a few of these releases. You know, at Google I/O back in May, we released
the Wave which was built on top of Google Web Toolkit. Most of you probably know we
did a major new release, a ground-up rewrite of our AdWords Interface which is the place
that advertisers interact and manage their advertising campaign. So, that was done on
top of Google Web Toolkit. We did our--a brand new redo of the Orchid UI which is, which
is incredibly high user traffic, much richer more than interactive UI. You probably don't
know about a couple of dozen other applications that we, Google have built using Google Web
Toolkit because they're internal. We use it, we use Google Web Toolkit all the time for
applications that manage hiring, that manage performance, that manage application distribution
on desktops, lots of through different internal applications that we regularly use the tools
that we build ourselves because we're trying to build the best web apps we can and we like
using the best tools. One of the things that's really good about having internal people use
our tools is we get to see and hear from them when they like what's happening and they like
the tools and they're happy about, with how they make their job easier. One of the other
things about having internal people use our tools is we also hear from them when the tools
could be improved. And one of the refrains that we hear all the time is we found out
that developers are impatient, you know. And developers are impatient because their users
are impatient, because we all want to when we're using software, we're building software,
we want to get things done. And the theme of what we're going to talk to you about tonight
is faster apps, building them faster and faster apps, running them faster. So, you're going
to see the team talk you through a set of enhancements. I'm just going to sort of skim
the highlight to some of the new things that we've been working on, have packaged up that
are now available for all of you to use as part of Google Web Toolkit 2.0. On the side
of letting you develop software more quickly, that's a whole new work-flow around working
with UI that lets us work--lets that process work more quickly. This improved integration
with IDE and there's a much tighter and higher fidelity edit-refresh test, edit-refresh test
cycle which is where all the time gets spent when you're building apps. We also put a lot
of work in to letting the apps themselves be much faster with continuing to take the
Web Toolkit compiler that takes code and squishes it down to be smaller and faster and getting
it to some more squishing and be smallerer and fasterer. Work on start-up of apps so
that you can download just the code you need as you need it. And we're excited to show
off a brand new tool that does performance profiling applications and you'll get to see
some demonstrations of how--no matter how you build the WebApp, you can really get inside
it and understand where it's spending its time and once you understand, you can improve.
So, with that, thank you all very much for coming, excited about to what you're about
to see and I'd like to introduce Andrew Bowers, who is the product manager from Google Web
Toolkit to start walking you through what's new. Thank you.
>> BOWERS: Thanks, David. So, as David said, we've been working with these teams Google
Wave AdWord and Orchid over the past 18 months to evolve Google Web Toolkit, to meet the
needs of modern web applications. And to set the context for what I mean by modern web
applications, just in the past 12 months, a lot has happened in the browser space. The
capability of the browsers continues to increase as HTML 5 moves from specification to reality.
We're also seeing that the places you can run web applications is increasing not just
on the desktop but a lot more opportunities in the mobile area. You could also say it's
an understatement that in that same time period, Java speed--JavaScript speed has increased.
And this is allowing developers to push a lot more functionality to the client that
used to happen on the server. So as these performance enhanced—-you know, performance
increases and capabilities increase, we're seeing much more ambitious applications. And
some of these apps are quiet frankly evolving out of the tools that are--growing out of
the tools that we're used to build them, GWT included. So need to make a few changes, and
we'll walk you through that tonight. Now for those of you not familiar with Google Web
Toolkit, let me just tell you what it is at a very high level, and we're going to talk
about the details in depth throughout the night. It allows you to write an Ajax application
in Java, and then cross-compile the in a highly optimized JavaScript that run across all browsers.
So you have one code base that works across all these browsers. Now if you look at the
development cycle for Google Web Toolkit, you can divide it into two parts, we have
development time and deployment time. During development, you code your application against
the Java APIs and widgets. This is to abstract the way the browser differences so that you
can have that one code base that works across multiple browsers. You iterate in the same
other life cycle that you're used to in the browser with the added benefit of being able
to take advantage of Java debuggers and tools. And when you're ready to deploy your application,
you use the GWT compiler to compile that source to highly optimized JavaScript. Now we're
going to talk about these steps in depth tonight, and we'll talk about the improvements we've
made divided up in these two sides of development and deployment, or really sort of productivity
and performance. So I want to start with the productivity side of the equation, and one
of the features that we learn working with Google AdWords. So many of you may not realize
just how big Google AdWords is. There's a lot of functionality, a lot of features have
been added over the years to meet the advertiser requirements. So when they were looking at
the UI redesign they wanted a way to iterate quickly to test UIs with users and to move
very quickly and use Google Web Toolkit to do that. So we introduced a new feature, a
declarative UI called UI binder. This allows me to write my user interface in an XML template,
drop in widgets into that template, and then, associate or bind those widgets to an associated
Java class where I write my application logic. So it's a clean separation of a presentation
layer and application logic, and allows you to iterate quickly. Now a demo is probably
worth a thousand of these PowerPoint slides so I'm going to show you a very quick example.
It's a small example so I could show you something from scratch. So if we could go over to the
demo machine. Oh, I'm already here. So this is the mail sample that ships to [INDISTINCT]
STK and it's a simple client side Ajax app here. And there's an about dialog box, it
shows up if I click this link. So I'm going to recreate that dialog box using UI binder.
So I go over to eclipse, and then delete the files that are there right now. I hope I won't
delete anything I don't need. And now I'm going to create that new dialog box. And let
see, I've got a mock. Let say, a designer sent me this mock, and I want to incorporate
that in here. So I go over to the clips, then I get to the UI binder wizard, I call the
dialog. Now the wizard is going to create two files for me, the XML template here and
I lay out my user interface, and an about Dialog.Java that's going to contain my application
logic. Now this is just boilerplate code right now so I'm going to change this to dialog
box, and I know that dialog box takes a set widget instead of initwidget, in its constructor,
so I'll change that there. It got two Ts. So I go to about dialog and I'm going to this
mock right here, I've got it opened, and I'm going to take that and copy and paste that
code in. Just paste it in to the template here. One of the other nice benefits of UI
binder is that I can actually bundle CSS style directly into the template. So that has a
few benefits. One, it means I don't have to get fetch external style sheets, one less
round trip. Two, I means that I can take a widget, package it up and use it across one
application in multiple places or across many applications without having to worry about
CSS name conflicts. So I'm going to take the styles here and I'm going to paste this in
as well. Now we could use an external style sheet as well, so we leave the regular way
you would reference a style to reference the internal there is a little bit different notation,
just use some brackets. We can see that's there. Now, I save that, I should be able
to go back here to Chrome, quick refresh and my changes are going to show up. Click on
the about dialogue box and you can see we now have a new dialogue box there. Yes, very
exciting dialogue box, isn't it? So, now you will notice that the close button didn't work.
So, I probably did something wrong or actually, I didn't change that from HTML, so it's still
a button. I want to change that to a widget, so, I can easily go in to UI binder and do
that as well. Remember we said, we could mix HTML and widgets as we wanted to as appropriate.
So, I'll just do that here, call it close. I wan to give it a name because I want to
have a handle to it. I call it close widget. Get rid of this old one. Now I go to the Java
file and I'll create a UI handle for it. And creating event, creative event handler for
it. Creative event handler is actually really easy and UI binders as well. I just annotate
it, I tell it which, which did I want. And then I create a simple event handler. And
I want to hide this dialogue box, so I'll do that. Import that click event, and now
I have an event handler. Notice I didn't have to write any anonymous on requests set up
in any event leisters, just annotate it a method. And we go back to Chrome, click refresh;
we'll have taken that HTML button and converted that into a GWT widget. Then we can continue
to add additional event handlers too. And now the dialogue box closes. So, it's a very
quick way to iterate with designers in your workflow and then also has a very nice separation
between your presentation layer and your application logic. Then the other thing that you've probably
noticed is, when I was in eclipse that I used a wizard to create the boilerplate template
for me and the java file. I also had a co-completion and error checking. So, as we're adding new
features to Google Web toolkit, we're continuing to increase the ID support to the Google plug
in for eclipse. So, what it means in, in UI binder for instance is that, if I have a widget
mismatch or name mismatch between my Java class and my UI.xml template, its going to
flag that for me because remember, we're binding this two together so, I get a little notice
there, you can read it, it says it, has a new corresponding field. Now, we've also done
that for other features as well as we're adding, quickly we go back to slides. And not just
in UI binder obviously, many other things for new features as well as existing things,
so RPC re-factoring, Java script native interface, we've added syntax highlighting for the Java
script and re-factoring there. You can actually re-factor native Java script methods that
are inside your code. The other nice thing is – you noticed that I was in Chrome the
entire time, yet I was editing the Java file and the XML file. Well this is thanks to the
Google web Toolkit developer plug in which allows me to edit those Java and XML files
and continue to work in the browser. But it's not just Chrome that it works with, it's any
browser, any of the major browsers that I prefer so, if I want to work in Safari, if
I want to work in Firefox, but I want to work in IE, its going to work across all of these
so I can debug and test across multiple browsers again, using my same eclipse IE and using
my same machine there. The other thing is that, that obviously means I can use firebug,
I can use inspector, I can use Chrome dev tools, any of those tools that I'm used to.
And one other, sort of side benefit of this I can do it across the network too. So, if
I have a problem in Safari that's on, let's say the Mac next to me, and I want to debug
that, I can stay on my Windows machine; let's say I put DNC on here. Just go over, take
that URL without using the Chrome, drop it into Safari and then hit my eclipse development
environment here stepping through the code in machine that I used to. So, it's really,
really nice way to iterate through the development cycle. Now, so we're talking about these multiple
browsers, these one code base multiple browsers. But it's also not just the web apps in browsers,
so basically anywhere that you have Java script running, you can run a GWT application. So,
let's say you're developing a Firefox extension or Chrome extension, or something from word
press, those can all be applications built with Google web Toolkit as well. So, to show
you that exact thing and someone who's doing that, I'd like to invite out Matt Mastrache
from dots box [ph].