Bindings, Platforms, and Innovation
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
Tracking change and innovation in the enterprise software development community
Posted by Scott Delap on Aug 11, 2006 04:11 PM
Version 1.1 of the Google Web Toolkit has just been released. New features include:
InfoQ sat down with GWT Tech Lead Bruce Johnson to discuss the new release. He indicated that they were very excited at the number of developers who have subscribed to the GWT Google Group (over 3500) and downloaded the developer SDK. In response to why the GWT approach of compiling Java into Javascript was favored versus providing a pure Javascript library Bruce responded:
The primary motivation was the number of great Java development tools. Capabilities like context-sensitive code completion and global refactoring are vital to keeping your code base healthy during rapid development. And then there are tons of other mature Java-centric tools you get to use with GWT, like JUnit, Clover, JProfiler, Javadoc, FindBugs, Maven, and lots more.In regard to why Google didn't take the route of leveraging pure Java on the client and promoting wider distribution of the Java Plugin and Java Webstart instead:In terms of the two languages, JavaScript is very flexible, which is a real strength for rapid development. That same flexibility can become a liability as your project becomes larger, requiring more engineers to work on a shared code base. For example, there are a variety of ways to implement OO concepts in JavaScript, each having different memory, speed, and maintainability tradeoffs. In big JavaScript code bases, you can end up spending as much time fiddling with the mechanics of the JavaScript code style as you do on the application logic itself. Java doesn't have this issue; classes and interfaces are well-defined concepts that just work.
We wanted to enable developers today. At the moment, JavaScript/DHTML seems to be the one "platform" common to all browsers.
Bruce indicated that the new localization support in the 1.1 release is interesting, because under the hood it leverages some of GWT's more advanced code-generation facilities. It allows you to define large numbers of localized messages, but only the ones you actually use in your application get compiled. This keeps you application very lean. He also meantioned that GWT's automatic dead-stripping of unused code is an example of why it's a genuine benefit to have a compiler in the mix versus a handwritten JS library.
When you write JS libraries by hand, maintainability (e.g. comments and descriptive identifiers) and minimizing script size can be somewhat conflicting goals.Another key feature in the new release is simplified JUnit integration that allows the ability to unit test asynchronous RPC calls in both hosted mode and web mode. The one major feature desired by developers but not included in 1.1 is hosted OS X support. Bruce indicated that he's forced himself to use OS X in order to feel developers pain and be a daily reminder to implement it as soon as the schedule allows.
The conversation then switched gears to talk about the various GWT widgets that have sprouted up since the initial release:
[I like the fact] that there are a lot of them and that they are actually easy to create and reuse. I also get a kick out of seeing GWT libraries that interoperate with great JavaScript libraries like scriptaculous using GWT's JavaScript Native Interface (JSNI). We never wanted anyone to view GWT as mutually exclusive with JavaScript, which is why we introduced JSNI...you can decide which code you want to write in Java and which code you want to write in JS, then easily stitch them together.The conversation finished by discussing the possibility of open sourcing the GWT Javascript compiler so developers using GWT could provide bug fixes and enhancements:
We've talked about that possibility from the beginning, so yes. Open-sourcing the tools right now could be more of a distraction than a help. It wouldn't serve GWT users if we took our eye off the ball by starting lots of discussions about the plumbing of GWT when we want to be focusing on making GWT the best it can be for developers. We'll periodically revisit the question as GWT evolves a bit more.
5 Ways to Ensure Application Performance
Performance Management and Diagnostics in Distributed Java and .NET Applications
Download the Free Adobe® Flex® Builder 3 Trial
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
This article explores the use of JBoss and jBPM to implement design solutions that effectively address the issue of orchestrating long running activities.
This presentation covers the use of graph databases as an optimal solution for data that is difficult to fit in static tables, rapidly evolving data or data that has a lot of optional attributes.
This session introduces Real Options and shows how it can help in running your project. Real Options is a decision-making process that can be used to manage risk.
This article discusses the use of bindings on services and references (including the instance of non-configured bindings) as the means to implement SCA communications in a Web and SOA environment.
After a short introduction to DSLs, Scott Davis plays with the keyboard showing how to approach the creation of a DSL by typing working snippets of Groovy code that get executed.
IBM Rational and InfoQ present, Scaling Agile with C/ALM, an eBook showing organizations how to become “finely tuned software delivery machines” by enabling team integration and scaling.
Amanda Laucher presents a real life enterprise application written in F#. She shows actual code snippets, explaining design decisions and suggesting how to use some of the F# constructs.
No comments
Watch Thread Reply