Dr. Axel Rauschmayer is a freelance software engineer, blogger and educator, located in Munich, Germany. Axel is a DZone MVB and is not an employee of DZone and has posted 246 posts at DZone. You can read more from them at their website. View Full User Profile

What is the Appeal of Ajax and GWT?

07.03.2009
| 9346 views |
  • submit to reddit

Ajax does have its detractors. Their argument goes as follows: Why reinvent everything that has already been done on the desktop on an inferior platform? I do agree that the attraction of Ajax is subjective (i.e., not based on technological arguments). This is obvious whenever I’m excited about something web-based, show it to non-developer friends and their only reaction is boredom. Then I realize that while I’m excited about what’s possible on the web, they have already seen it on the desktop. But—there are some good arguments in favor of Ajax. My reasoning goes as follows:

  • I love web applications (because I use 3 different computers having data travel with me is great).

  • I’ve always disliked Applets and Flash. With advanced browser use (tabs, drag&drop of links, etc.), anything that is not well integrated feels constricting.

  • Mobile applications: Web applications are currently the best solution if you need something that runs on the smartphone platforms Android, iPhone, Palm Pre, and Blackberry. The browsers on all of these platforms are WebKit-based, making testing less of a chore. Windows Mobile 6 is out there, too, but feels dated now, and I'm not sure how capable its browser is.

  • There is tremendous momentum behind the browser as a platform. New user interface ideas are constantly being tried out, JavaScript is getting really fast, gains lots of APIs (geolocation comes to mind), etc.

Using GWT to write Ajax applications has the following advantages:

  • Compared to desktop Java: GWT makes programming web applications almost as simple (in some cases simpler) as programming Swing. So why not use it?

  • Compared to other Ajax solutions: GWT has Java's superior tooling, one has a single code base for client and server, and GWT’s compiler produces highly optimized code (due to Java’s static nature).

 [Update: clarified that I meant that mobile browsers are Webkit-based, not their platforms.]

From  http://2ality.blogspot.com

Published at DZone with permission of Axel Rauschmayer, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Greg Brown replied on Fri, 2009/07/03 - 8:17am

> I love web applications (because I use 3 different computers having data travel with me is great).

I don't think HTML or AJAX offers any particular advantage here, unless you don't have control over what is installed on those 3 computers. Then, the argument for HTML makes more sense.

> I’ve always disliked Applets and Flash. With advanced browser use (tabs, drag&drop of links, etc.), anything that is not well integrated feels constricting.

There's no reason (with applets, anyways - not sure about Flash) that you can't achieve nearly seamless integration with the native desktop.

> Mobile applications: Web applications are currently the best solution if you need something that runs on the smartphone platforms Android, iPhone, Palm Pre, and Blackberry. All these platforms are WebKit based, making testing less of a chore. Windows Mobile 6 is out there, too, but feels dated now, and I'm not sure how capable its browser is.

I don't think it is accurate to say that these platforms are "WebKit based". Android has it's own GUI SDK, as does the iPhone. Blackberry is Java ME. As far as I know, the Pre is the only one that is truly web-based (not sure if it actually uses WebKit under the hood or not).

> There is tremendous momentum behind the browser as a platform. New user interface ideas are constantly being tried out, JavaScript is getting really fast, gains lots of APIs (geolocation comes to mind), etc.

Again, no particular advantage to AJAX here. In fact, it is often easier to try new UI concepts and technologies in a richer platform like Flash or applets.

>Using GWT to write Ajax applications has the following advantages: > Compared to desktop Java: GWT makes programming web applications almost as simple (in some cases simpler) as programming Swing. So why not use it?

I agree that using GWT to write AJAX applications has some advantages. The main reason why I wouldn't choose GWT over Swing is that GWT applications don't run in the JVM, and don't get all the benefits thereof.

> Compared to other Ajax solutions: GWT has Java's superior tooling, one has a single code base for client and server, and GWT’s compiler produces highly optimized code (due to Java’s static nature).

I'd argue that, if you are looking for superior tooling and a superior (rather than simply acceptable) end user experience, you should actually be looking at the plugin based RIA toolkits, and not GWT at all.

In all, I don't think these are very strong arguments for GWT. I do think that GWT is a good way to build AJAX applications. I just don't think it is a good way to build *Java* applications, or even rich client applications in general. The browser != the JVM. No matter how slick the development experience is, the runtime environment is not as good.

Andrew McVeigh replied on Fri, 2009/07/03 - 9:19am in response to: Greg Brown

In all, I don't think these are very strong arguments for GWT. I do think that GWT is a good way to build AJAX applications. I just don't think it is a good way to build *Java* applications, or even rich client applications in general. The browser != the JVM. No matter how slick the development experience is, the runtime environment is not as good.

i've spent many years writing swing apps, and recently a bit of time writing GWT apps.  the runtime of GWT obviously isn't as good (javascript vs JVM), but the client-side deployment effort is nil compared to great pain for Java.  how many years have we grappled with the need to roll out lots of thick client upgrades across lots of computers, and handling multiple versions of an app?

this, and centralised data, is so compelling that people even use ajax and webapps when it doesn't make sense for other reasons.

normally, i look at the interactivity required for an app and decide whether it should be a swing app or a webapp based partly on that.  if the interactivity is high, definitely swing.  however, GWT has shaken things around a bit.  it's made the space for swing that much smaller.

of course, things like CASE tools are much better as thick client apps.  but there may come a time...

Andrew

Axel Rauschmayer replied on Fri, 2009/07/03 - 9:46am in response to: Greg Brown

@Greg Brown:

Especially with 6u10, applets are really cool. Pro-GWT arguments do hinge on the premise that Ajax apps are worth the effort. With applets, apart from installed base, it is the little things that make them feel ever so slightly out of place. Even now, knowing about the inferiority of the web platform, I sometimes prefer it to Swing+JVM. And I think the best for browsers is yet to come. It has an amazing amount of momentum and enthusiasm behind it, so eventually, there will be things that the JVM doesn't offer. Note that that kind of momentum is never due to technical reasons. Java owes its popularity to a similar kind of momentum, otherwise we'd all be using Common Lisp or Smalltalk.

Greg Brown replied on Fri, 2009/07/03 - 9:41am in response to: Andrew McVeigh

the runtime of GWT obviously isn't as good (javascript vs JVM), but the client-side deployment effort is nil compared to great pain for Java. how many years have we grappled with the need to roll out lots of thick client upgrades across lots of computers, and handling multiple versions of an app?

If you are talking about local app installation and management, then I agree. But we're talking about applets (or Flash apps) here. IMO, ease of deployment is the main argument for using applets.

Greg Brown replied on Fri, 2009/07/03 - 9:52am in response to: Axel Rauschmayer

With applets, apart from installed base, it is the little things that make them feel ever so slightly out of place.

I'd argue that this is the fault of the applet developer. There's nothing intrinsic to the Java platform that prevents an application from providing a well-integrated experience.

And I think the best for browsers is yet to come. It has an amazing amount of momentum and enthusiasm behind it, so eventually, there will be things that the JVM can't offer.

For some applications, I agree. HTML is, and will probably continue to be, the best platform for delivering document or page-centric applications. However, for richer interactivity (i.e. true GUI applications), the DOM is pretty limiting. The <canvas> tag has some potential to alleviate this, but, as far as I know, MS doesn't have any plans to support it, which pretty much makes it useless.

Olivier GERARDIN replied on Fri, 2009/07/03 - 9:54am in response to: Greg Brown

> I love web applications (because I use 3 different computers having data travel with me is great).

I don't think HTML or AJAX offers any particular advantage here, unless you don't have control over what is installed on those 3 computers. Then, the argument for HTML makes more sense.

Even if you do have control over what's installed on these computers, you still have to install stuff. The whole point of web applications, and especially AJAX ones, is that there is nothing to install: the browser is the platform.

 

> There is tremendous momentum behind the browser as a platform. New user interface ideas are constantly being tried out, JavaScript is getting really fast, gains lots of APIs (geolocation comes to mind), etc.

Again, no particular advantage to AJAX here. In fact, it is often easier to try new UI concepts and technologies in a richer platform like Flash or applets.

 I think the point was not about trying things in AJAX, but to show that the browser as a platform is making constant progress. I can also cite video support in HTML 5 which is a key point, or server-push technologies, etc.

 

>Using GWT to write Ajax applications has the following advantages: > Compared to desktop Java: GWT makes programming web applications almost as simple (in some cases simpler) as programming Swing. So why not use it?

I agree that using GWT to write AJAX applications has some advantages. The main reason why I wouldn't choose GWT over Swing is that GWT applications don't run in the JVM, and don't get all the benefits thereof.

What benefits are you talking about here? Platform independance? GWT gives you that too... Security? JavaScript is sandboxed just as Java running in a JVM. Speed? The latest JavaScript engines (check Chrome for example) are so optimized that they run compiled GWT much faster than the hosted mode runs Java bytecode.

As much as I like Swing, the key winning point for GWT is not about the JVM, is that it runs in a browser with no installation at all.

 

> Compared to other Ajax solutions: GWT has Java's superior tooling, one has a single code base for client and server, and GWT’s compiler produces highly optimized code (due to Java’s static nature).

I'd argue that, if you are looking for superior tooling and a superior (rather than simply acceptable) end user experience, you should actually be looking at the plugin based RIA toolkits, and not GWT at all.

If you think GWT produces a "simply acceptable" user experience, you haven't seen a GWT powered application in a long time. In addition to forcing your users to install and maintain a plugin, plugin-based clients force you to learn a new development environment, a new language, new tools... while GWT allows you to keep using the Java tools you know and love, and use your Java team skills.

 

In all, I don't think these are very strong arguments for GWT. I do think that GWT is a good way to build AJAX applications. I just don't think it is a good way to build *Java* applications, or even rich client applications in general. The browser != the JVM. No matter how slick the development experience is, the runtime environment is not as good.

GWT is not a way to build Java applications.. it's only a way to build clean, efficient, maintainable, debuggable AJAX applications with the comfort of a mature object-oriented development environment. The runtime environment may not be "as good", but the truth is: for web applications it doesnt matter, because it's more than good enough for what we want from it, which is to smoothly run the JavaScript we feed it. And I'd rather generate this JavaScript with GWT than any other way.

Axel Rauschmayer replied on Fri, 2009/07/03 - 10:16am in response to: Greg Brown

With applets, apart from installed base, it is the little things that make them feel ever so slightly out of place.

I'd argue that this is the fault of the applet developer. There's nothing intrinsic to the Java platform that prevents an application from providing a well-integrated experience.

Short list of little things:

  • Copy any text on a page easily.
  • Drag and drop links in the page to another tab.
  • Control/Command-click to open a link in a tab behind the current one.
  • Embedded HTML (for marked up text, SWT is good at this, Swing will need JWebPane)

Are these possible with applets? If so, my “don't integrate well” argument goes away. Installation is still a small problem, though: I would want to use Java 6u10 and that would not currently allow me to target a large share of Intel Macs (those with 32bit processors). I do expect that problem to be solved with Snow Leopard, but with Apple, one never knows.

MS has made some strides to support standards, so I'd hope that they would eventually support Canvas.
More thoughts on platforms: “What should be the platform of your next application?”.

Greg Brown replied on Fri, 2009/07/03 - 10:27am in response to: Olivier GERARDIN

The whole point of web applications, and especially AJAX ones, is that there is nothing to install: the browser is the platform.

Again, I don't see a strong argument here. Don't forget that the browser itself often needs to be installed, or at the very least updated. From my experience, users who do have control over their systems don't seem to have a problem downloading and installing multi-megabyte updates to browsers, iTunes, the OS, etc. So installing a 12MB Java plugin really isn't much of a burden/issue.

In addition to forcing your users to install and maintain a plugin, plugin-based clients force you to learn a new development environment, a new language, new tools... while GWT allows you to keep using the Java tools you know and love, and use your Java team skills.

For Flash/Flex, this is true. But the same argument can't be made when comparing GWT to Swing, since both are already Java-based.

I'm not saying that there's no place for AJAX apps, or no place for GWT. I just don't think that GWT/AJAX is the best way to address all UI use cases, just like Swing, Flash, etc. isn't the answer to all UI needs.

Andrew McVeigh replied on Fri, 2009/07/03 - 10:54am in response to: Greg Brown

If you are talking about local app installation and management, then I agree. But we're talking about applets (or Flash apps) here. IMO, ease of deployment is the main argument for using applets.

It's a fair point, but for me the following serve to invalidate that argument.

1. strange JNLP version errors

2. webstart locking up the browser  --> happens to me all the time, particularly with citrix

3. (the killer) poor (or no) interaction with the surrounding webpage(s)

Andrew McVeigh replied on Fri, 2009/07/03 - 10:59am in response to: Greg Brown

I'm not saying that there's no place for AJAX apps, or no place for GWT. I just don't think that GWT/AJAX is the best way to address all UI use cases, just like Swing, Flash, etc. isn't the answer to all UI needs.

No, of course it's not the only answer.  it's one of many.

The benefits in practice though are pretty compelling.  There are quite a few downsides though, many of which GWT addresses.  I was contemplating the crazy history of web technologies the other day, and wondering what people would have come up with if they had known at the start where it was all headed.  they certainly wouldn't have made the frankenstein hmtl/versions/dhtml/css/javascript beast we have now, with poor drawing support.

Otengi Miloskov replied on Fri, 2009/07/03 - 11:09am

@Greg Brown We know all in this planet nothing is perfect, all software have bugs and there is a right tool for the job we all know that that that, we dont need to repeat all this bs all over again and again.

But its that GWT rocks for building Ajax applications using the Java language thats all the point of this article. you dont need to start a war or fight saying your tool is better than mine and so on is getting so stupid.

Java standalone swing apps have their place(My personal choice is SWT or with C++ Qt). And Ajax apps with GWT have their place too and are very attractive in this exciting times.

2c.

 

Greg Brown replied on Fri, 2009/07/03 - 2:13pm in response to: Axel Rauschmayer

> Copy any text on a page easily.
> Drag and drop links in the page to another tab.
> Control/Command-click to open a link in a tab behind the current one.
> Embedded HTML (for marked up text, SWT is good at this, Swing will need JWebPane)

As I said earlier, I think it's all about choosing the right tool for the job. These are all document-centric features. I don't know what your specific use case is, but it sounds like HTML might actually be a good fit for your needs. However, for more GUI-centric applications (i.e. where a richer widget set is required), an RIA toolkit is probably a better choice.

Greg Brown replied on Fri, 2009/07/03 - 2:18pm in response to: Andrew McVeigh

If you are talking about local app installation and management, then I agree. But we're talking about applets (or Flash apps) here. IMO, ease of deployment is the main argument for using applets. It's a fair point, but for me the following serve to invalidate that argument.
1. strange JNLP version errors
2. webstart locking up the browser --> happens to me all the time, particularly with citrix
3. (the killer) poor (or no) interaction with the surrounding webpage(s)

I agree that Web Start is a mess. But again, we're talking about applets, not JNLP. :-)

J6u10+ is pretty solid, especially for web page integration. I think it makes applet deployment quite realistic.

Greg Brown replied on Fri, 2009/07/03 - 2:34pm in response to: Otengi Miloskov

you dont need to start a war or fight saying your tool is better than mine and so on is getting so stupid.

Where do I say anything of the sort? You must have missed the part where I said "I do think that GWT is a good way to build AJAX applications". Or the part when I said "HTML is, and will probably continue to be, the best platform for delivering document or page-centric applications". All I did was counter some of the author's points. Isn't that the point of allowing readers to comment on these entries?

Andrew McVeigh replied on Fri, 2009/07/03 - 3:07pm in response to: Greg Brown

J6u10+ is pretty solid, especially for web page integration. I think it makes applet deployment quite realistic.

the only applets that i've ever seen that i rated in the slightest were from pulpcore.  that's a pretty savage indictment after 10+ years of applets...  i have no idea why sun couldn't make the applet startup process as slick as pulpcores.  btw - j6u10 doesn't offer quickstart under linux :-(

applets might be able to talk to things on the page, but it's like flash -- i.e. you have a big fat flash widget or applet sitting in the middle of the page and any html is an afterthough.  it doesn't fit into a multi-page model and you lose all the good stuff where you can mix and match widgets and presentational content easily and involve creative designers in the process. and that i think is one of the reasons that html is so successful.  it's like half way between a widget set and a DTP package.

i'd never recommend to anyone that they deploy their app as an applet.  all my bad experiences have conditioned me to believe that it will never get better.  nothing i've ever seen (apart from pulpcore which is impressive, but nonstandard) has given me the slightest glimmer of home here.

it could have all been so different.  imagine what could have been if sun had early on standardised the liveconnect and dom manipulation stuff and concentrated on that.

 

Thierry Milard replied on Fri, 2009/07/03 - 4:50pm

  i have no idea why sun couldn't make the applet startup process as slick as pulpcores.  btw - j6u10 doesn't offer quickstart under linux :-(

 

===> I have an Applet under windows. And it's not that fast at all. I would dare say startup is bloody too slow. 15 seconds in a 2 year old Pc :Just too much. 

In a way it is quite funnny to look back at what Sun has done in the last 4 years. That have made development easier and better lookin then Swing : Called it javaFx.

So  yes Sun-java was ready for web-cool-ajax-or-flash-like development embeded in web page.

- "Web here i Come" says Sun to us web developers !

But at the same time the ...........................................still................. much  too long startup process of jvm  just makes it impossible to choose java-or/and-javaFx on the Web-front-end  application (even with java-1.6_14).

 Just like if Ford had made a super beautifull-car with lots of horse power and a low price ..... but with a fuel consomtion 20 times the average car. Just impossible to sell.Yes sometimes "small mistakes" seems so enormous to us.

 Thierry

 Ps: By the way I decided to stop java-Applet development. I am now learning Flex and android and GWT. Everything seems so simpler on these platform. Maybe sun did take way too much time to understand that simplifying the developer task is simply a good target for us.

Dimitris Menounos replied on Mon, 2009/07/06 - 5:27am

You can put lipstick on a pig, but it's still a pig. JVM, has always been both a strength and a problem. It is too huge and hence slow. 15 years later still chokes much too many resources on a modern computer for what supposedly be a "thin abstraction layer". Quickstarter is nice but a hack nevertheless. Thankfully, via Google's innovations, the language was reincarnated and is now free from the dead weight (which will continue to prosper on the server along with COBOL).

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.