Tip:
Highlight text to annotate it
X
>> RAMSDALE: So to keep things on track here, we'll go ahead and get started. My name is
Chris Ramsdale. Thanks for coming out today. It's packed house this is fantastic. So I'm
going to give two sessions for today that are on our Google Web Toolkit. The first one's
is going to be more of a 101 session to get everybody on the same page about what you
can do with Google Web Toolkit, how you can build rich Web apps. So from a show of hands,
how many people have actually used Google Web Toolkit to build an application for you?
Great, I think there's a lot. But there's blinding lights in front of you so I'll assume
that it's half the crowd. Today, we're going to go through what Google Web Toolkit is.
I'll give you an overview of that. We're going to talk about tools for developers and then
optimization for users. And then we'll give you an intro to GWT best practices in GWT
2.1. So from a 25,000-foot view, what is Google Web Toolkit? Well, it's a development toolkit,
it's not a framework. I have nothing against frameworks but the notion is that we are a
set of tools that you can pick and choose to make web applications. We have a compiler.
We have code generators. We have Eclipse support. We have plugins for IDEs. You can pick and
choose either one and you don't have to--you don't have to buy into all of them. Unlike
frameworks like Spring or other ones that are supposedly favored by JBoss. So the one
thing you code and buy to is that you're coding in Java. You're writing a front-end code.
And what I mean is--when I say front-end throughout this presentation I'm talking about code that
runs in a browser. So, if you write front-end code in Java then it runs in JavaScript. We
have again, a compiler, a set of code generators that take that, cut that Java code and turn
it into HTML5 and to CSS and JavaScript. The other thing is use one code base in a browser.
So if you're running a consumer-based application, you typically have users that are using both
IE, Firefox, Safari, Chrome, some Opera users, depending on where you're at. What we tried
to do is give you the ability to write one single application with no tweaks in or right
in any browser. Fourth, we make AJAX a piece of cake. Not that it's rocket science to begin
with, but there's lot of boilerplate code that goes into doing AJAX. There's a lot of
serialization, deserialization codes, some stuff that I talked about in the keynote today.
And with GWT, we tried to make that a piece of cake. We tried to make it faster because
we have a holistic view of your application. That means we know what types you're sending
over the wire. We know what types you're expecting to get back. We know how to serialize them
off the wires. We can reduce payload and ultimately make your application even faster. And then
it's funny, GWT is using the main products, AdWords, or kit, which is open to you guys,
and hundreds of internal applications as well. So as you can see, Google Web Toolkit started
out as just an SDK. But it's grown over the years. Now, we have a GWT family, as we like
to call it. There's the GWT SDK. There's the Google Plugin For Eclipse. There's Speed Tracer.
And now, this recent addition to the family, which is the Google Web Toolkit Designer.
It was part of a company called Instantiations that we acquired about several months ago.
We are now in the process of bringing their products into the IDE as well, making more
unified Google Plugin for Eclipse. Now, when you do these tools working together is that
you design and develop using the Google Web Toolkit SDK and the Google Web Toolkit Designer.
You're going to debug using our Google Plugin for Eclipse, right, within the IDE. And then,
you're going to optimize with Speed Tracer. Now, for some of the users who are not familiar
with Speed Tracer, if you ever used Firefox, use Firebug instead of--outside of Firefox,
it gives you an idea of like, how your JavaScript's operating. You could do some debugging. You
could do some introspective look into your application. Well, Speed Tracer takes that
one step further. And it actually has hooks inside of Webkit so that it can see when you're
doing things like painting, layouts, garbage collection, things like that, to identify
where your app might be sluggish in the browser. So, when we typically think about who our
target is, right, we have two focuses. We have to focus on the user. We focused on our
users. So that's the developers, everybody in this room. And for those developing for
those users, we look to leverage existing IDEs and tools, right? Again, everything is
available in Eclipse that was normally available to service side programmers or mobile programmers.
We should make that available to web app programmers as well. We want to minimize the refresh time
between coaching. And so you're not actually going and making a change, having to recompile,
to redeploy, it'll take some [INDISTINCT] to do that which means [INDISTINCT]. And then
the work, when we can, we would animate as possible. Again, we have tools that are operating
on you're Java code. We know things. We can do things based on that that minimizes the
amount of code that you'd have to write. Let's you focus on the next killer feature. But
then we focus on your users which are the end users, your customers. And then, we would
have minimized our time when we're making a comfortable experience, right? We want to
get them off the desktop applications and get them into the web, into the browser. That's
why we have to make it as fast as possible. It needs to feel like a desktop application.
And then finally, when have made a comfortable experience, being in that we will let them
use whatever browsers they're comfortable with, right, whether it's Safari, in Firefox,
IE, or Chrome. So, we have different goals when we look to different users. You as developers
focus on writing the next killer feature, making it look good, and doing some code refactoring.
Say, you've picked up a piece of code from your colleague who's left the company. You
think it's terrible. You want to go refractor and make it better. So that's what your goals
are right there. Goals for your customers are a little different. They just want to
make it fast. You know, "By the way, don't charge my credit card twice when I hit the
back button." How many times have you been using a banking application and you're like,
"Hmm, if I go back, are they going to charge me twice?" So they would appear to be different
and somewhat competing goals, right? That's not the case. With Google Web Toolkit, what
we've done is we made it possible for you to focus on what you want to do as a developer,
right? Write a great app. Killer features you can be proud of. I mean, who will take
care of making it fast and doing things like handling history support for you, right? Let's
you focus on the features. So, some back story on Google Web Toolkit. No plugins required.
Now, you'll see me talk about a developer plugin that we use for us developers. But
for your customers it's just HTML, CSS, and JavaScript. So, you don't need any Flash plug-in.
You don't need any Silverlight plug-in to run the applications. It's nothing against
those plug-ins. I think they're great, actually. We just don't want to run into this, right?
So, some plug-in is not available for let's say your mobile phone and then you can't run
an application on it. So, look, stick to standards, right? Eric talked about cloud portability.
Well, it's not just cloud portability, it's the ability to bring your application anywhere
on any device and not have to worry about two companies working out some silly agreement.
So, port use. If you just focus on IE, it's not--you're not--this is not going to be of
great importance. But if you have your focus any other browser other than IE, it gets to
be important. Because what we've done is that each browser handles certain pieces of JavaScript
code in CSS just a little differently. So, here's one example. If I want to take--and
I have a div, right, just a spot where I could put in some HTML, there's a couple of ways
that I can do this. I can say, "set in a text." I can set text content equal to some HTML.
Or I'm going to say, "intertext equals some HTML," right? In each way, it's a little bit
different. Some browsers support one, some browsers don't support the others. And if
you have to write this by hand you have to know which way to optimize. Because, for example,
on Firefox, it's a little bit faster just to say, "intertext equals," right? And now
on IE, it's significantly faster to say, "intertext equals." So, what we do is we take those and
we find the most optimal way and we expose an API that's just normal for you. So, you
just simply say, "set text," or "set HTML," and then we'll take care of doing the right
thing for you, and then that's it. And, you know, you might want to think that the new
terms in milliseconds, this is very big. But if you look at it, the percentages are pretty
good. You had a 14% savings on Firefox; Webkit gives you 29% savings, so on and so forth.
And then there's this guy here 464, you definitely should check out this guy's blog because it's
filled with pages and pages, and pages and pages of weird things you'll run into as you
start to build up your application. Granted you're not going to run into them the first
few days but look, we're in for the long haul, right? We're going to write an application
that'll take three months. It's going to take a year, some take two years. And it's going
to grow. And eventually, we're going to get into some weird state where like, "Oh, it
just doesn't quite work right on IE6," you know? So, we take care of that for you. Another
thing, and this is why we love tools so much, right? This is JavaScript right here. And
I heard you say, "It's pretty trivial. But can you find the bug with this example?" Well,
if you can--go ahead. Right, exactly. So, it's pretty simple, right? But it doesn't
look like it. So, if you actually ran this, the way you found a bug--unless you're just
staring at it on a big screen--you run your app and you probably have three screens into
it and you get some weird JavaScript, no exception, have no idea what's going on, have to trace
back in your code, you wasted about two hours. Totally ridiculous. But if you actually use
Google Web Tool Kit and our plug-in, what you get is nice little red squigglies, right?
I mean, it sounds really silly, just red squigglies. But you take them for granted almost because
what they do is they tell you immediately that you've done something wrong with your
application, fix it now, don't worry about going three screens down into it, and you
can back up. It's demo time. So, let's use an actual--let's create a new web app. And
then we're going to actually run it the browsers and hit a breakpoint within the IDE. This
goes online? It is. So, here. Again, this is a SpringSource Tool Suite, what I was showing
you this morning. And if you go "new" and hit "other," let's do this, "new," create
a new web application project. I will use Google Web Toolkit at this app engine. I'll
call it "demos." You know what, I actually realized that I don't have a Java SDK installed.
So here's what we're going to do. I'm going to expand on a demo that we did this morning.
So, this is the application that I created with Spring Roo this morning where I did a
simple refresh demo. All you have to do--it's going to hear and say, "debug now this Web
application." And it's going to start-up the debugger. So finally--so I've started up the
debugger. I'm not going to worry about the screen [INDISTINCT] but what I'm going to
try to splice my speakerphone from my application. So [INDISTINCT] into step one. Step up right
here. [INDISTINCT] okay. Sorry about that. So I'm sending this today--as this morning.
We will talk [INDISTINCT] goes. So it's been a part in here. It's actually compiling the
Java code into some JavaScript, shooting it up for the wire. We're going to get into how
this actually works in just a second, all right? So, let's jump. Come on, laptop, I
know you can. All right. Now, not much have showed here, but what I've done is I've actually
launched development code from within an IDE, so I'm told we will plug in for Eclipse, go
ahead and launch this. I launched it in my browser and I set a breakpoint in my Java
code and that's what I get right now. So I'm actually sitting in the IDE of a full stack
trace, of a full call stack as well. I can see what's going on and as well, I can run--I
can walk in here and so if I go to run, let's do a step into. I'm actually stepping into
my code now. And I can--and as I traverse this, I can actually debug both the client
from the server side as well. So then finally you just hit run, ensure that map efficiency
keeps running. And it's warning me because I took too long to actually complete the script,
but if I continue, I should be good to go. So there, so similar to this morning, only
instead, I've actually debugged so it doesn't run out. And I've got a breakpoint that's
landing inside my IDE. Let's see how that works. So before we come into that, we typically
have a joke back in the office that, you know, we're really just a Java and JavaScript compiler,
right, that's all we do. And in fact, that is the larger portion of what we do. We take
Java turn it into a JavaScript. In fact, at some point, we actually said, "You know, this
looks a lot like assembly language because this is the compiler output from the GWT C
or from the GWT Compiler. And what it does is it takes your Java, turns it into a JavaScript,
obfuscates it and then minimizes it. So have this--you have a small, small JavaScript download
in the end of the day. But you can always change that. And let's see, I actually want
to see what the compiler's output is. I can change it to pretty print and now I have something
that actually looks like a JavaScript. So if you've ever done an enormous HTML, CSS
in JavaScript program, this should look pretty familiar, right, given an end function and
you have some other things going on, some exception handlers. So now, let's go back
to the demo and see and take a deeper dive of actually how that happened. So how did
that actually get to where I was running the browser to debugging in the IDE? So tools
were developed, right. So when I--when I hit go inside Eclipse, in this case, it was Springsource
Tool Suite which you're getting in the brand new version of Eclipse. When I hit go and
hit debug outs, what happened was the Google plug--the Google plug-in, our Google plug-in,
started a code server which is just the TC, which is a server listed on a TCP port, and
it start at the getty server. Getty is Tomcat; it's just an embeddable server for hosting
your application. And then when I launched Firefox, there's a plug-in in Firefox that
actually--that is making a TCP connection back to the code server that's running into
Eclipse and they're passing JavaScript objects back and forth. So as I'm stepping through
my code and I'm translating it into the Java and the JavaScript, I'm shipping those over
the wire back to the--back to the browser and the browser is taking and injecting it
into the page. So I really do get step by step by step when I'm debugging. So if you
look at it from Eclipse to deployment, how do we actually get to the point where we have
an application that we want to deploy? So we start with the code, it's just code that
you have in Eclipse, knowing we're authorized to use a generator. And this is where a lot
of the power of Google Web Toolkit comes from, right? So we'll take a look into the use cases.
And when we look at the--at generators, what we're talking about is getting enough power
behind your GWT App. And then, one of the other goals is that we want to automate away
a lot like BorderSide code. And then the foundation for how we can split your app to serve up
the right version on Eclipse, the right version on Firefox, the right version on Safari, and
the right version on Chrome. So let's take a look at two use cases for why code generation
is so good. One, we take a look at typical RPC, just remote procedure calls, right? So
the way this happens in a typical application, this is a deploy AJAX call, because you have
a client, right, and it takes in zero--it takes an object, it serializes it, turns it
into an XHR, an AJAX request, then it gets to the server, the server de-serializes it.
It does something with it, gets a response, serializes that, sends it back over the wire
and you de-serialize it and your application is running. That's a lot of code you don't
need to write, right, and not to mention, if you start bumping versions, it's a real
pain. So what we do is we come along and say, "Well, since we know--we've seen all of your
code, we know what you're trying to do, we're going to put two proxies in between." So the
client ends up calling a proxy which just says, "Take this object and send it to the
server," right? I don't want to care about serialization, blah, blah, blah. You just
do it. So, if you have proxies, that's great. I know how to serialize it. I have code to
do that, so turns it into a format that you can send over the wire and again that's just
using XHRs. Then when it hits the server, it actually doesn't hit your server site code
right away. It hits a GWT proxy, again, that's running a de-serialization, hands it to your
application and so your server site code, what it's dealing with is objects. It doesn't
have some JSON payload that it has to de-serialize and in fact, the objects. It just gets the
objects. They are the same when [INDISTINCT] is true for the reverse file. So what you
end up doing is you write code that looks like this. So the top portion is your client
code. And what you do is--now when putting the other trivia example where you would do
a suggestion service just like you do when typing Google and you'd say, "I want to do
a search," and you get back to search results, it's--now I've got a defined suggest service.
And I'm going to expose a method, it's called get suggestions, and it's going to return
back an array of strings when it passed through the strings. So if I type in App, then it
returns back apple and some subsequent matches as well. Then, what I actually want it--and
that's how I just find my service. That's all I have to write and they coincide. Now
when I actually click a button; and I actually want to do something and call this, it's as
simple as the--as the code will look. So I'm going to click method, let's say I click a
button, and all I have to do is say suggestservice.get suggestions, get the text from my search box,
and it provides some callback mechanisms. That's really on the code. The key here is
that you're not--you're not dealing with some arbitrary strings. You're dealing with objects
that you can pass back and forth. Strongly typed objects that you can--not only can we
compile and optimize for you, but you keep tooling around as well. So you get code completion,
refactoring, and so on and so forth. And at the end of the day, it's really simplistic
code that's easy to maintain and easy to scale. So let's take a look at use case number two,
which is creating new audits. So typically, if you ever--if you've used Google Web Toolkit
prior to our 2.0 release, what you found when you're creating UIs by specifying a whole
bunch of Java, lines and lines and lines and lines of Java. So what we did is we decided
that for, you know, our 2.0 release, we're going to utilize the upcoming depth practices.
And that's when we're going to make UIs declarative. Make them feel like you would normally write
them when you're doing a web application just to use XML, right? Because when you're--when
you're creating some web application, you're just creating HTML, right? That's typically
what you're used to doing. So we said, "Okay. We'll do it in XML." So wee said, "By the
way, when we do this, we can again minimize some of the boiler plate code." You're going
to give us time and time again when we talk about Google Web Toolkit. And then we remove
other--some other frustrations along the way. One of them being if you've ever done, again,
a typical web app and you use a lot of CSS, you'll find that you have one big huge mile
of this CCS file with a lot of strange names which we don't have--we don't want to have
namespace solutions. So there's some things that we can do there to break that out, so
that when you can find this widget that has sub-widgets and it has this style as in this
one file, we can make sure that that CSS is specific only for that widget. So what you
end up doing is you write code that looks like this. So this is self-contained. It is
a widget on a page. And all I've done is at the very top where it says UI style, I have
specified some style. I want it to--I want some margin; I want some padding around this
widget. And then, I dropped down, and below where I think this is really powerful. I start
to layout my UI, again in declarative form using XML. And if you squint just a little
bit, this looks like standard HTML only if you used some widgets here. So you notice
things like horizontal panel; that's specific to Google Web Toolkit applications. Then we
can find two buttons. So what you end up with is a horizontal panel with two buttons in
it with some added color, and that's it. Now you can see how you can start your string
on this. But the beauty is this is self-contained. So if I have styles inside of here, right?
They're specific to only that widget. It will not affect anything else in the page. And
then what you can do is by using the UI field mechanisms, you'll see that UI field add button,
UI field delete button. I can then go annotate my Java code with those same field names and
implement click handlers for them. And the generators come along and they will link up
my declarative UI and the XML that you see right there and the Java code where I've annotated
with these UI fields. And when I talk of--if in it--if you're a current Google Web Toolkit
user, I'm going to have a few tips and tricks as we move through here. But if you're interested
in what we're generating, the code that we're generating, the code that I'm talking about,
you can simply pass it down to [INDISTINCT] flag through your compiler, and you'll see
all this firsthand. In fact, we talked about another--a couple other flags you can pass
through your compiler to optimize your application in a second. So, a good reason. We talked
about generators, right? So moving along the chains to get into production, we're going
to talk about translators. But it gets pretty simple after generators because translators,
all they are that's where to JavaScript to Java--Java to JavaScript compiler comes in
where we've taken your Java code--we've taken the code that we're generating, right? And
now we have the entire app. It's all Java source. And what we do then is we take our
compiler and we're going to compile our pass on it, that compiles it for JavaScript and
then optimizes along the way to all these things and compresses it so that it's minimal.
That's it. So then we need the linkers. Now, if anybody's ever done compiler design or
worked on compilers before, you'll see--you'll notice a pattern here. This is typically what
compilers do as well, right? If you took a normal C++ compiler, you would see that instead
of generators, they have macro expansion. And then the translators, that's actually
where they're translating it into assembly code and then linkers to pull it all together
to give you the EXE that we're looking for; so we're doing stuff that are--that's similar.
And the EXE that it produces is typically tied to a platform, right? It's what--it's
the binary that we hand out if you're building an application. Same thing goes for linkers
here, right? The linkers are the entry points of your GWT application--for your Google Web
Toolkit application. Now, that could be I want to load from my site or I want to do
a mash up where I load from your site onto my site, so there's some cross-scripting going
on. Or I actually want to create a mobile application in which point I'll--in which
case, I'll have to completely separate entry points so that it can serve up just some slightly
to the HTML but still the same JavaScript on the backend that I'm using and generating
from a Java code. So again, when I talk about entry points, this is what I'm talking about,
there's permutations. If you keep going off and you use Google Web Toolkit, right, you'll
end up generating something that looks like this. Now, it looks a little bit cryptic and
that's fine; but what you end up have--what you end up with here, each of these HTML pages
are for your--for a specific browser. They're for Internet Explorer, or they're for IEE--I'm
sorry, they're for IE, or they're for Chrome, or they're for Safari and also per language
as well. So you can serve a specific application for Internet Explorer 6 for the English version
or for whatever language your actual server got. So you've me talk about optimizing the
way we're all going to type code, right? And I'm really focused on developer efficiency.
That was one of the messages we're talking about in the keynote. So here I kind of go
through some of the developer time cycle column. And what we see typically is that you want
to go write some code, you run it, you push a few pixels around, right? Have you ever
gone to this, this stage where you could just tweaking little things here and there? So
you just push a few pixels around just to make it look just right. And then you have
to compile and then you go off. And while it's compiling, you read some xkcd, you read
some blogs and Twitter traffic. You might debate with your colleague about what color
[INDISTINCT] should then you revel in your accomplishments because finally the compilations
done and you deployed it and then you rinse-wash your IP. So you actually spend, you know,
50% of your day writing code, the other 50% of your day doing nothing, you're being unproductive.
Well, if you're having fun, you're honestly being productive. So, you know, we talked
about it to look into that and what's going on, right? So if you happen to go through
that cycle, well, you happen to be in that cycle for a reason because you have tradeoffs,
right? You are not writing code because the compiler is running. When the compiler is
running it's optimizing your code. It's making it small. It's giving you this alpha list.
So you get speed, or end-user gets speed, and trade off for your productivity. Or so
we think. You asked for quick user experience, right? So while the compiler is running and
it's doing all of this [INDISTINCT], it's generating all those permutations, it's having
to parse to your Java code and actually spit out a version of IE6 that runs in English,
a version of IE6 that runs in Japanese, and the same probably on the browsers. That takes
a while. So again, trading off developer productivity for user experience, or so you think. So there's
a couple ways you can accomplish this. So if you're having difficulty compiling it,
right, and you have to develop a timestamp of what's going on, what you can do is you
can specify things, even a little tricky. We specify things like I just want a compile
for Firefox running in English because that's what I'm developing on, right? I'm in the
development phase. I'm not on the production phase. I'm not going to the QA cycle. I'm
just writing code to develop this. That's one way you can do it. You can also speed
it up by simply telling the compiler, "Hey, compiler, no more optimizations. I don't care.
I'm just writing the code. I'm just developing. It doesn't need to be super fast because I'm
not pushing a new production yet. So you compile it faster, you can deploy it, you test your
changes, that kind of works, too. But why were you out compiling at all? Why bother
with this? The real way we should be developing code is simply like this; you write some code,
we refresh the new browser just like I showed you. Does it work? Nope. Let's develop some
more. Let's refresh. Does it work? Keep that cycle going, and that's quick. Those are quick
refreshes. So you're making changes and you're seeing instantaneous feedback. And finally,
when you're done, then compile and then deploy. Hopefully, the Google App Engine go wherever
you want to deploy. So what you do is, this is the software along the life cycle we that
want to see for Web applications, for Web app developments. It's what everybody else
in the industry has. We should have it, too. So, great. We're happy, right? So as developers
we're happy though. We have--well, I think you are. I hope you are. We're--we have tools
that make us efficient. We got strong and tight languages, that's good. We got IDEs,
that's fantastic. But what about our users? What about your customers, right? Are they
happy? Are they getting exactly what they want? I mean, after all, the GWT compilers
coming along and making that really tight, small JavaScript which lets me go a step further.
So let's talk about optimization for users. So there's two ways you can do this. You can
phone the resources and you can split your code. Now if you've ever done gaming before,
writing games, you do a thing called sprite which is where you take a whole bunch of images
and you put them into one and then you just do offsets to get to those. You can do a similar
thing in Google Web Toolkit. So let's take a simple example. I would associate icons
with my contacts, all right? So when I do that I have a contacts application. At some
point in time in that application, I'm going click a button, I'm going to get a dialogue
that looks like this, right, and I'm going to pick an icon to pull with my users. Pretty
simple. So--and I'm going to hand over a few of the details so bear with me. But you can
do this one way. You can goFetch all those 20 images, okay, there's 20 images there,
right? You can fetch those one at a time. Give me image one. Give me image two. Give
me image three. And that would work. So I fetch the image and then you'd actually set
the height and the width, and then it would add it to the images panel. It works perfectly
fine. By the way, that's--that is the GWT code right there. So this is what you'd see
if you did that. Now this is fire--this Firefox--running in Firefox, right? So what you see is initial
download, so I'm going to go fetch my application. I'm going to pull it down, right? So I fetch
my contacts to HTML, which is a really small file, and that tells me, "Okay, it looks like
you're running on Firefox with the versions--with language set in English, so go fetch this
other JavaScript. That's the second set you see. That's 61K." Then later on my application,
you see a whole bunch of fetches to get the images, right? Those are all those 20 images.
The problem is that when you do that it's inefficient because you're actually experiencing
all the HTTP overhead associated with getting an image. Now you don't think that's a lot.
And it's not, when there's 20 images. But imagine if you're getting 2,000 images or
imagine you are scaling to the size of a Bing search, or Google search, or Yahoo search.
The speed needs to be instantaneous so you don't want to go with that overhead. So there's
ways to do that. And actually, there's one specific way to do that. What we can do is
we can take advantage again of a code generation inside Google Web Toolkit. And all we have
to do is we say, we're going to define the interface, right? The interface--the implementation
of this interface is going to be generated by Google Web Toolkit. But what we do is we
said, "Okay, I'm going to find an interface with a bunch of methods and I'm going to annotate
them with a path to my actual file," right? So what I have then is I have this interface,
this nice interface. And I can say, resources., you know, imagezero, and it will give me back
an image resource, an actual Google Web Toolkit class that I can use to display that image.
Now, how I got that? It doesn't matter because what were doing is we're taking all those
images, compressing them down into one file and then overlaying this interface on top
of it so you can actually call and link that image resource. When you do that, you end
up with a column, a call stack, that looks like this. So again, we get the contact to
HTML, that doesn't change, it's 2k, very small. Then we go fetch our JavaScript and we're
like, "Hmm, that's a little bigger. I'll come back to that in a second." Then we move through
our application and then suddenly when I pop-up that image dialog again you don't see the
20 fetches. This is great. "I reduced all that http overhead on my application. I've
gotten rid of it." But the problem is when you look at this really closer, the problem
is that. So now, those fetches, right? I've taken all that data that I have to give, those
20 images, and I have to go fetch it when I initially did my application. So, that's
great. You have no worries the view overhead but that means my users have to experience
that lag the first time they ran my application. That kind of sucks. You don't want that to
happen. Imagine if that, again, that was 2,000 images. You have to pull down, 1 to 10 megs
of JavaScript to initially run your application. Imagine that you're doing that now on a mobile
phone. Unacceptable, right? So there's another way to fix that. So let me introduce code
splitting. Code splitting is just that, the idea that you're splitting your code. You're
only going to fetch what you need. If you remove optimizations in any application you've
written, we call that kind of lazy fetching, lazy initializations, go fetch all my contacts
right after them, do page in that sense. Well, this is the same thing here. So, when we're
talking about JavaScript, right? So, if at the end of the day my entire application is
two megs of JavaScript but I only need the first 20k and show the first screen to you
new application, then why should I be needing them? Let's see what we have here. So, now
imagine if when I click on that button, right, when I click on the button, it showed that
images dialog, if I surround it with something that's specific to Google Web Toolkit, right,
which is this GWT.runAsync that kind of wraps what's going to happen when I actually call
the [INDISTINCT] what the compiler does is it comes and looks for those split points
as it works to the application. Again, the tracking, we have a holistic view of your
application that allows you to do these kind of tricks. And it says, you know what, the
developer has said that he doesn't want to have this, he wants to split this off, right?
And as long as it doesn't have any ties back in other portions of your application it can
be completely separated, the compiler will create a whole bunch of JavaScript files.
And then when your application is running, you've noticed that like when you get to a
point, "Oh, I don't have a JavaScript so I have to make a callout and then get answers
to an RPC call [INDISTINCT] to fetch that JavaScript and bring it in your application
in you run it. The nice thing is that they call stack then looks like this, exactly the
way we want it. You get your initial HTML. It doesn't change, again, that's 2k. Then
you go and fetch your JavaScript instead of being a 160k, like previously, it's back down
to 39k, which is very reasonable. Again, it should be available, imagine less than 200,000
images for 2,000 images. And then finally, when I get later on in my application, I make
a comment and slide images, look what we have. We actually do the fetch to get the images
but we do in a way that we minimize the initial views overhead. So we have the best of both
worlds. Quick start time going to the applications, look and feels like a desktop application
but then hyper-optimized throughout my application and it'll only pull when I need to. And by
the way, once you pull down images, they're cached if you want to do it again. So this
way we get the best of both worlds. And so, finally, to recap, we have--we talked about,
Google Web Toolkit, Java for front-end development, right? Tools to target large view applications
which means that you have now a language that works on IDEs and all these tools. Beyond
the idea, imagine all the plug-ins that are there Eclipse and IntelliJ, right, they all
work with Google Web Toolkit. So that in turn makes you efficient developers. And then given
the fact that you're efficient developers, you can go write killer features and you could
start incorporating these best practices, tweaking for that last 10%, which you're not
worried about all that boilerplate code. See, this is why I keep saying, no more boilerplate
code, no more of that just stifling applications that you have to right. Let some tool do it
for you. You can focus on killer features and making your end-users happy. That's it.