Is Google Web Toolkit useful to develop complex javascripts?

Question

Iam a great fan of javascript frameworks especially jQuery .I have always wanted to design sites like "plurk.com" but i know that it needs very huge lines of javascript.so that shut me off.But since i came to know GWT , i really want to test it out and want to ask you if it makes our job easier to develop complex things than with the javascript or its frameworks .Which one would you prefer ?

Answer 1

Few things scare me like "generated Javascript". The Law of Leaky Abstractions has got to be doubly true in these cases.

Writing effective cross-browser javascript is a tricky process of continuous refinement. Trying to decipher where some generated, obscured Javascript is going wrong is a major headache. It's bad enough fixing bugs in the pure JS libraries.

To me, GWT is a trick aimed at allowing backend developers to write front-end, in-browser code. Unfortunately, the realities of modern web apps mean you just have to know Javascript and the DOM. Something's going to break, and you're going to need to know why.

I think you're better off picking a good javascript library like jquery or prototype, and learning that well. Those libraries abstract away the sort of stuff that SHOULD be abstracted away and is unlikely to break in edge cases, like array operations and AJAX requests.

Answer 2

I think a few of the answers on this question are quite un-informed, and I suspect that the people answering them have never used GWT on large scale projects. Yes GWT is a great way to do large AJAX websites, and for large complex sites, involving a back end as well, it kicks things like JQuery up and down the park. The way I always look at it is that javascript on it's own is great for doing small client side things. When you need to do something more complex (like dynamic fields, popups, animations) you bring in something like JQuery or Prototype. When you want to take it one step further you go with GWT.

People assume that because you write it in Java, it's designed for back end developers to do front end development. It's not. Java is simply the language that they chose, mainly because it's widely used, statically typed and there are lots of good editors out there for it.

I don't buy the leaky abstraction theory either, it doesn't try to fully abstract out the HTML elements, as it gives you direct access to both native javascript and the DOM if you choose to use those.

In short we've built very complex sites (one of which was featured on the GWT blog) in GWT, and also using other libraries like JQuery. I can tell you with 100% confidence that once you get your head around GWT it kills those other frameworks dead for complex tasks. It also has some great built in things that help make things better, and even does some things that no other framework supports (like the magic it can do with images). See this blog post for more details:

http://googlewebtoolkit.blogspot.com/2007/10/epo-builder-built-with-gwt.html

Answer 3

Yes, it does, since you'll be using Java and not Javascript.

Superb IDEs, static code analysis, searching and refactoring - all this will make your life much easier on large projects.

Answer 4

No. It doesn't.

It doesn't remove the complexity, it just makes it possible for you to deal with it from a Java Perspective. Since that gives you all the Tooling available from Java... that alone might make it worthwhile.

JavaScript IDEs are getting better and better though, and typically if you're using a Framework like jQuery or Prototype, then you're probably going to find it easier than dealing with a heavy weight abstraction layer like GWT.

My personal preference is to take the pure JavaScript approach, but that's because I like being able to work more closely to metal, and I'm disciplined enough to tame my JavaScript cats.

Answer 5

With GWT, you're not actually writing JavaScript; it's entire value proposition is that you can write Java that it will compile down to JavaScript for you.

Answer 6

I'm working on a project that has used GWT to pretty good effect. It's a good choice for us since we're all primarily Java developers working on internal tools. I can't speak to how useful it is for large end-user sites.

One advantage I particularly appreciate is the seamless object serialization and deserialization. Not only are the details of XML-RPC abstracted away, but since the same Java code is compiled to byte code for the server and javascript for the browser, you can code almost as if the server and client were running in separate class loaders in the same JVM. For instance, you can construct a Java object on the server, send it to the browser as the return value from an RPC service call and the browser code can then use the identical Java class to manipulate the object you just returned. Likewise, parameters to RPC calls can be constructed as Java objects, with the server receiving an identical Java object on the other end. All this without mucking about in the details of (de)serialization.