Bruce Johnson discusses Google Web Toolkit
Recorded at:
- Share
-
- |
Read later
Reading List
Bio Bruce Johnson is a Google Software Engineer and tech lead of the Google Web Toolkit (GWT). Prior to joining Google, Bruce cut his product teeth as lead developer of AppForge's MobileVB product.
Sponsored Content
In a nutshell it was to try to get a little extra leverage around large AJAX codebases, basically. JavaScript is a very powerful language, the flexibility of JavaScript on a small scale is really a good thing, but as you add lots and lots of people working on the same codebase, some of the things that rely on, just sheer discipline and use of idioms consistently start to get a little brittle and so when we run into a sort of "spaghetti-ish" situations we wondered if there wasn't some way to provide a little more structure and so we thought of this idea of translation Java into JavaScript so that Java can provide some of that structure.
Java is a strongly typed language, which is nice. There are pros and cons of both static and dynamically typed languages, but there are certainly advantages of compiling from a statically typed language -- for one thing you can check a whole lot of things in Java source that you can't really check in JavaScript. You have the ability to do things like share code easily using JARs, whereas JavaScript has a little more of a tricky, less refined reuse model. We want to encourage people to use good software engineering practices, reuse is a huge part of that. Also you get to use a variety of Java tools, things like great Java IDEs like Eclipse and IntelliJ iDEA and NetBeans and so on. So GWT, because it works with Java source, it can implicitly work with all those development environments as well. And then we make sure that it would work with all the Java standard debuggers, Java profilers, code coverage tools, static analysis tools like FindBugs and so on. So there really were a lot of benefits to be gained by simply switching languages.
I guess maybe people's first impression was: "This is a sort of translator"; it was a little dismissive until they got to see what it was really doing under the covers. They assumed that we were somehow blindly translating a particular Java construct into something in JavaScript, so that it would lead to bloated code and so on. Actually we take a much more computer science-y, and more aggressive approach to that which is that we parse all the Java source together and do some pretty aggressive optimizations on it. We disallow reflection and dynamic class loading, intentionally. The advantage of that is you can do whole-program optimizations when you know that there aren't pieces that are not analyzable by the compiler. Reflection kind of defeats full static analysis since you never really know what is going to happen until runtime, but if you take that out of the equation, you can compile a large source code base of Java and if you compile it monolithically then you can analyze every single call site, every method implementation.
You can identify things that appear polymorphic but really aren't, we call that "type tightening". Once you do that you eliminate polymorphism, you rewrite call sites and translate polymorphic dispatches into static dispatches and once you do that you can inline the code which allows you to do another iteration of other optimizations. So it is a real compiler and we've really only scratched the surface with the optimizations I mentioned and there are a lot more cool optimizations that we can do in the future. The benefit to GWT users is that all they have to do is upgrade the new version of GWT, recompile and they get a huge benefit in either size or speed or both. For example in 1.4 which is the next upcoming GWT release, a simple recompile will gain you about 20% size reduction and faster start-up time.
We did that when we went open source in December and we really just wanted to make sure that we started the open-source community out on the right foot. So what we did in that document, "Making GWT Better", was to lay out the underlying principles of the GWT design which may not be obvious when you look at it. When you hear GWT you might assume it's all about abstracting out the platform completely or making it easier to write code even at the expensive of speed or size or something like that. Actually that is not the case at all so our mission statement actually focuses much more on the end-user experience and the document explains that we emphasize user experience above even what is cool or even what is convenient for developers.
Often we've had discussions online where developers say it would be really convenient if it could do X, Y or Z and if we decide that that would somehow negatively impact the end-user experience we won't do it, basically. We do prioritize end-user experience over development experience. That said, if we could find a way to make development easier obviously we'll do that and our favorite kinds of features are things that make your application faster, smaller, more usable and are very convenient and we've actually managed to achieve that with a lot of the core facilities in GWT: History, RPC, JSNI and so on.
We've been really happy. We've got already, we've committed dozens and dozens of patches, really fantastic ideas from a wide variety of people -- people all over the world have participated. There are 2 different mailing lists/Google groups: the first is the traditional GWT-users forum, where people were really excited to see that we had open-sourced. They were interested in checking out the code and most importantly they feel comfortable using GWT because they know that, this wouldn't happen but if Google somehow abandoned it or something like that, they could still continue to use it. Actually we are building out the GWT team even more over time, so that is not the direction it would go, but it does give people a sense of comfort I guess. And then there is another group called GWT-contributors where we actually discuss the nuts-and-bolts of developing each new release and we've had a few hundred people sign up already just in the last 8-10 weeks and some really great discussions about some pretty interesting and insightful technical low-level stuff within GWT. So it's been really great.
There is a bunch that I really like. Datetime and number formatting/parsing are a supplement to the internationalization library that's been needing to come for a long time --That is ready to go in for 1.4. There are startup time optimizations independent of the compiler, so for example when you restart an application that you've downloaded before, you actually fetch 80% fewer bytes during that startup process so startup is faster and uses less bandwidth. Some of the other big things: there's a benchmarking subsystem that is going to work in the context of JUnit, but it will actually do benchmarks for you on code of your choosing. So you can generate data tables and graphs automatically to say how some bit of code behaves, which is really nice because behavior can vary widely across browsers depending on which low-level JavaScript methods you use so it's a good way to help us ensure that we are doing really efficient things at the low levels.
There are several new important widgets: RichText, spelled with spell checking, there is an AutoSuggest text box, some button variations like an image button, a custom button, a toggle button, a few other things like that. Another unusual feature that I think is going to be really powerful I think is called ImageBundle. We actually count the number of HTTP requests that a GWT app makes -- we take real working apps and then we just count the number of HTTP requests so we decide, "could we eliminate that one or not", we do that over and over. We noticed that a very common use case is to create a toolbar or something with images, so in a big app you can end up requesting dozens and dozens of tiny little images and even if the response is essentially "not modified" you're still having to create those connections and tear them down and because of the outgoing HTTP limit of 2 connections at once it creates this contention for sockets that are essentially not doing anything.
So you are just finding out that the image you already have is already up-to-date, which is kind of a waste. So what we do now is at compile time if you create what's called an ImageBundle and refer to several different images, at compile time we take those and combine them into one large image file that is named in a unique way so it can be cached on the client and then replace references to the individual images with a similar construct that acts like an image, but is actually just a clipped rectangle within the larger composite image. So whereas you might have had say 40 downloads of images you have one now and you just have your different image objects pull out different portions of the image, so pretty interesting kind of technology that really is a direct result of the fact that we have this compilation step.
Can anyone play the video
by
Toby Jee
Tried to play the video but it doesn't work. Just wondering if its just me, can anyone play the video?
Hello stranger!
You need to Register an InfoQ account or Login or login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think