Google I/O 2012 – The History and Future of Google Web Toolkit

>>Ray Cromwell: Hi. Good afternoon. Welcome
to the history and future of Google Web Toolkit. My name is ray Cromwell, I’m tech lead for
GWT. So I’d like to just jump right in because we’ve got seven years, believe it or not,
of history to cover. So, often people actually come up to me and
say why did Google even create GWT in the first place? Isn’t JavaScript good enough
for you? Why do you need Java for Web programming? So I think it’s instrumental to go back and
look at the context in which GWT was conceived seven years ago. So if you think back seven
years ago, which is an eternity in Web time, Web 2.0 was just starting, AJAX apps, rich
internet applications were just being created, the first sort of series of them. And people
were actually thinking back then that the future of rich internet applications was going
to be something like a war between Adobe Air and Microsoft Silverlight. I mean, there were
conventions on this. And people did not think that the browsers were powerful enough to
do really, really capable applications. And then Google released Gmail in 2004 and
Google Maps in 2005, and I think that started to change people’s imagination because for
the first time, especially with Google Maps, people saw an application that was written
in the Web that was fast, it was fluid, it was — in fact, this was before touch. It
was touchable. The way you interacted with the Google Maps application is you grabbed
it with the mouse pointer and flung the map around. So that fired up people’s imagination
and people really wanted to start building rich Web applications like this.
But at the time if you looked around and surveyed the landscape there wasn’t a lot of good tools
to do this in just raw JavaScript by hand. In fact, jQuery, which is really the most
popular library out there, wasn’t even released until 2006. And I think probably Bruce Johnson
and Joe Weber who created GWT were sitting around somewhere in a cafe and saying How
can we solve this problem without building our own JavaScript bidi, JavaScript testing
frameworks and build servers and all this other kind of stuff that’s been there for
a long time. And if you look at Java they were like wow,
it has seven million programmers, it has intelliJ and Eclipse, it’s got Ant and Maven and it’s
got J Unit and Test Mg and it has bug analysis software and dependency package management
and all this stuff. The only thing you can’t do with it is you
can’t write a client side Web application except if you want to do applets or something.
If I could only compile Java to JavaScript it would close the loop and we would get massive
leverage on that ecosystem. So that I think was the foundation context for GWT.
So it’s evolved a lot since then. The first version of GWT was released in 2006, followed
very shortly by a few other versions that really didn’t add much to fix bugs. The really
important thing is with GWT 1.3 in 2007 early on we released it as open source. And for
the first time everyone could contribute to GWT if they wanted to. And it was also the
first to get OSX support. Later in 2007 we added J Unit testing framework
support as well as automatic sprite sheeting. This was another first because back in 2007
we were automatically creating CSS sprite sheets on the fly well before actually people
had built tools to do this for hand-coded JavaScript. But the biggest thing people were
asking us over and over again is when are you going to have Java 5 support? We want
generics, we want enoms, we want auto boxing, all that stuff. So they did a fire drill,
they crunched down and in 2008 they got Java 1.5 support. In fact, 1.5 was one of the biggest
releases. It added not just Java 1.5 support, but this new overlay type system that allowed
you to link with JavaScript for the first time with zero overhead in the compiler. It
had a new low level DOM API, and we added CSS themes to the widgets for the first time,
so everyone who used GWT early on knew that the widgets no style whatsoever. Out of the
box it just looked like nothing. So we added a couple of CSS themes so at least out of
the box someone could actually look at the app and not puke.
[ Laughter ]>>Ray Cromwell: And we added this thing called
linkers which has some useful things that I can perhaps get into later.
And with 2009 we basically redid the event handler system to make event handling more
generic and not just tied to the DOM. Now you could fire custom events and reuse events
on both the client and in your server code. We added code coverage support with Emma.
We added war directory support so you could just point our tools at a war directory and
it would work. And we added a parallelized build system that today is mostly used by
Google. In 2009 we had a minor release that mostly
just added support. 2009, though, was the year of a really big release, and that was
GWT 2.0. And GWT 2.0 was an overhaul. It was the biggest release ever. We added a totally
new dev mode so that you could develop in development mode with any browser you liked.
So whether it was Chrome or whether it was IE, whether it was Safari, Firefox, you had
the same experience. Previously we were bundling a really old version of Firefox or IE directly
into the GWT toolkit, so you couldn’t even upgrade the browser you were developing with.
We added draft compilation to speed up your compiles. We added this new templating system
called UI binder. We added layout panels for really efficient CSS style layout. And we
added the code splitter, which was an overhaul to compiler to allow you to tell the compiler
that certain pieces of code don’t need to be loaded when your app starts up, but they
can be loaded later. And a new system for bundling resources into your application,
which was called client bundle, which was the evolution of image bundle, which did sprite
sheets. With client bundle we also bundle in CSS and we have a CSS compiler that performs
optimizations on the CSS to shrink that down as well.
In 2010 we partnered with VMWare to support their cloud, and that necessitated a new RPC
system that was not as tied to Java as GWT RPC was, and that was request factory, which
was a more JSON oriented RPC framework. We did data binding with the editor framework.
JSR 303 bean validation support, model view presenter pattern support, and a new system
of cell widgets which are efficient widgets for rendering like tables and grids.
Then we had a couple of minor releases. We acquired this company called Instantiations
and we released as open source WYSIWYG designer for GWT UIs. We added a lot of HTML5 support,
like canvas and storage and things like that. And we dropped in a little bit of stuff for
Google in terms of enhancing app integration. And then finally, in the last release we sort
of started to think that we need to move off Ant and get more towards Maven, so we sort
of Mavenized it. So that’s where we were. That’s the history
of GWT. So where are we today?
Well, as far as we can tell the SDK has been downloaded over a million times, but that’s
probably not an accurate number because a lot of people are getting it from Maven central
now. We have over 100,000 monthly active developers. Because software basically periodically checks
to see if there’s a new version to give you a notification that GWT 2.5 is available.
So we at least know of Eclipse users there’s 100,000 active developers. We have deep integration
with Eclipse through the Google Eclipse plug-in with intelliJ and with VMWare spring tools.
And our products are used widely within Google, including our biggest product, which is AdWords,
Google Flights, Offers, Google Groups, Blogger, many that you haven’t even imagined that were
written in GWT. And we did a couple of fun things. We ported
Quake, first-person shooter in 2009 using GWT to the Web and it ran smoothly at 60 frames
per second in a browser, and Angry Birds for the Web, if you’ve ever played for Chrome,
is written in GWT. So GWT today is a mature, high quality code
base. What more could we do? Is there anything left
to actually do to improve GWT? And I’m happy to say over the last year we’ve
done a lot. In fact, the GWT 2.5 release that we’re introducing today is the largest release
we’ve done, I think, since GWT 2.1. We’ve added more stuff in 2.5 than we did in 2.2,
2.3, 2.4 put together. Let me go over a few of them. First, we did
a lot of work on the compiler. So out of the box with no changes to your code, if you just
recompile your application you will get a substantial code size reduction.
For example, the showcase application, if you just recompile the GWT 2.5, 14% smaller
JavaScript. And that is undercounting because the GWT user library has added a lot more
bloat in terms of the underlying library code. So it probably would have been even smaller.
The mobile Web app, eight percent smaller. Your mileage may vary. The larger the app
probably the better the benefit. Smaller apps, smaller benefit.
But we can do better. We also integrated the JavaScript closure compiler that is used at
Google for like Gmail and Google+ and Google Docs and a lot of other large JavaScript applications.
And the closure compiler has a lot of really low level JavaScript optimizations that we
never really would think to do in GWT because it’s Java oriented, things like putting bang
zero instead of true or if you have a number like 10,000, rewrite it as 1E4 in scientific
language. It saves off two bytes. So here you can see if you enable closure
compiler you get an extra five percent co-size reduction. So now versus GWT 2.4, recompiled
with the switch closure compiler, we’re 20% smaller than GWT 2.4.
But we can do better. We’ve also looked at the code splitter and so the showcase application,
for example, does a live code splitting. If you’re not aware of what code splitting does,
it allows you to pick parts of your application, like a composed window or settings page, that
may not be displayed immediately when your application is loaded up. You can mark them
as split points that the compiler has the option of deferring and loading later. So
it can move that code out into a separate JS file, shrinking the initial size of the
JS that has to be loaded. So any bit of code that is exclusive to one particular fragment
and is not shared is called exclusive code. What I’m showing up here is there’s split
points. They have some code that is only referenced within those split points, and if there is
some like, let’s say, job util list that both of them use, and so any time there’s shared
code we put that code in a shared fragment called the leftovers fragment.
Here’s the problem. As you continue to increase the number of split points in your application,
the probability of there being shared code between any two split points rises. And what
that means is that that leftovers fragment at the bottom gets larger and larger. So when
your application loads up, before it can run any of these split points it has to load the
leftovers fragment because it’s a shared library. So we needed to do something about that leftovers
fragment. What we do is we perform a kind of clustering.
We analyze all the fragments that you’ve split out and looked for ones that are most similar,
that basically use the most amount of code together, and we merge them into one fragment.
And hopefully there’s a lot of shared code that no longer is used by anybody else. It’s
only used now within that new merged fragment that you see in the middle of the screen.
That leaves the leftovers fragment down at the bottom empty where we’ve hoisted some
code out of it into this new shared fragment. So what can of effect can this have on an
application like Showcase? 39% reduction in code size of the initial JavaScript that your
application has to load before it can present the UI to the user.
The first time I saw this I thought we had a bug in the compiler and it was wrong, it
was removing too much code, but I’ve measured it several times and it’s true. 39% code size
reduction. But there are other things we had to do. We
had to improve the overall diagnostics of the compiler. Things that you might rely on
like if someone is running your application and a user hits an exception, how are you
going to find out what happened and what line of code it happened on?
So there’s this new standard that Google has proposed and other people have adopted called
source maps. What it does is whenever you compile anything to JavaScript, be it Java,
Closure, Coffee Script, whatever, we write out the standardized mapping file which says
this piece of Java or Coffee Script or whatever source language became this bit of obfuscated
JavaScript in the output. But having that bidirectional mapping, now
when you go to debug or inspect obfuscated compiled JavaScript code, it can actually
tell you the original line of code that it came from in your source language before you
messed with it. So this permits de-obfuscation of script,
but it allows GWT, more importantly, to construct perfectly accurate stack traces.
So right now today if the user encounters like an exception in one of the GWT applications,
you get the line number of the method, the name of the method that it occurred in, but
you actually don’t actually get the actual line number of code within the method that
it occurred on. And in fact, if the compiler has inline several
methods and rolled them up into one, you actually don’t even know what method it occurred in
because now those small inline methods are not even on the call stack. They’ve been basically
moved in to the parent caller. Not so with source maps. Now you will actually
know the exact original function, regardless of optimizations, where the error occurred.
It’s Chrome only for now. Firefox has demoed it and they promise to support it.
Okay. So this kind of dovetails into super dev mode because it’s what enables it. But
here’s the problem. Over the years people have complained we haven’t kept our dev mode,
C++ plug-ins up to date. Basically we use these native plug-ins that
we install into the browser so that when you run in dev mode and it’s running Java code
and it has to remote control the browser and tell the browser add a DOM element somewhere,
it talks to this plug-in, which then remotes controls the browser to actually update the
browser. The problem is that the browser vendors have
accelerated their iteration on their browser. Used to be they would release a browser once
a year, Firefox 4, 5, it would take a year. That would give the GWT team more than enough
time to actually update three or four different plug-ins on three or four different operating
systems. But now we simply can’t handle it because every six weeks they’re releasing
a new version. Like, for example, every time Firefox releases
a new version of Firefox it breaks the C++ plug-ins that we have.
So we needed a new solution. Plus on things like mobile devices like iOS you can’t even
have plug-ins in the browser, so how would you debug a GWT application on an iPad?
So what if we could create a GWT compiler that was so fast we could compile your Java
code in one second? Biggest complaint we get is the compiler is slow. So what if we could
speed it up so we could compile your code in one second or 10 seconds? Then you could
actually iterate by loading up JavaScript into their browser. And with the combination
of source maps, you actually could debug source level Java code right in your browser.
So let me show you a demo of that. So I’ve got the GWT code server running, which is
the new super dev mode server. It’s a servlet. It starts up on your GWT module and basically
it’s waiting there for me to connect. It’s going to serve up the compiled code.
So I’m going to go to this application I have called Silver Comet, and hopefully I’ve got
a network connection and it can load up. I might be in trouble here. If that doesn’t,
what I’ll do is I have another version. Here let’s do this.
I’ll just skip ahead for a second and I’ll come back to that and show it to you.
All right. Let’s let that go for a second. Okay. There it is.
So this is an application, it’s graphing marathon data from the Silver Comet half-marathon in
Atlanta. You can see I can do things like I can hit a character, click on a person,
it tells me where the runner is. If I were to try to debug this today, I would
bring up the Chrome inspector and I go to scripts. You can see that it’s basically compiled
JavaScript. So it would be really hard to like set a break point in here and debug it.
So let’s go down to here and click on this little — in the Chrome inspector this little
gearbox and say enable source maps. So now I’m going to click this — I’m going to go
back to the code server and I’m going to drag this bookmarklet up here and I’m going to
turn on super dev mode. So hopefully it’s going to reload. I think
my network is having problems. Okay. There it is. I’m going to click super
dev mode, click compile. And it’s compiling. And usually this takes like less than two
seconds, but network is loading already, so it’s already finished, but it’s loading on
the bottom. There we go.
Now it’s reloading the compiled JavaScript. It’s already been compiled at this point.
I go over to this window over here and I can probably show you compiled in 0.979 seconds,
if you can see that. So the issue is there is some kind of network
thing that’s hurting my demo here. Let me bring up the inspector and see if I
can show this to you. Oh, there it is. So it’s back up. I’m going
to go to the scripts tag now, scripts. Now you can see I have Java code in here.
[ Applause ]>>Ray Cromwell: And I promise you it won’t
take this long when you actually do it on your own computer. I’m going to go and I can
set a break point here. See that? And I will come up here and hit a character and you can
see it doing a break point. I can hit play and you see the things up there? So I’m stepping
through Java code. In fact, you can do something in super dev mode that you could never do
in regular dev mode. I’m going to step down into a JSNI function. I’m going to step into
this item shell, step into remove property, JSNI JavaScript function. You could never
do that before in regular dev mode. [Applause].
So let’s go back to slides. Okay. UI binder. If you use UI binder we have more good news
for you. First of all, if you sell widgets, you can
now actually — you don’t have to write Java code, you can actually specify the template
for a cell that renders in a table grid or in a tree with a UI binder template. There’s
sort of a new interface called UI render and it does that.
Secondly, we have optimized the way UI binder constructs the HTML and injects into the page
significantly. We have vastly reduced the number of DOM operations down to just a few.
The end result of that is start-up latency for Orchid, which also uses GWT was reduced
by 20%, and the rendering speed it was taking to refresh the HTML on the page went up by
300%. So not just the compiler has been improved, but the speed of the widgets has been improved
up to 300%. And we’ve also started the beginnings of adding
support for using the same I 18 and message class used on the client side in the server.
So using GWT.create in the server, and what that will get to is sometimes you want to
share code between the client server in terms of internationalization resource bundles,
this will basically get you there eventually. And we have updated the ARIA library support
in the GWT to the newest W3C standard. If you have accessibility concerns, we have better
support for that. Lastly, we’re introducing a new experimental library called Elemental.
So what is Elemental? Well, over the years, as I said, the browser vendors are iterating
faster and faster, every week they are adding a new HTML5 API into JavaScript. And we just
can’t keep up hand wrapping those APIs, so every release, GWT 2.2, 2.3, 2.4, we added
a few. We added canvas and then we added local storage, an index database, so on.
But there’s just too many. We can’t keep it up as a manual process.
So what Elemental is, it’s a library that builds a complete 100% HTML5 mapping to the
latest Chrome, WebKit and soon Firefox, by actually looking at the C++ source code definitions
for the JavaScript run times used for exporting their APIs and auto generating a complete
set of GWT classes that directly call into those APIs, look, it’s all done — I’ve got
a typo in there — with JavaScript overlay type. So when you compile this, they all melt
away, it’s a small or smaller than you could write by hand. There’s no overhead. Every
API you could think of is there, WebGL, Web audio sockets, RTC, even Web Intents, Shadow
DOM, these new things that you might have just seen at the show today. We have a new
set of collection classes that you can use as an alternative to JavaScript util collections
that are mapped directly to underline JavaScript collections, so there’s no overhead if you
use like maps or arrays, no extra bloat. And a new JSON library, similarly that has no
overhead if you use it, just directly access JSON objects and no bloat in the output. I
think this is an excellent library for doing mobile device development because the mobile
device browsers are often on the bleeding edge of CSS3 and things like that because
that’s how they get their extra performance. So it could also work for desktop. But you
might have the — already using the existing stuff, so you will have to decide whether
or not you want to move over to this library. But try it out. I’m going to show you a demo.
Real quick. And I cooked up sort of a hack to show you the power of super dev mode and
to show the power of Elemental. And so what I have done is I’ve built this
servlet filter that if you try to load up an HTML page and if you have something in
there like this … I’m going to type a script tag. I’m going to say type the SQL to text/
— no, not JavaScript, Java. And in here, I’m just going to write like I would write
JavaScript. Window.alert. Hello. Believe it or not, that’s Java code,
not JavaScript. So I have a servlet filter, when this file is being piped out will catch
that script tag and see well, that’s Java code, automatically synthesize a GWT module
entry point on the fly, right into the super dev mode compiler, compile it in one second,
then replace it back with a regular script type, text JavaScript, and then the page loads.
And so — so my computer is kind of slow on a real computer — if I would upgrade my computer
it would run a lot faster, but I will show you that right now. Let’s see — if I just
write some code there, and it’s — oops. Wait. Okay. Is it running? It is running. Okay.
Demo problems again. Oh, that’s because it’s on my local machine.
That would make all difference okay. Let’s let that load. There you go.
[ Applause ]>>Ray Cromwell: So now you can develop — if
I were to release this servlet filter, you can actually develop Java code in a really
lightweight fashion, where you can have multiple HTML pages and just sprinkle a little bit
of Java code in each page a page at a time and just get a little tiny bit of compiled
Java code out of it. Well, why would you do that?
Well, simple. Any of you know by heart the new Web RTC camera API? I sure don’t. There’s
a lot of APIs in HTML5. But because this is Java, this is my Java IDE, you know, I can
do things like this, you know, window — this is the Elemental library — .getnavigator
or .get — you see all of these APIs in geolocation, platform plug-ins, product, I can do WebKitgetusermedia,
which is the new Web RTC API to access the camera.
So you can get full completion, all of the normal stuff that you love in your IPE, but
with the sort of lightweight HTML programming experience. So let’s try that out and see
if that works. Going to take a second to recompile. And hopefully
this works. There you go. [ Applause ]
>>Ray Cromwell: So try this out, it’s experimental, but it has a lot of cool APIs in it to try
out. Okay. So you have seen the past, you have seen the
now, let’s talk about the future. So one of the problems that’s been happening
over the last year or so is that ability to iterate on GWT by taking outside community
contributions has slowed a lot. The reason why, it has been paradoxically due to GWT’s
success within Google. So as more and more internal Google apps migrated to GWT, we could
not take much of a chance accepting patches without thoroughly reviewing them. Imagine
somebody submits a patch and it puts a bug into ad words, we could lose billions of dollars
of revenue. So we have to be really careful about accepting external community patches.
So you might have noticed a lot of frustration with the issue tracker because we had our
internal issue tracker, and we were proprietary to internal bugs. Hundreds of internal GWT
apps, you know, our internal customers come first, compared to the community because that’s
where our money is coming from. And so — so I thought that was a really sorry situation
to be in because a lot of the people in the community have contributed so much to GWT
over the years and we really needed to do them better.
And so I suggested and we adopted that we’re going to basically change the governor — governing
body of GWT to no longer just be Google as a dictator, but be as a peer. So we’re introducing
the GWT steering committee. So now the control over the future roadmap of GWT, when features
go into it, who gets to be a committer, who is a code reviewer, what patches get landed
is now going to be controlled by a committee of several of the top, you know, star contributors
to the GWT community and some of the biggest companies using GWT. Google goes from being
now a gatekeeper to a peer amongst equals. So we have to be more responsive, we have
to think more about what other people are using GWT for, not only what we are using
it for. The steering committee is going to determine what the project guidelines are,
what the policies and philosophies of the project is going forward and determine who
gets direct commit access to the master branch. And it’s going to set the overall future roadmap
as I said. We have drawn from a mix of star contributors, and here they are. This is the
initial GWT steering committee. It’s Google, Vaadin, Sencha, Red Hat, Thomas Broyer, and
Stephan Haberman, who have done an enormous number of bug fixes to GWT over the years.
Daniel Kurka, who has done an absolutely awesome mobile GWT library, and Christian Goudreau
of Arcbees, who has done the GWT team library which a lot of people use because it extends
our MVP library, it’s really fabulous. We’ve had some early decisions. We’ve had
a couple of meetings already. We’ve decided, this might please many of you, we’re moving
the DMT repository from Subversion to Git. [ Applause ]
>>Ray Cromwell: And we’re going to have two official branches now. The master dev line
trunk, where all of you if you have a feature, you can submit your patch, and it can land,
whether or not it may break an internal GWT application. This will be the bleeding edge
branch. Everyone when you get a nightly build one and try it out, we can figure out what
needs to be rolled back. But if it makes it through the dev branch and doesn’t destroy
anybody’s applications, then it’s going to be cherry picked into the beta branch, which
represents the work on the next release, let’s say GWT 2.6 or GWT 3.0. The beta release is
what Google is going to be building our internal apps off of. So there’s going to be a lot
of quality assurance on that branch so you can be sure if you want to pick up something
that’s a little more stable, you can be trusting in, that would be beta branch. Our partners
like Sencha and Vaadin will probably also be shipping code based off of beta branch
works, not the dev link. So you will have a much lower probability of breakage.
So here’s where you will find us, there’s going to be a new website, not up yet. It’s You can read about all of the new rules, processes for contributing
to the GWT. And there’s a GWT steering mailing list where you can read our meeting minutes
and our discussions on what’s happening with the future of GWT and where it’s going. So
you won’t to wait ages for a blog post from us to see what’s happening.
Now you can read it in real-time. So now I would like to ask Michael Mullany,
CEO of Sencha, to talk about all of the brave and exciting things that they’re going to
do with GWT now and in the future. [ Applause ]
>>Michael Mullany: Awesome, it’s great to be here. My name is Michael Mullany, I run
Sencha. Also joined by Darrell Meyer here in the audience who is a tech lead for Sencha
GXT at Sencha. Do you want to stand up, say hi?
>>>Hi there. [ Applause ]
>>Michael Mullany: Okay. So before we start just a quick poll. How many people have developed
with GWT, since you’re in the GWT session, right? Good. How many people have done an
app over 10,000 lines? 50,000 lines? 100,000 lines? Half a million lines? Over a million
lines of code? Okay. That’s a good distribution.
Well, one of the reasons that we are excited about GWT is because it does really help you
with very large applications and very large teams working together. We are a company that
has about 2 million worldwide developers in JavaScript and in Java. Across all sorts of
applications and all sorts of geographies. Of that, we have about 400,000 registered
community members on an incredibly active forum, so we’re approaching kind of a million
posts on our forums over time. We’re also expanding geographically pretty
rapidly. We started on the East Coast, moved to California, we just opened a Vancouver
office and an Amsterdam office. I’m not allowed to say we’re hiring, so I won’t say that.
[ Laughter ]>>Michael Mullany: We have a really amazing
array of applications built with Sencha Technologies with XGS, with Sencha Touch and with GWT.
We have everything from very large clinical trials management applications to CAs, admin
interfaces to Dell’s warehouse management system, Best Buy’s store system, all built
with Sencha technologies. We’re primarily focused on business applications and very
large applications. That’s why people use a very structured framework, like XGS or GWT.
And our goal is to take — to really provide a complete productivity capability from design
time to development run, all the way to deployment. So Sencha architect, if you stopped by our
sandbox yesterday, is a drag and drop visual app builder for Sencha Touch and XGS so you
can get mobile and desktop on the same tool. We are also happy to be working on GWT designer
integration for GXT. Sencha (indiscernible) is focused on content animations. The build
side JavaScript frameworks for mobile and desktop and we have GXT for Java. Our deployment
is the newest thing that we have. It’s cloud services that basically provide back end point
services like notifications, authentications, app messaging for mobile and desktop applications.
Our goal, and I think this is a common thing across developer bases today, is to as much
as possible provide a single HTML platform across all of these — in the multi-device
world, right? So from phones to tablets to TVs to desktops, people are trying to create
application experiences that follow you from device to device, that reuse data, reuse models,
reuse business logic, controller logic as much as possible and that’s really our design
point for Sencha Technologies, whether in JavaScript or in Java. XGS 4 is our JavaScript
framework, I won’t spend much time on it. It basically provides structure for JavaScript
programmers who want to create large applications that are pixel perfect across browser. The
companion to that is that Sencha Touch, which is again a JavaScript framework for modern
mobile devices. We made a bet that smart phones were the only
phones that smarted and that turned out that was the case. We do an awful lot of low level
platform code switching abstraction to make the code base work across every device that
you can think of. I mentioned architect and IL. So on to Sencha GXT, which is a meet for
this room. GXT started about five years ago as the — as Darrell’s project and then Darrell
joined Sencha and merged with the Sencha team. It’s basically fully featured, theme-able,
high performance widgets. It’s a true GWT implementation, even more
so in GXT 3 than was the case in GXT 2. The big thing that GXT brings to the table is
full alignment with GWT conventions in GXT 3. But really the thing that knocks you on
the head when you look at GXT is just the sheer volume and weight of UI widgets that
we bring to the table that you don’t have to create yourself. There’s — there’s literally
several hundred widgets of all types for all types of applications that work the way that
GXT or GWT expects. So GXT we just completed an enormous release,
our GXT release. It was just released about six or eight weeks ago. It basically takes
what we had built ourselves from our own custom conventions for things like event handling,
all into GWT 2.1 through 2.3 conventions. So, for example, we now use the cells to render
our trees and our grids and it’s much, much faster and much, much lighter weight. We have
also moved to interface-based design, so for large applications it’s much easier to create
mocks and to do testing. We’ve done — [ Applause ]
>>Michael Mullany: Thank you. Custom theming, so we now use the appearance pattern. We’ve
pulled out theming information out of the components and out of widgets, so it’s much,
much easier to add raw HTML and CSS styling into your components without standing on your
head. We also have much improved model support. So in — in GXT 2, you basically have to use
our custom data stores and that was the only way of getting data into an application again
without standing on your head. Now you can basically pull in — pull in model data from
plain Java objects or for any beans that you have. Much more flexible. We also added full
UI binder support so you can declare your UI widgets with the UI binder XML conventions.
Another thing, strongly type layout engine. One of the big issues with our layouts in
GXT 2 was that you could basically have a lot of mismatches between a container type
and a layout. So now we’ve gone to strongly typed layouts, so it’s much harder to make
a mistake and the compiler will catch it if you try and associate a layout with a container
that doesn’t match it. And there’s a lot of other things in the release,
but basically the whole theme was have a huge widget library and theming that works with
the new GWT conventions and I think we’ve been pretty successful with that. It’s had
a great response and a great reception in the short weeks that we’ve released it. And
we’re really happy to have released it. So we’re actually incredibly excited about this
opening up of GWT with the steering committee. One of the main reasons that we ended it with
custom conventions in GXT 2 was the fact that we had no idea what was coming down the road
from the GWT team. So we had our own event system and I think it was literally a couple
of months afterwards there was a new event system from GWT that if we had known was coming,
we probably would have aligned with. So we’re really happy to continue to promote
RIA for Java developers. We’re really excited to be a member of the steering committee.
We would love to hear you, as a member of the steering committee, your ideas for how
we can improve GWT going forward. GWT we feel is the best way for organizations that are
committed to Java to build front end applications, particularly larger ones, larger teams, that’s
what our customer base tells us why GWT is an awesome solution for them.
So what are we doing? We’ve just finished our GXT release, so it
was pretty huge. We’re just getting around to planning the next release. But a couple
of things we’re doing is making the appearance implementation that we have better with a
more flexible client bundle, we are doing some updates to UI binder, and I think some
of our changes have actually made it into the 2.5 code base. Theme building. You know,
it’s actually a huge request across our product line, which is how can we do better visual
design without having to hack into SASS or hack into custom CSS. Better IDE support and
tooling. So there’s some support coming in GWT designer for GXT 3. But our goal is to
make it easier and easier to create GXT applications using standard Eclipse and stand IDEs.
There’s much, much more detail into what we’ve put into GXT 3, we’re really proud of the
release. Probably the best place to learn more about it is on our blog, that’s the link.
Just Sencha-GXT from our blog. Also Darrell and myself will be here hanging around after
the session if you want to talk to us more about GXT.
We’re really excited about the directions, we’re really honored that Google has asked
us to participate in the steering committee, and we hope to be able to serve the GWT community
as best we can in this new role. So thanks again.
[ Applause ]>>Ray Cromwell: I would like to ask Joonas
Lehtinen to come up. He’s the C.E.O. of Vaadin, which he has a fabulous framework. He’s going
to tell you all how Vaadin is going to contribute to GWT and what they’re all about.
>>Joonas Lehtinen: Yeah, I’m really excited to be here and see where GWT is going at the
moment. Let’s first kind of give a brief intro to (indiscernible) how we are using GWT and
where that relationship is going in the future. So you can say that Vaadin is a Java frame
building rich web applications, and as that it’s quite like GWT, but at the same time
it’s different from GWT; in Vaadin you’re doing everything from the server side. It’s
basically based on three different items. So first we want to have amazing components,
both as URL components as well as data sources and data (indiscernible) themes and so on.
So we have really nice set of widgets in the core product, hundred or so widgets, you can
go to to see that out. There are also widgets for mobile, Android, iPhone,
iPad. What I’m mostly excited about is the community around Vaadin, so there are hundreds
of plug-ins in for Vaadin. Those plug-ins might be widget outbreaks or
integrations or themes or tools. Second idea is that they’re combining server side RIA
together with (inaudible) so what is this search? Look at this, so basically you have
five layers in your (inaudible), so you have the back end layer and the Web server. You
have communications. And you’re going to have Java to Java compiler, and then Java to Java
within Web browser, so if you look at GWT, it looks like this, so this
(indiscernible) four layers, and optionally you can do on JavaScript on top of that. Vaadin
is quite different. You are only writing two layers. You’re only writing code on the server
side, so everything on the (indiscernible) layer and on the browser side is total automatic.
You don’t have to write any line of code for those. And if you’re converting this to Java
frameworks, I like XJS, it’s probably the best one out there at the moment. So also
in here you’re writing four layers, and this is the core of the (indiscernible) you can
kind of skip half — half of your program when you’re writing in Vaadin. It actually
works like this. So all of the components have two parts. You have server side component,
it’s basically API that your program is against, so whole UI is on the server side. On the
client side, you are rendering and event handling, and that part is totally done with Web toolkit.
(indiscernible) Third thing, Java, basically everything in Vaadin is (indiscernible) object,
so all of the components are plain ole objects just running on the server side in the real
JVM. (indiscernible) you can write UI in any language out there. You can use (indiscernible)
what have you. You can use any tooling, any IDs. You can deploy this to almost any server
out there, most of the clouds, and at the end of the day, it’s just one file, so you
can use that in any web browser. Just drop that (indiscernible) into a project, you can
start adding UIs with that. It’s (indiscernible) license so it should be the same license as
GWT. So what’s the relation between Vaadin and GWT? Let’s look at the history. This is
actually quite an old project. We started in 2001 already. So we’ve had 11 years of
history behind us. And then we kind of started to have huge number of JavaScript code lines
on the client side to render all of those components, and it turned out to be not that
nice, so fortunately GWT came along and we threw all of that away and we wrote everything
in GWT. (indiscernible) It was a perfect fit to Vaadin. Both are written in Java. Both
(indiscernible) oriented and both recorded across browsers, something very important
for us. So I could say that this has been kind of like standing on the shoulder of a
giant, this giant being Google and (indiscernible) you have been doing a really, really excellent
job, and it has been helping to write quite a bit, so we haven’t had to deal with all
the browser differences ourself. So you can see this as
our engagement period of five years for us, and this has been strange engagement because
after five years, we are still in love with GWT. I truly think that GWT is the best way
of building Web scripts, Web application on the client side with Java. So if you’re building
a huge application, there is — that’s the kind of number one way of doing that on the
client side. But the relationship have been kind of unidirectional. We have been getting
a lot from GWT. And we haven’t been giving too much back. And I think this is the same
for many of us, so we have been using GWT, we haven’t been giving too much back to GWT.
And I’m really thrilled to see this new development with the steering committee and more open
process for GWT, so we can come back to GWT, and I hope in the end this grows to be something
much, much, much bigger than it is today. So where do we go next?
You have been kind of jumping in five year leaps. What’s the next leap for us?
So I’m really thrilled to announce the new study for Vaadin. We are adding GWT to Vaadin.
So what does it mean? At the moment we are kind of using GWT as
a dependents. We are using GWT as a rendering agent behind the scenes in Vaadin. What they
are doing, they are moving inside Vaadin, so they’re taking copy, putting that inside
Vaadin and maintaining ourselves (indiscernible) and we, of course, are contributing
all of those back to GWT. This also means that Vaadin will be combined with GWT. So
for two days project you can use Vaadin for that, and as a win developer, a new customer
what’s more in there? There are a couple of things. But first, there
are actually two sides of Vaadin. So we have two program modules. We have server side programming
and we have client side programming. Server side being optimized for the productivity
and the client side being optimized for the controlling. So you get both around 50 reduction
of code lines when you’re programming in the server side as well as all of the wonderful
controller on the platform on the client side. So you can see that from the developer point
of view we are adding (indiscernible) components, tools, themes,
but also there’s one more theme. (indiscernible) support, we are serving companies who are
using our technology to build applications, and now that we are merging GWT in the Vaadin
directly, we are starting the support with Vaadin. If (indiscernible) we are a good project
for you. This is going to be available pretty soon now. So we are targeting for the Java
1 release with Vaadin 7 that will be including GWT, and it’s available as a developer preview
today. This is an early alpha release, but it’s there for you to try out. There is a
ton of more things to read about how Vaadin would kind of combine and what that old aspect,
(indiscernible) and read more about this. Thank you.
[ Applause ]>>Ray Cromwell: Let me switch back to my
slides. Okay. So there were a couple of other steering committee members who couldn’t be
here, I don’t want to spend too much time. But Christian Goudreau has developed a wonderful
library called GWT, and he is on the steering committee as well, and he has some wonderful
things to say, and I’ll just leave that up there for a second for posterity. As well
as Daniel Kurka who has done an incredible mobile library for web property (indiscernible)
I encourage you to go to, check it out. And he is also on the steering committee.
I’m sure he’s going to be focused on making GWT better for mobile. Finally, we are hiring.
Believe it or not. So if you are a unemployed GWT programmer and you’re looking to join
Google, and work on (indiscernible) please send your resume to And now
I will turn the microphone over to you. You’re free to ask questions.
[ Applause ]>>>Hi. So my first question is about validation.
You said you’ve implemented the 303 at 2010, but as for now, our classes in package validation
are marked as experimental, and they say do not use them in production.
>>Ray Cromwell: Yes. I’ll answer very quickly. We have recently hired someone to specifically
work on the support in GWT and to make it 100% compatible with the 303 TCK test compatibility
kit. So if you look at the event logs right now, you’ll see a new guy who is committing
— or actually one by one he’s fixing the TCK test, and once they pass the TCK, then
we’ll remove the experimental tag.>>>Okay, thanks. When will 2.5 be released?
>>Ray Cromwell: RC1 is out already. You can download it now. Probably in maybe a week
or two, the final version, after we get some bug reports back and smoke test it more. Okay.
Thank you. I’ll go over to this one.
>>>Hi, I’m a GIS developer, I use Google maps to do — in my projects. Most of — I
hate JavaScript. Most of the time I’m looking for a GWT wrappers around Google maps API.
Are you guys coordinating between the two teams to always have a GWT library for Google
maps once a new version of Google maps API comes out?
>>Ray Cromwell: Yeah, a good question. So, yes, in the past, we have done that, I believe
recently they may have released an update to the Google API libraries for GWT which
included some support I think for 3.0. I don’t know what state it’s in. Unfortunately, the
person who is working on it, Eric Zundel, left to go to another company, but we will
try to figure out a solution for that. It may be that the steering committee takes it
over, like for example, maybe Sencha with some maps, widgets in there, and they can
basically take on the task of ensuring it’s always up to date. But we’ll find out. We
are definitely concerned about it, because maps are actually very important.
>>>Thank you.>>>Hello. (saying name). I’m a new developer
and our team is mostly — we are mostly using intelliJ to develop and to debug our applications,
and the question is with the new super dev mode, will we be able to use our favorite
IDE to debug applications, or the only way to do it will be the browser?
>>Ray Cromwell: Right. Good question. As you can see. I am a rabid intelliJ user, I love
intelliJ, and I constantly rag on people at Google that use eclipse. The answer is that
we are trying to talk to JetBrains, they’ve done a lot of good support in the past to
basically get support for source maps within intelliJ, and based on the outcome of those
talks, if they’re willing to do it, if source maps are implemented or if we had a plug-in
to do it for intelliJ, intelliJ can already attach to JavaScript debuggers, so essentially
instead of attaching it to JVM, you attach it to the Chrome debugger, and all it has
to do is use the map to actually let you match it back into the editor, breakpoint intelliJ
to control Chrome. It definitely is a possibility to make that work, and we need to talk to
the right people and make it happen.>>>All right. Thanks.
>>Ray Cromwell: Let’s go over there.>>>Hi, I have two questions, actually. First
about the steering committee. I’m very happy to see that Google is accepting more external
people, but I’m also a little bit concerned because there are a lot of companies that
have large libraries on the steering committee. How do you guaranty that — these companies
have their own agenda. How do you guaranty that GWT doesn’t become bloated with their
features that –>>Ray Cromwell: I can answer that. First thing
is that when we initially nominated them, we told them that we realize that they have
commercial interests, but we would like steering committee members to also kind of wear the
GWT hat. So, for example, we’re on the GCC committee, I think, you know, Google participated
with GCC development, and of course people on the GCC steering committee, they’re all
commercial companies or different chip, you know, like AMD or Intel or whatever, so they
have interest, but the people on the committee usually do a pretty good job of wearing their
GCC hats, and we expect that the GWT community members kind of wear their GWT hats so that
they have things that are competitive, they’re probably going to keep them anyway, because
that’s their value, but if there’s new core features they need, like new event handlers
or new support for low level operations or there’s bug fixes that they have been forking
off privately in the past to fix, now they will contribute them back. The second thing
is that the committee is run by consensus, so if anyone objects, basically, to a proposal,
it doesn’t happen. So we basically all have to agree, and some people on the committee
will be concerned about bloat, and if, you know, someone wants to drop in like a two
megabyte JavaScript library, there is going to be some objections. Is that —
>>>I have a question about the example you showed with injecting Java code inside the
HTML page, so you type window from lower case W, it’s not class window.
>>Ray Cromwell: That’s right. So — yeah, so the intelliJ is actually a really fabulous
IDE, (indiscernible) so I told intelliJ to assume that there’s a line in the code that
looks like this, window window is equal to browser dot get window, and so that is like
implied that’s there, and what happens is the filter, when it’s extracting that code
and writing it to disc, it inserts that line, so the IDE doesn’t complain that that window
variable is missing because I told intelliJ to assume that that’s injected. So that is
a feature of intelliJ, so if you’re an eclipse user, you might want to check that out.
[ Laughter ]>>Ray Cromwell: Okay. Let me go to him first.
>>>So another question I wanted to ask is about kind of release for GWT, what are the
next versions when they will be out and what features are planned so probably this question
must go to your committee and what will be the process? Who will decide?
>>Ray Cromwell: Right. Excellent question. And, yes, I should have basically made it
clear that 2.5 will actually be the last official Google controlled release. Every new release,
GWT 2.6 or GWT 3.0, will now be basically a steering committee release, and so the road
map, we haven’t — we’ve just started our first two or three steering committee meetings.
We got basic IP issues, and things like that. We’re getting to starting to find a road map,
where are we going to go, go to GitHub or somewhere else, there’s lots of arguments
in the base over that kind of stuff (indiscernible) and so one thing we’re going to discuss is
what’s going to go into the next version and when is it going to be released. So if you
watch GWT steering — GWT.steering at, you can follow along and probably get some
inkling as to when it’s going to happen. Probably sooner.
Okay. Any last questions? All right. Well, thanks for coming, guys,
and I hope you continue to join GWT.

Comments 14

Leave a Reply

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