Tech Talk: Bruce Johnson on Google Web Toolkit

Discussions

News: Tech Talk: Bruce Johnson on Google Web Toolkit

  1. Tech Talk: Bruce Johnson on Google Web Toolkit (11 messages)

    In this Tech Talk, filmed at The Ajax Experience in Boston, Bruce Johnson discusses what you can expect when you build your web app with GWT. Bruce also talks about using GWT with existing JavaScript libraries, testing, and profiling, as well as addressing how much of your application should be written with GWT.
    What kind of application is GWT meant for? Bruce Johnson: Well, it excels at applications that have fairly rich client-side state. Although we have taken a lot of care to make sure that it was sort of pay-as-you-go. In other words, if you only use a little bit of functionality, then your script should be relatively small. If you use more functionality, it should be larger, but it should only get larger in proportion to what you actually use. We wanted you to be able to seriously consider adding a little bit of GWT to an existing web application. So, there is not a requirement to download some, 500K JavaScript library for example. If you only use a little bit of GWT functionality, only a little bit of JavaScript is downloaded, but that said, it really starts to excel when you can build leverage client-side state, when you can keep objects around in the client, and manipulate your application over time without having to do round trips to the server, without having a complex session state on the server that has to be saved to a database and so on. All that state is retained as live objects within the browser as you would expect just like programming a traditional client/server application.
    On testing:
    We wanted to bring software engineering practices to the world of AJAX as much as we could. So, JUnit support has become a big part of the Java culture, development culture. So, our thought was that we should support using JUnit style test cases. So, there is a test case called GWTTestCase, and if you can create a test case that extends that, then it can automatically run within a JUnit test furnace. Actually it runs in two modes, which is interesting. So, to run as bytecode, normally, like it is very much the JUnit analog of hosted mode. So, you actually can debug your test cases, you can step through them, you can figure out what is going on if you are doing test-driven development. It is important for your test not only just to sort of run in batch mode, but you often want to be able to step through the tests one line at a time. So, there is a hosted mode version of our JUnit integration support, which works well. And then, my favorite feature is that there is also a webbed version. So, web mode is what we call it when you deploy your application as JavaScript. There is a web setting, basically flagged to the JUnit test runner that will actually cross-compile your application, your test case, I should say, and deploy it to a browser, and then still it will execute your test and use RPC to report back the results to the test runner. So, from your perspective as the guy running the test, it looks as if it is just another test runner instance, but actually what is happening is a lot more interesting underneath the scene. It actually cross-compiles and deploys and runs it in the real environment that you would deploy your application code in. And then, there are additional capabilities of that same architecture that allow you to deploy to other browsers. So, for example, you can start a JUnit test run and point that test runner at a Mozilla form, for example or Internet Explorer form or Safari form. So, it makes it really easy to test all these different browsers in situ. So, we found that it really makes cross value testing a whole lot easier.

    Threaded Messages (11)

  2. I have only one important question so far. Why Google does not use GWT to develop the own services on the google.com? The new services are introduced since the May 2006, but none of them are based on GWT. In general, GWT still misses the rich component set (aka Widgets) like any other libraries such as Backbase, ADF/Trinidad, QuipuKit for java or telerik for .net. Only the primitives are not enough for starting a rapid development. =AlexaW, http://ajax-tutorials.com
  3. Which new services? picasa web? google docs & spreadsheets? google maps? Cyril
  4. http://www.thinwire.com also has richer widgets and is open source.
  5. In general, GWT still misses the rich component set (aka Widgets) like any other libraries such as Backbase, ADF/Trinidad, QuipuKit for java or telerik for .net. Only the primitives are not enough for starting a rapid development.
    but good enough to start GWT!
  6. Dojo?[ Go to top ]

    And why not just join DOJO support group.
  7. Re: Dojo?[ Go to top ]

    And why not just join DOJO support group.
    Is Dojo written in Java??
  8. Re: Dojo?[ Go to top ]

    no
  9. Re: Dojo?[ Go to top ]

    And does Dojo (or any of the other toolkits implied here by previous commenters to be better choices) include a server side portion, with object serialization, while starting from Java and emitting cross browser JavaScript? GWT is not meant to compete with purely JavaScript based client side only AJAX solutions, many of which are really damn good. This includes Dojo, Sciptaculous and so on. Instead GWT is a different approach, starting from Java, and it ALLOWS you to integrate those other JavaScript libraries using it's JSNI mechanism, something that is commonly done. And GWT does not try to have as many fancy UI widgets as do the others. That is not the point of GWT. What is the point is a solid and robust set of core widgets, in a *toolkit*, which you can then use to build upon to create more involved widgets yourself (or you can grab one of many third part libraries that already do lots of this, GWT Widget Library, GWT tk GWm, etc). GWT is not analogous to all the other things it's being compared to here. A better analogy would be to Echo2, which does also start from Java (and is itself also very impressive). Yet even that takes a bit of a different tact and is more server side focused (with a ClientEngine, but not the same as bulk on the client like GWT). GWT is significant, it is a move back towards a "rich client" but also inclues an RPC portion (to facilitate another tier) and has the advantages that it starts from a non idiomatic, non dynamic language, while still using the ubiquitous "browser" as the base. Again, all those other JavaScript AJAX libraries are fantastic for what they do, but they do not solve the same problems as GWT.
  10. Re: Dojo?[ Go to top ]

    Probably some might use GWT. Personally I would prefer to write UI straight in JavaScript with full control on things than write Java code against some framework and auto generate JavaScript from it. I just cant see how you can write serious application with auto generate Java.
  11. Great idea![ Go to top ]

    Develop in Java, deploy in JavaScript/HTML. GWT is a typical Google product. It centers around usability and user experience, not around abstract 'concepts'. Emphasis is placed on convenience and manageability for the user (the developer in that case). 'Monolithic' compilation is a feature in that concept, not a burden (contrast that to frameworks that foster XML configuritis). One (minor) problem (which is mentioned in the interview) remains. GWT may not be 'forward' compatible, i.e. you may need to re-compile your code after major browser releases. I hope the GWT team will some day find a JavaScript/HTML subset that is both Standards-(W3C-)conforming and usable for all major browsers. BTW, I've already seen a job offer requiring experience with the 'Google Framework'.
  12. Great tool![ Go to top ]

    After downloading GWT yesterday, buying and reading the online book from Ed Burnette, and having a quick run through the examples, at first glance, I'm very impressed by the product. The original GWT concept is particularly interesting and I have a feeling that this is the right approach for RIAs. Learning curve is close to flat, especially for someone experienced in Swing and who knows the way AJAX works. Being in Java first, it can be unit-tested, performance-tested, properly documented. The AJAX and cross-browsers JavaScript intricacies are hidden, so are the hassle of the Back/Forward button, validation, error messages and internationalization. It really looks like a great tool to design and deploy rich GUIs as far as productivity is concerned. I'll look deeper into it. The only missing area is the way security is handled (authorization that is). If anyone has advices in that respect, I'd gladly listen. Congrats to Bruce Johnson's team in any case! Yann