GWT – Pros and Cons

I love JavaScript. With the advent of jQuery and Mootools, my love for JavaScript has only increased plenty-fold. Given a choice I would use either of the aforementioned frameworks for any web application I develop. But being in the service industry, time and again I have to succumb to the client’s pressure and work in their choice of technology – whether or not it is the right one (The one who pays the piper calls the tune. Isn’t it?). One such client exposed me to the world of GWT.

I have given GWT a shot couple of years back on the day it was released. I didn’t like it that much then, so I dismissed it and never returned back. But, over the past six months working on this project I have a slightly different impression on this framework. I still cannot say that GWT is the next big thing since sliced bread, but at least it is not as bad as I thought it was. I have just documented my observations, both good and bad during the course of this project and thought some fellow developer might find it useful while evaluating GWT.


  1. If you are a Java veteran with experience in Swing or AWT, then choosing GWT should be a no-brainer. The learning curve is the least with this background.
  2. Even if you are not experienced in Java GUI development, the experience in working on server-side Java for years will come in handy while developing GWT apps
  3. You can create highly responsive web applications with heavy lifting on the client-side and reduced chattiness with the server-side
  4. Although there are numerous JavaScript libraries out in the wild and most of them are worth their salt, many conventional developers don’t understand its true power. Remember, a powerful language like JavaScript is a double-edged sword. If you don’t know how to use it, even you won’t be able to clean the mess you create
  5. You can migrate from a typical web application to a GWT application iteratively. It is not an all or nothing proposition. You can use a clever trick called JSNI to interact with loads of JavaScript functions you already possess. But it is always better to move them to GWT sooner rather than later
  6. The IDE support for GWT cannot be better. Java IDEs have matured over the past decade to be one of the best in the world and GWT can take direct advantage of it
  7. The integrated debugging beauty is something you can kill for. The excellent debugging support offered by the mature Java IDEs is one feature that could sway anybody’s decision in favor of GWT
  8. The built-in IDE support to refactor Java code can directly be put to good use to maintain a simple design at all times. Doing this in JavaScript is not for the faint at heart
  9. The IDE syntax highlighting, error checking, code completion shortcuts etc are overwhelming – to say the least
  10. GWT is being actively developed by Google. We know that the project is not going to die off anytime soon. Until now their commitment towards the project says a lot about its future in the industry.
  11. The community behind the project is also a big PLUS. Discussions take place daily in Stack overflow, discussion forums, wikis and personal blogs. A simple search with the right keyword could point you in the right direction
  12. GWT is a well thought-out API; not something that was put together in a hurry. This helps you as a developer to quickly comprehend the abstractions and makes it really intuitive to use
  13. You can use GWT’s built-in protocol to transfer data between the client and the server without any additional knowledge of how the data is packaged and sent. If you prefer more control, you can always use XML, JSON or another proprietary format of your choice. Even in that case, while using JSON, you don’t have to use an non-intuitive java JSON library. You can use JSNI to ‘eval’ the JSON using straight javascript. Cool huh!
  14. You have the advantage of being able to use standard Java static code analyzers like FindBugs, CheckStyle, Detangler, PMD etc to monitor code and design quality. This is very important when you are working in a big team with varying experience.
  15. You can use JUnit or Test NG for unit testing and JMock or another mock library for mocking dependencies. Following TDD is straight-forward if you already practice it. Although there are JavaScript based unit testing frameworks like jsunit and qunit, come on tell me how many people already know that or are itching to use that.
  16. The GWT compiler generates cross-browser JavaScript code. Today, any marketing person who says this will probably be beaten. It has now become a basic necessity, not a luxury
  17. The GWT compiler optimizes the generated code, removes dead code and even obfuscates the JavaScript for you all in one shot
  18. Although the compilation process takes hell a lot of time, you don’t have to go through that during development. There is a special hosted mode that uses a browser plug-in and direct java byte-code to produce output. That is one of the main reasons you are able to use a Java debugger to debug client side code.
  19. Rich third-party controls are available through quite a few projects like Smart GWT, Ext GWT etc. They are well designed, easy to use and theme-able. So, if you have a requirement where existing controls don’t just cut it, you should be looking into one of these projects. There is a really fat chance that one of those components will work out. Even if that doesn’t work out, you can always roll out your own.
  20. GWT emphasizes the concept of a stateful client and a stateless server. This results in extremely less load on the server where many users have to co-exist and high load on the client where only one user is working
  21. I18N and L10N are pretty straight-forward with GWT. In fact locale based compilation is taken care by the GWT compiler itself. The same cannot be said about regular client-only frameworks
  22. GWT comes built-in with browser back button support even while using AJAX. If you are an AJAX developer, I can almost feel your relief. This is priceless.


  1. GWT is a fast developing project. So, there are a lot of versions floating around. Many functions, interfaces and events get deprecated and keeping up with their pace is not too much fun when you have other work to do
  2. There were quite a few GWT books during the beginning. Not so much these days. For example, I haven’t found many books on the 2.0 version of GWT. This leaves us only with Google’s documentation. I agree that the documentation is good and all, but nothing can beat a well written book
  3. GWT is not fun to work with. After all it is Java and Java is not a fun language to work with. If you add the fact that entire layouts and custom controls should be created in java, you can easily make a grown programmer cry. With the introduction of UI binder starting version 2.0, that problem is kind of solved, but now you have a new syntax to learn.
  4. The Java to JavaScript compilation is fairly slow, which is a significant con if you choose GWT.
  5. I personally prefer defining structure in HTML and styling it using CSS. The concepts used in HTML are clean and straight-forward and I have years of experience doing just that. But in GWT, I am kind of forced to use proprietary methods to do the same. That combined with the fact that GWT doesn’t solve the styling and alignment incompatibilies for me compounds the problem. So, writing layout code in GWT is something I despice. But with UI Binder and HTMLLayout from version 2.0 onwards, I feel I am back in my own territory
  6. It requires some serious commitment levels to get into GWT, coz, after that, a change in client side technology could require a complete rewrite of your app, as it is a radically different approach than other client side frameworks
  7. There is not a defined way to approach an application development using GWT. Should we use only module per app or one module per page or somewhere in between. These design patterns are slowly evolving only now. So, typically people tend to develop all in one module until the module size goes beyond being acceptable and then they refactor it into multiple modules. But if it is too late, then refactoring could not be that easy either
  8. Mixing presentation and code doesn’t sound right although typical desktop GUI applications does just that. But these days, even desktop application frameworks like Flex and Silverlight have taken an XML based declarative approach to separate presentation from logic. I think GWT 1.x version had this disadvantage. With the introduction of UI Binder starting from version 2.0, I think this disadvantage can be written off although it is yet another painful XML language to learn
  9. You would often be punching in 3X to 5X more code than you would with other client libraries – like jQuery – to get simple things done
  10. You should also remember that with GWT, the abstraction away from HTML isn’t complete. You’ll still need to understand the DOM structure your app is generating in order to style it, and GWT can make it harder to see this structure in the code.
  11. GWT is an advantage only for Java developers. Developers with .NET or PHP background won’t gain anything here
  12. If you have tasted the power of JavaScript and know how to properly utilize it to your advantage, then you will feel crippled with an unexpressive language like Java

I am sure many of you will have differences of opinion. Difference is good. So, if you think otherwise, feel free to leave a comment. We’ll discuss…

Ganeshji Marwaha

I spend my days as the Director of Technology for Mobility practice and help my clients design enterprise and consumer mobile strategies. Mobile Payments, Digital Wallet and Tokenization technologies are my areas of specialization

  • Interesting! I was pretty impressed with the “Google Wave” product when it came out and that had been built using GWT apparently. Using abstractions built on top of technologies always involves trade-offs and as long as technology choices are made considering those, it should be fine. I am sure your post will help anybody evaluating GWT.. Thanks!

  • Ganeshji Marwaha

    Thanks @Raj

  • Tanks for this usefull evaluation and personnal feeling about GWT.

    As a Frontend java developper (java Swing javaFx) developer, it now seems clearer to me I should try Google Web Toolkit (GWT) for real !

  • Ludo

    Thanks for this article.

    I don’t get your Con #12. What do you mean by ‘unexpressive’ ?

  • Ben

    Thanks for the article. It confirmed for me some of my apprehensions about GWT. I’ve had a lot of difficulty finding good information/documentation on the UIBinder and the design patterns for managing a load code base have also eluded me. It’s good to see I’m not alone.

  • Its general issue with abstraction. (Any Abstraction). Consider we are using struts2+jquery plugin. It handles things beautifully. But When it comes to doing something not so standardized, you are is soup. Similarly using libraries with dojo.

  • Ganeshji Marwaha

    @Thierry – Thanks. And definitely GWT is worth a try if your use-case requires complex client side scripting.

    @Ludo – By unexpressive I mean, we can’t do many things cleanly. Think about the amount to boiler-plate code compared to ruby or groovy or scala for that matter. Think about how you would parse an XML with Java and its equivalent code in Ruby. There is more in terms of support for Closures, duck typing, DSL but you get the point…

    @Ben – You for sure aren’t alone

  • jD

    Hello Ganesh,

    What about a very competitive back-end Java technology + JQuery in the front-end vs. GWT in the Web development market.

    Do you think would have a chance for getting the heart and minds of the Java Web development community


  • GWT definitely ties one to Google

  • Ganeshji Marwaha

    @Jigar Shah – very much true

    @jD – I would any day choose the jQuery front-end over GWT but that is just me because I understand the true power and utility of javascript and how to bend it to my whims and fancies. But that is not the case with typical java developers. Java developers in my company is an example. They would prefer GWT over pure javascript based front-end. So, i guess both of them have their place… I just wish GWT translates directly from byte code. I don’t even know if it is possible, but if it is, then having scala to write GWT code could be a game changer.

  • jD

    Hi Ganesh,

    Probably your folks might consider a 2nd look to JQuery…
    Right now there are 309 GWT jobs listed on Dice while 2579 for requiring JQuery skills for the US market. I believe for self preservation they would have to make a decision pretty soon.


  • That’s a very interesting one. I can’t wait for your next articles in your blog. I hope your blog got million visitors. good job!

  • fymo

    Beautiful review Ganesh

    I’m using GWT for over 2 years now and I agree with your points, but some of the cons are solved now

    5. you can style a page using HTML and CSS only then attach the GWT widget only, or you can create the whole page using GWT. You just add a div in your page where you want to attach the widget. For me, I prefer to use GWT to create the page, as I’m a Java developer so that’s not a problem for me. On the other hand, if I’m working in a team with a web designer, the second approach will be more feasible so that I, the developer, could concentrate on the business logic and server side coding and leave the web design to the designers. So I think that’s could be counted as a pro 😀

    6, 8. Now you can avoid that by using the MVP design pattern. It’s very simple, very straight forward. It is an improvement of the MVC design pattern and could ease any change of the client side regardless whether it’s a web browser, handled device or even a web service. So, with a change of the client side technology you only need to change the view part of your application.

    12. You can also get the advantages of using JavaScript through native methods provided by JSNI, and that’s what I like most about GWT. You don’t have to commit the development all to GWT, you can use whatever tools you have in your arsenal along with GWT and the integration is kinda simple.

    And I agree with you on the rest of cons, especially cons 9, 10

    Thanks for the review

  • Dimitris

    Pros#12 is wrong! GWT is loaded with deprecated APIs exactly because they were not so well thought-out in the first place. Moreover if you delve into their widget sources you will find many horrifying stuff. Thankfully they tend to keep their DOM structures pretty clean, which makes them easy to customize and style.

  • Dimitris


    LOL, you think THAT very simple and straight forward? Maybe the long years of Java development have infected your brain cells’ DNA 🙂

  • fymo


    Well, I’ll admit it was actually tricky at the beginning, but once I got the hang of it, I can’t even think if a simpler way to do it 😀

    There is a session about GWT in Google I/O 2009 that got me started

  • Ganeshji Marwaha

    @Dimitris – full blown MVP implementation could be daunting at first sight for small apps. But when you work with a large team of developers with varying levels of experience you will start appreciating its elegance… That said, I also wish it could be simplified…

  • joseph


    Second comment test, since my previous one was considered as spam…

    Anyway, back to it!

    My comment was mostly around this question: do you consider GWT as a good match for public facing web applications?

    I’m unsure of it mainly because, AFAIK, GWT code runs only client side in JavaScript. Thus it could be hacked or some data changed during the transfer. Yet I don’t know if this fear has any reality.

    As a side question, I was also wondering which effort it is to incorporate random jquery plugins, since it’s something which happens quite often to me. Is it something so demanding that you hesitate like hell before going into or just unappealing but doable?

  • Regarding con #9: you can use gwtquery (aka gquery) and be nearly as expressive as with jquery. Check it out.

  • Ganeshji Marwaha

    @joseph – For public facing websites the first concern GWT raises is that it cannot be truly SEO optimized for most of the UI is generated on the fly using javascript. Security constraints for Javascript are not unique to GWT. All javascript libraries share the concerns and most of them are solved with the right-blend of logic in the server-side as well. So, I wouldn’t write-off GWT considering security concerns.

    And I am sorry, I am unable to understand your side question. Can you be a bit more clear

  • Ganeshji Marwaha

    @Luciano – That is some great library. I checked it out and looks really wonderful. Will definitely try that out. Also noticed a gwtquery-ui project as a compliment to the famous jquery-ui project. If you are aware can you throw some light on how mature and stable these projects are…

  • gquery is definitely mature, and in a recent Google I/O it was supposed to be merged in the core, but then it didn’t happen. I don’t know about the UI project since I never used it.

  • Ganeshji Marwaha

    @Luciano – Will immediately give it a shot. Thanks for the tip…

  • joseph

    @Ganeshji Marwaha
    For sure, all JS is weak regarding security and needs server side check of the incoming data. However, from what I read, I’ve got the impression GWT server side doesn’t do so. I’m wondering if I’m right and if it matters (maybe there’s nothing like GWT server side and all is left to the user, I’ve no clue of it).

    Regarding the second point, my question was about the effort needed to use random jquery plugin in GWT: is it so much it’s avoided or is it still bearable ?

    thanks again for your post and for all the commentators: they rock. I learnt much regarding GWT 🙂

  • Ganeshji Marwaha

    @joseph – If you use just just GWT RPC with servlets on the server then you are left with not much feature set on the server, but you don’t have to just use that. You can always use Spring MVC, Struts or any other server side presentation framework as well. So, I guess you are safe there.

    We do use jQuery plugins inside our GWT project. I guess many do the same too. All you have to do is import the jquery library, your jquery plugins, import your GWT js, then use JSNI calls to call for its features. I don’t think it is too much effort.

    Do take a look at gwtquery and gwtquery-ui projects as well… They seem to be porting jquery library to GWT with our familiar jquery DSL style intact.

  • LSM

    YOu can easily use jQuery or any other toolkit along with GWT. For example: pass some data from the GWT to either the DOM or javascript and use jQuery to present it.

    Also, your opinion of Java not being great to work with kind of spoils your argument – you come across as though you were forced to use Java/GWT. There is no perfect web dev platform.

    And apart from the client-side Java in GWT, there’s no reason you can’t use another JVM language for the server-side stuff.

  • LSM

    By the way, you can override the CSS for any GWT widgets.

    And you can use the static HTML structure of a web page as much or little as you like. GWT can play as small or large a part of your application as you choose.

  • Ganeshji Marwaha

    @LSM – Perfection is not the expectation. I don’t think my opinion of Java not being great to work with spoils my argument in anyway. You provide no justification for it.

    The same way i can use any JVM language for my server-side (choice), I cannot do that with GWT(no choice). That is what i mean.

    If you feel that Java is expressive enough for you, well and good. I beg to differ though…

  • Pingback: Best Blogging Site What Is Monitored Blog site Internet hosting … | Hosting Review Directory()

  • Steve

    Thanks! I gotta say, I have just learned GWT afer coming from JavaScript land (2+ years). And this article truly felt like I had written it myself. You are 100% correct!

  • It’s long established that global state is bad, for instance a public static variable in an OO language, however jQuery (and probably all JS frameworks) encourage you to treat the DOM as public global state. One Pro for GWT missing above is that the GWT Widget framework discourages global DOM manipulation – it’s tough for widget code to mess with another widget’s HTML elements. The global DOM in jQuery makes it unfathomable to me how a large jQuery would work. I’d be interested in your thoughts on this.

  • Erik

    After all it is Java and Java is not a fun language to work with…you can easily make a grown programmer cry.

    This made me chuckle. As a grown programmer who started with C, I think java is a blast (well, mostly). I would say it’s the new generation of script kiddies who may cry at Java. 😉

    BTW – excellent article and great insights.

  • I like this blog. It is a rich content topic. It helps me solve a lot of problems. It updates at a very fast rate, and provides for me many opportunities. I think it can help me to solve many problems, thank you.
    Oh! It’s really good! Thank you!
    evening dresses
    strapless prom dresses
    cocktail dresses

  • Danolo

    Frankly, I am puzzled with something nobody has talked about.
    WE can do the best in absolute with Java for the Client-side (and server as well). And it just requires the plugin loading in the browser ! Now we see more and more heavy Javascript client out that take a long time to load (even more than applet) and are slow, heavy because its script running, sadly monothreaded ! You can hardly get a dynamic chart with GWT.
    I can launch pages with 10 applets running each 2 threads (total of 20 threads), doing each asynchronous data exchange with many servlets. I will never be able to do the same with GWT !
    So why using Java to result in something much less powerful that jav can do !
    The only interest of GWT is the widget library looking fancier !
    But to get a complex rich client running well, nothing better then a (semi)compiled code. Moreover, You do not say that GWT from google sniff your data andactivity: See their Terms of service, beeeerk : Big browser is watching you !

  • I’ve seen progression in every post. Your newer posts are simply wonderful compared to your posts in the past. Keep up the good work

  • A very good comparision… but i still hate GWT!

  • Reds

    Very well written. I was thinking to invest my time in GWT or Javascript framework. I vote for Javascripts as most of the libraries are very powerful now.

  • Pingback: Dissertation | Pearltrees()

  • James

    Good article. Erik, I am with you…alot of these guys have probably only coded half the years you and I have (25 or more). Coming from all that we have seen, Java is the crown jewel as a basis for serious development. It seems pointless to me for an organization to embrace anything but Java and wise to pay their staff to learn primarily 1 technology. Html and Javascript are the worst technologies ever…a tool like GWT that hides that ugliness while based on pure Java skills is really a plus for smart solutions. I have used GWT just a bit, but have used all the other web technologies enough to see their weaknesses. Heavy server-side generation of web pages is the last decade (Struts, Spring MVC, etc)…seems to me the next decade needs to get away from that approach and embrace GWT and others.

  • You atre right java script is the best one ever

  • Elmer Fudd

    I think this is a prey terrible article. It misrepresents the number of concepts. It’s misleading and incomplete at places. Do not take it seriously – that’s my advise to you.

  • Ganeshji Marwaha

    @Elmer – You are entitled to your opinion. But can you be kind enough to detail the misleading areas so that others can benefit.

  • cem ilman

    After working on .NET technologies for 9 years, then 7 months with Java+Gwt until today , here are my opinions.

    I used jquery with .NET based tech and loved it pretty much. But merging is very painful and you need to learn many things besides native c# json, javascript, jquery etc.

    With almost no knowledge on java 7 months ago, now i can say that if i start a project on web, i definitely choose gwt over and over. Here are my needs on enterprise development:

    1. javascript is most suitable with MVP
    2. client-side component-based development is a must on enterprise development
    3. if you have components everywhere, you need a mediator, which is event bus
    4. intergrated debugging, testing for tdd, need fast and elegant solutions
    5. learning curve for new team members

    Now we’re using gwtp over GWT and it is amazing. MVP, eventbus, history management, DI on client is done. Now i can put a non-Java developer on the line and in two weeks, he will be very productive. With ui-binders as Ganesh said, designing is not a big problem.

    Think about testing, debugging, and one environment for all the jobs, I can say that personally Im two times faster on web development when compared to my .NET days.

    As a result i can say that pros are very valuable for me when compared to cons. The only thing i missed is that beauty of some c# language features (linq and delegates especially) but nothing more.

  • Hi Ganeshji. Thank you for the article. This is the best GWT pros and cons list I could find on the web.
    Do you mind that I re-posted it on my blog with some comments?