Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

GWT is a software stack that translates Java code and a sub-set of the Java Runtime's class library to JavaScript code.

In comparison with JavaScript toolkits, GWT can seem alienating, by nature and by usage, and overly complex to do even simple things, taking away much of the fine-grained control you'd have by using JavaScript directly.

Why would a web-developer choose to use a tool like GWT, which uses a language originally not targeted for the web, instead of using pure JavaScript and JavaScript frameworks and toolkits?

Is it measurably better, and based on what criteria?

share|improve this question
1  
As phrased this question is not constructive - check out the FAQ - especially here and here. –  ChrisF Mar 7 '12 at 23:26
    
@ChrisF: is it better like this? –  haylem Mar 7 '12 at 23:53
    
@haylem - much.# –  ChrisF Mar 8 '12 at 8:40

4 Answers 4

Batteries Included

Java's Tooling

It is just awesome:

  • IDEs: even if some IDEs support JavaScript, the level of support just doesn't compare. Try to refactor JavaScript code on large codebases (say, 40K+ LOC) and weep.
  • Unit-Testing: though that picked up over the last few years, it's also way more mature in the Java world.
  • Continuous Integration and Continuous Inspection
  • Documentation Generation: Sure you have JSDoc and a few others

Static-typing

It catches bugs early. (Google Closure address that a bit while keeping the developer in the JavaScript world, if you prefer).

Optimized JavaScript

GWT writes faster and more compact JavaScript than you (for large applications), and allows you to determine what gets sent to the client arguably more easily than with equivalent full JS solutions.

Architecture

It provides a good separation of concerns for large applications, with decent MVC or MVP architectures already pre-baked at your finger-tips.

Decent Library

GWT provides interesting libraries, and makes it easy (well, easier) to build I18N-enabled applications with dynamic bundle loading.

Unit-Testing

Using JUnit from within Eclipse IDE and from the command-line. This relates to my first point. You could very well also use some of Java's code quality tools on a GWT project (for source checks, not bytecode checks, as there isn't any).

It's All About YOU!!

GWT isn't for everybody. It makes some people more productive and gives a good tool for non-JS developers to build professional web-apps with dynamic front-ends without touching (too much) JavaScript. But if it doesn't work for you, just use something else.

If you want most of the above but you just don't want Java, maybe look at Google Closure, or the Dojo Toolkit.

Was a Good Idea at the Time: History Matters!!

The JavaScript world (and web front-end technologies in general) is extremely active these days, so things are looking up. But only a few years back, things were not so bright. LESS/SASS were not that popular, jQuery was not yet the de-factory JS library, JavaScript libraries weren't spawned every other week, and tooling wasn't that great in general.

But, there already was a growing demand for professional and large web-applications with dynamic front-ends, so there was a gap to fill to make developers more productive. JavaScript has a great many pitfalls and oddities that you need to be aware of, and maybe it's just better to not even need to care about them. Hence the niche for tools like GWT.

Since then, others have appeared (CoffeeScript comes to mind, Dart is on its way, but also large JavaScript frameworks, the revolution of server-side JS with Node.JS and others, and a strong comeback for JavaScript as "good enough" all-around language to be used not only on the client-side but also in other parts of your business stack.


Additional Notes

With Regard to your Original (Now Edited) Question About the Use of Firebug

You can debug GWT code with Firebug of course, but ideally you would debug it directly from the Eclipse IDE's debugger, which now provides live code debugging support.

However, Firebug it still usable, though you need to keep in mind that GWT generates optimized and compressed JavaScript, which may not be easy to debug as is.

With Regard to your Original (Now Edited) Question About CSS

Yes, you still need to write CSS code yourself, of course. You couple your GWT project with other tools though (like SASS), more or less easily.

It's Just a Tool!

Don't mistake GWT for what it's not: you don't write Java code to be run directly on the client side as Java bytecode. You write code in the Java language, which is then translated to JavaScript for efficiency and to allow you to use a higher-level language (or, at least, that's how it's meant to be seen).

Arguably, Java and JavaScript could be regarded as comparable in terms of abstraction levels. However, Java comes with some advantages (detailed above), hence the advantage in reaping the benefits of existing tools without the need to re-write them. Google's developers just had the clever idea of making it possible to reuse existing Java-oriented tools, but to in effect develop JavaScript applications.

Additionally, they solve another issue, which was the often cumbersome managed of dual-language web-applications where the JavaScript and the Java code was treated separately. The use of GWT allows a certain level of convergence for both sides of the development process.


Further Reading:

share|improve this answer
    
"Arguably, Java and JavaScript could be regarded as comparable in terms of expressiveness." Joke? Equivalent functionality in Java is about 5x as long. –  kevin cline Mar 8 '12 at 1:48
    
@kevincline: correct, I didn't mean to write expressiveness, I meant it terms of abstractions levels. Thanks for spotting it (it's 2AM...) –  haylem Mar 8 '12 at 2:02
6  
@kevincline: plus I did say "arguable", and die-hard fanatics of a language or another would argue anything :) –  haylem Mar 8 '12 at 2:04
1  
In addition to @Halem's items, I'd throw in that JavaScript's prototype-based OO can be a bit strange for someone coming from a class-based system like Java. Consistency of approach is often useful. –  Matthew Flynn Mar 8 '12 at 3:57
    
@MatthewFlynn: and vice-versa: that's why pure JS developers are definitely having a harder time getting on the GWT band-wagon, or using more heavy-weight frameworks that replicate more or less a class-based OO paradigm. –  haylem Mar 8 '12 at 4:09

After spending years developing a web application in GWT my opinion is that GWT has so serious disadvantages that I would never use it again if I am not forced to.

DOM tree

While JavaScript performance may be better, the rendered DOM tree is often unnecessarily complex. For example, the Tree implementation uses 13+ DOM elements including a <table> for each individual item. Using large trees (around 10000 items) simply freezes the browser. A pure JavaScript/HTML/CSS tree was able to handle the same amount of items easily.

Development

The modify-try cycle of pure JavaScript/HTML/CSS source can not be beaten. You just save your source file and refresh the page in the browser. This is a key factor in productivity and GWT just can not compete even by using code server.

Debugging JavaScript is absolutely easy and pleasure with the debugger of Chrome or Firebug.

Hammer Experts

The idea of using Java for everything is for developers who are "hammer experts". They are masters of their hammer so everything is a nail. I think this approach is very wrong. Using GWT also requires knowledge of CSS and HTML. Without this GWT developers often bump into problems that they find almost impossible to solve, while someone with HTML/CSS experience can come up with a solution. If the developers need this competence they can get it easier with developing in HTML.

My opinion is that most of the advantages provided by GWT are at least questionable while the disadvantages are far more serious compared to developing in pure JavaScript/HTML/CSS.

share|improve this answer

It's not measurably better.
For everyday use, consider jQuery, AmpleSDK, or some html5 polyfill.

GWT has a lot of overhead: actual and conceptual.

Might be useful if you have a java app or some server side java code to port to a web frontend.

share|improve this answer
    
You mean ClojureScript. Clojure itself a LISP-based language targeting the JVM. ClojureScript is the one producing JS code. –  haylem Mar 8 '12 at 3:38
    
Yep, had already edited that out, anyway. Keeping it simple. –  ZJR Mar 8 '12 at 3:43

Few benefits of using GWT that I think of ( more details read my blog http://www.pandurangpatil.com/2012/09/benefits-of-using-gwt.html)

  1. As GWT client application is written in Java, one get an opportunity to catch syntactical mistakes at compile time because of the same (Though it doesn't support all the JRE classes as those features are not supported by the browsers itself). Lets take an example to understand what I am saying. If you misspell a JavaScript variable name by using pure JavaScript library. The only way you can catch such mistake is to run the application and test for desired results. Java features like Generics and Annotations are use full and can be used in your application.

  2. One can make use of existing available libraries or write one to generate code as per requirement with ease as the code that need to be generated need to be in Java. GWT compiler takes care of compiling it and converting it in to JavaScript.

  3. Management of code becomes more easier.

  4. One can simply write some common business logic in a such way that it can be used in GWT client side code and also on server side code as its in Java e.g. validation of data or some common utility functions.

  5. With the use of GWT eclipse plug-in, you can easily debug the client code in Java for your business logic.

  6. As GWT compiler compiles your client Java code and generates JavaScript out of it. Which you need deploy it to your server, and it gets served and executed in user browser when requested. While generating this JavaScript it will do some optimisations.

    • It doesn't consider dead code while generating JavaScript, when I say dead code I mean to say "code which is there but not getting called from main flow". In turn reduces the effective size of your final JavaScript code.

    • It takes care of obfuscating generated JavaScript code.

    • It does minification of generated JavaScript code.

    • And more importantly it will generate browser specific optimised code separately. When I say separately, it will generate browser specific separate JavaScript which will be served when respective request is received from given browser. Which in turn reduces the size of the JavaScript code which gets downloaded for specific browser as it doesn't contain all browser specific handling in one single code.

  7. If you are writing your application for different languages i.e. English, Hindi, Marathi etc by using Internationalisation feature of GWT. While generating JavaScript code it creates copy per language and browser combination. Which makes generated JavaScript code for given combination of language and browser most optimal and small one.

  8. In case you need to use direct JavaScript which can be called from Java GWT code one can do it using JSNI ( JavaScript Native Interface). One can even call GWT Java Code back from JavaSctipt.

  9. If you want to make Bookmark able pages then you can make use of History feature of GWT.

  10. If you want to make use of JSON as data format for communication and manipulation it has very good feature called JavaScript Overlay Types.

  11. Deferred Binding feature of GWT is a good feature which I suppose is possible to provide because of Java.

  12. You can build your user interface using available widgets of GWT in Java Swing style. You can even create your custom widgets very easily.

  13. If you want to build your user interface ( Web pages ) in pure html style, you can make use of Declarative UI feature of GWT. Which I feel one of the major feature of GWT. Which makes it easier for developer to build pages in pure HTML style. Which I suppose is more maintainable than Swing style coding. And most importantly you can still have your logic in Java and only presentation part in pure HTML. (Note: which ever method you use (Declarative UI or Swing Style) ultimately its going to be HTML only but what makes difference is the way you code and maintain it).

  14. Client Bundle feature of GWT makes it very easy to manage your other web resources like css, images and other text contents.

    • CSS resources makes it possible to have conditional logic inside your css. You can also access some dynamic values from your GWT client side Java code.
    • It will also take care of obfuscating your css classes. And most importantly GWT has automated generation of interfaces from your css files to use css classe's.
    • Image resource makes it easier for developer to use images in your application in very easily maintainable fashion. When I say easily I mean to say when you want to use images in GWT Java code rather than using hard coded URL, you can use image resource. Benefit you will get using image resource is if you are going to change the location or use some different image with different name you just need to change it at one location. More important feature of image resource is when you use it with CSS resource as sprite. It will take care of making that image as in-line data uri or use it with sprite. I don't say its not possible to do it with other frameworks what's more important is how fast and easily you can do it. GWT makes it much easier for you.
    • Data Resource add some optimisation for data files like .pdf to rename those files based on their contents to make it strongly cacheable by browser. Small data files may be converted in to in-line data uri.
    • By making use of Client Bundle for other web resources and if you properly structure you application into different modules. It can become completely reusable modules as whole with every resource. What's the big deal about reusable modules? well if you are using images by using direct URL in some module. And if you include that module in other module and try to use the components created in that module you still need to have those images copied to public URL of your final application. Which you don't have to do it if you use those images as image resources.
    • Other optimisation you can achieve by creating small modules by using client bundle for css and images. Where you can chose to include only required modules inside your final module/s. The difference it will make is final module JavaScript and other resources will only contain required contents and not the whole contents even if you want to use small piece of the module.
  15. Cell Widgets: To present paginated data collection GWT has Cell Widgets. There are widgets like CellTable, CellList, CellTree and CellBrowser.

    • CellTable is meant for presenting data in paginated table format, it has feature where in you can change the contents of given cell in place. It supports pagination on client side and server side both, it support sorting on column and also it supports selection of one or multiple records and generating events for the same.
    • CellList can be used to present data in list format and items can displayed in custom format. It also supports client and server side pagination and selection of one or multiple records and generates events for selection. CellTree and CellBrowser can be used to present data in tree format.
  16. Communication with server from GWT client code. It supports multiple ways to implement client server communication.

    • If you are not concerned about the protocol being used for data transfer then it GWT RPC mechanism. Its very easy to integrate your client side code for data transfer with server. You can define custom DTO's (data transfer object) in client code which can be even used on server side code. Server side implementation accepts the same DTO's as parameter or return value. Everything else is taken care by GWT RPC frame work. It even propagates exceptions raised from server side code to caller in client side code (Provided you need to define those Exception classes inside client side code package. GWT RPC internally makes use of AJAX calls with their own custom protocol for data transfer.

    • If you don't want to use GWT RPC you can make server AJAX calls to fetch data from server using Request Builder. Which is also much easier to implement. It also has interesting feature Request Factory. With this feature you can make your DAO or Service layer exposed to get called from client code. To do that you need define few set of interfaces for your service and custom data types. And using these interfaces you can access those services from client code. I have written maven plugin to generate these interface. If you annotate your DAO layer with some required annotations refer (https://github.com/pandurangpatil/gwt-mvn-helper) refer mvn-helper-test module inside it for usage. Request Factory is more targeted to integrate with ORM layer like JDO or JPA on server. It has a support to call persist on given entity from client code. And most important when you call persist method it compute and send only change (delta) to server to save.

    • If you want to make cross domain JSONP call you can do the same refer.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.