Google redefines Ajax, again

Google redefines Ajax, again

Summary: Wouldn't it be nice if you could write, test, and debug your application using a normal client-side development environment and then just press a button to make it run inside any web browser? That's the promise of the new Google Web Toolkit (GWT).

TOPICS: Google

Back in February I wrote:

"I think most people are just going to be sporting band-aids until we're all wow'ed by a better, hopefully simpler, solution."

I was writing about how nobody seemed to have quite figured out Ajax besides Google. Today at JavaOne they both proved my point and gave us a better, simpler solution. Enter the Google Web Toolkit (GWT).

Simply put, GWT lets you forget you ever heard about Ajax, DHTML, and JavaScript. Forget browser incompatibilities (and maybe someday even forget about having to write every application twice, once for the web and once for the desktop). What do you have to remember? How to program in Java.

What you do is: write, test, and debug your application in Java using Eclipse ("hosted mode"), and then as a final step, "compile" it into "browser machine code" (aka JavaScript). Command line utilities are available but it's easiest in Eclipse. According to Google,

"Generally speaking,

  1. If your GWT application compiles and runs in hosted mode as you expect
  2. And GWT compiles your application into JavaScript output without complaint,
  3. Then your application will work the same way in a web browser as it did in hosted mode."

It's not a totally new idea, but as with many things on the web, Google executes it better than anybody else. And, because it's Google, everybody is ga-ga over it. Just look at the new GWT forum; in the past day it has acquired over 500 members and over 350 posts.

Will this work? Judge for yourself by running the sample applications in your browser (no downloads required), or by checking out the GWT SDK.

Topic: Google

Ed Burnette

About Ed Burnette

Ed Burnette is a software industry veteran with more than 25 years of experience as a programmer, author, and speaker. He has written numerous technical articles and books, most recently "Hello, Android: Introducing Google's Mobile Development Platform" from the Pragmatic Programmers.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Impressive, but not the only show in town

    The demos on the Google site are impressive, as with nearly everything AJAX based for us long time web developers, but it isn't anything I haven't already seen included in either ASP.Net 2.0 with the Atlas add-on. It seems like Microsoft and Google are on the same track, but all the hype is over the Google offerings..
    • Hyping google

      Get over it. Although there are similar toolkits that were available for working with AJAX for Java before this, the one from Google is "more hyped"....thus, the excitement ;-)
      • Different from echo2

        GWT has a fundamental difference from Echo2 in that all your logic can run on the client side. You have the option of making RPC calls to the server if you want, but it's all client driven.
        Ed Burnette
  • Java on client is dead

    Too many flavours, too many issues - in an uncontrolled environment (i.e. the client) it becomes unusable. We've recently removed all java client code from our applications because our clients find managing the varieties of JREs too difficult.

    Ajax, while not very powerful, and IMHO a trully horrible interim fudge technology, has simply become the best way to keep client deployment manageable.

    The first, and most significant thing Sun can do to get people back to considering Java on the client is to opensource it. Then developers can actually see why things are behaving differently on different JVMs, and work around them properly rather than through guesswork - but it's still a lot more effort than a nice clean predictable runtime environment.

    Java on server is of course still good stuff.

    On the VB side of things, the compiling of VB code to target the JVM is an interesting idea. MS wants the considerable number of VB6 coders to convert to .Net and the vb6 coders feel hard done by: there is market share to be poached.
    However VB is popular because of its "simple to get to grips with" forms+controls based development paradigm. People who develop non GUI style business logic, or large scale, well designed systems, aren't generally fussed about what language they use to implement things anyway.
    If we're really saying that a VB6 GUI application using 3rd party activeX controls will run without any modification on a linux box on PPC architecture, then congratulations! If however you're just using the VB gui to create java byte code using JDK libraries - this is not really exciting, and is a quite limited market (Appforge I beleive used to do something similar).

    Oh, what I'd give for a single, standard, truly secure, powerful, manageable, 100% cross platform, client VM! It's really got to happen at some point, but there's just nothing presently available.
    • Ooops - wrong topic

      Off I go on a rant, again, and I don't even check it's the right topic. How did I end up commenting on an article about Google's use of Ajax, this was supposed to be a comment on Sun's Java roadmap announcements... I hope nobody thinks I don't know that Javascript and Java are totally different things!

      If there's a moderator around - can you get rid of the post, ta.
      • Java

        You have no idea what you're talking about: Javascript and Java are not the same things.

        And that goes double for your rants on "client" Java (what the heck does that mean - applets? standalone Swing/SWT apps?)
        • Read the story

          Next time read the story before flaming. The point is you have to write the thing in Java (ugggh) and then it gets 'compiled' to Javascript.

          As to client side, he could be talking about that god awful Sun JVM that tries to update every week and makes glaciers look speedy.
  • Blah blah blah. Google is king. Blah blah blah.

    Mr. Burnette, I usually respect your writings, I had the idea that you knew what you were talking about, definitely in the world of Java. I see now that I was grossly mistaken. Would you use a "C++ to Perl" translator? NO! Why? Becuase it's a moronic idea! This is exactly what GWT does. EXACTLY WHAT IT DOES. Translates Java to an AJAX system. Not only is AJAX lousy to begin with, and Java is nothing special (not bad, just no outstanding reason to use it, it is a general purpose language and that is it). Why would I use a ho-hum language to generate "JFC that code is horrible!" code?

    If this announcement or product had come from, say, Microsoft, or even Sun, would anyone care? No. Why? Because this kind of thing is bloody useless. It's like offering a sale at a car dealership for a Yugo. "We make it easy to get behind the wheel of the Yugo of your dreams!" AJAX is the Yugo of programming techniques.

    Justin James
    • We'll see

      Lots of ideas have come and gone so time will tell. But I disagree that it's the same as a C++ to Perl translator. What would be the point?

      If GWT works as advertised it could be incredibly useful. Java is much better understood, much less fractured, and far easier to debug and test than JavaScript. And note that it's possible the same technique could be used for other languages like C# in the future.

      I would have thought it was impossible if somebody hadn't done it already. It doesn't matter to me who did it, but the fact that Google did it does lend it more credibility than any random company.
      Ed Burnette
  • none of the examples i tried work in ie7 beta...

    ...or at least the version i am currently running. javascript errors galore. good times.
    • Same here

      I wonder what kind of javascript microsoft is implementing in ie7? Can anyone cofirm that it works in ie6?
      • It works in IE6

        Ed Burnette
    • And thus...

      ... I describe AJAX as "the Yugo of programming techniques." Too many browsers implement too many different variations of JavaScript. Even ZDNet throws out JavaScript errors at me. For anything but the most rudimentary code, you need to write, test, and maintain at *least* three versions of the code. If your code base is big enough to be considered an "application", is this really what you want? You may as well write a Windows, Mac, and Linux version of a desktop app at that point...

      Justin James
      • This just proves my point

        Who wants to write three versions of your code? If you want interactive web applications it's almost required that you use some kind of framework that somebody else maintains, whether it be dojo or or GWT or whatever, unless you have the resources to spend months or longer discovering and addressing all these weird variations.

        IE7 not working is a known problem and a fix is in the works.
        Ed Burnette
        • Proves both of our points, actually. :)

          Your point is that this is awesome because AJAX is so hard to write, due in large part to browser compatability problems. My point is that this is irrelevant, because AJAX should not be used, due in large part to browser compatability problems.

          This is fine (as is AJAX) for dinky things. Anything complex enough to have browser compatability problems on a large scale is not going to handle a Java-to-AJAX tranalation anyways, requiring you to hand-tweak the code that is produced. In other words, you are still stuck maintaining a million different versions.

          When JavaScript runs about as fast as Perl or Ruby, and is as cross platform compatable as either of those two languages, I will be much more accepting about AJAX. Until then, the AJAX groupies need to stop cheering on the endless flood of lame, POS mashups and what not, and start hounding the browser vendors to produce browsers that can actually use AJAX.

          Justin James
  • Awful

    While I applaud the effort as a programming exercise, the result explains why Google's interfaces look so crappy.

    Nor is it anything new, there are plenty of players offering better interfaces with Javascript files.

    It's a browser not an operating system or a VM. For god's sake, stop trying to turn a pig's ear into a silk purse - it isn't going to happen.

    Have a look at the scroll panel in the layout widgets. It's supposed to scroll the text - it doesn't of course. You have to make your browser quite small for the autoscrolling to come in. This is the problem with the browser (at least from my perspective of developing eLearning) your user doesn't see what you design and your once simple interface becomes a scrollable nightmare. This is apart from the other browser problems of security restrictions, security messages, net unreliability, server load etc etc. The unsuitability of the browser has led most of eLearning to now be delivered as (shudder) Flash.

    Frankly I'll take .Net or a web enabled desktop app - at least I have a Visual IDE and I don't have to touch Java.
  • Too bad for the license...

    Good stuff, but too bad the license is so... mmmh... closed.


  • RE: Google redefines Ajax, again

    I really enjoyed reading this post !!!have bookmarked <a href="">w</a><a href="">e</a><a href="">b</a><a href="">s</a> will come back to read more.