Feb 27, 2014

GWT is coming back ... in 2015

Note: This post was published back in 2014-02-27. I can see a year into the future :-)

GWT is coming back!

Google Web Toolkit (GWT) will have a huge come-back in 2015. Here is why.
First, let’s look when and why GWT was created and what it is. If you know the Web and GWT, you can skip straight to My Predictions at the end.

GWT History, Present and Future

1994–2006 Before GWT

  • 1994: Internet Explorer 1.0 was launched as an add-on to Windows 95.
  • 1996: The <IFRAME> tag was invented and allowed web sites to become slightly more interactive.
  • 2001: Internet Explorer 6.0 was launched.
  • 2002: XmlHttpRequest invented by Internet Explorer, adopted by Mozilla.
  • 2004: GMail from Google launched publicly. Besides showing the world what was possible in a browser (“a real application!”), it also used the predecessor of the Closure compiler. AJAX was heavily used. Web 2.0 is there.
  • 2005: Internet Explorer had 87% market share and kept growing.

2006: GWT Launched

Sometime here the initial GWT team must have started to work. GWT was created when Internet Explorer 6.0 was the most relevant browser. Each browser had different bugs and APIs, but IE 6 was considered the worst. GWT launched with a unified API of widgets and events, which worked the same on all major browsers.
  • 2006, Q2: Release of GWT 1.0.0

2006 - 2014: From Web to Apps

  • 2006, Q3: Release of jQuery 1.0.0 (source). jQuery also unified the different browser quirks.
  • 2007, Q2: iPhone was launched. It could only launch web apps. There was no app store yet. Q4: Android 1.x beta launched on phones.
  • 2008, Q2: Apples AppStore was launched. Soon thereafter (in 2010), “the web is dead” and people somehow needed apps. Apps, Apps, Apps
  • 2009, Q4: GWT 2.0.0 released. PhoneGap launched. It allows JavaScript to access sensors, camera, local address book, and other local services on the phone.
  • 2010, Q2: Apple iPad launched. Tablets! Everybody needs one!
  • This was also the launch of the Chrome Web Store. Now web apps truly existed.
  • 2011, Q1: Android 3.x on tablets. Q4: mgwt 1.0.0 and gwt-phonegap launched. (source). MGWT mimics the UI widgets of iOS and Android; is packaged as a normal app via PhoneGap; runs find on phones and tablets.
  • 2011, Q4: Android 4.x unified phone and tablets OS. PhoneGap was open-sourced as Apache Cordova.
  • In the meantime: JavaScript
    • became a lot faster - thanks to optimizations, asm.js (a fast JS subset);
    • easier to debug - step-by-step debugger in the browser
    • easier to debug from compiled languages - thanks to Source Maps Rev 3 Proposal from Mozilla

2014: The Current State of Affairs

50% of web traffic comes from mobile. Vendors have to support at least 3 major form factors (desktop, tablet, smartphone) multiplied by 3–4 platforms (Web, Windows, iOS, Android). To reduce costs, people started to code the back-ends of their apps in JavaScript and sometimes the user interface, too. Hybrid apps were born.

What is GWT?

GWT today, version 2.6.0, contains several parts, all available under the Apache 2.0 License:
  • Java to JavaScript compiler - translates all of Java 7 syntax to valid JavaScript code.
  • Java Runtime Emulation (JRE) - provides implementations in JavaScript for basic Java APIs. Here is the list of supported APIs.
  • UIBinder - create complex layouts with XML config files
To give you a feeling for the land in which GWT lives, here are the dependencies used by GWT 2.6.0: HtmlUnit 2.13, Jetty 8.1,Servlet 3.0, Guava 15.0, Protobuf 2.5.0, ASM 4.1, JDT 3.8.3, Closure compiler 20131014 (optimizes JavaScript).
The main focus of GWT is on performance. To achieve this, GWT tries to
  • minimize code size (compact javascript)
  • minimize number of network requests (inlined styles, images, i18n resources)
  • optimize for caching (huge cacheable chunks, tiny dynamic loader script)
GWT comes with a very nice debugging mode, called DevMode. In DevMode a native browser plug-in re-routes most calls to a running IDE such as Eclipse, which runs remote debug mode. This allows to debug step-by-step, live running Java code mapped to JavaScript code.

Is GWT relevant?

  • At Google: yes, 1k internal users; Many products built with GWT: Google Shopping Express, Adwords Manager, Google Sheets v2
  • Externally: 100k users of SDK
Sources: GWT.create keynote, GWT Report 2013

2014: The Future of the Web - Components

The web (standards and browsers) morph into a real app platform.
  • 2013, Q2: HTML Templates released as W3C Editor’s Draft.
  • 2014, Q1. Four new W3C Editor’s Drafts released:
    • Custom HTML Elements - each custom element has a name, properties, functions, events, child content. Elements can be nested. The web has a native component system!
    • Shadow DOM - multiple DOM trees in a single web page; can interact with each other
    • HTML Imports - import HTML pages into other HTML pages, including scripts
    • CSS Grid Layout - native-like GUI layout (basically, tables done right)
Taken together, these 5 standards are called “Web Components”. There is a nice overview page here. To make it nicer to work with these APIs and to polyfill support in older browsers, both Google and Firefox provide JS libraries. To quote the official X-Tag blog:
“X-Tag and Polymer are both high-level sugar libraries that build upon the W3 Web Components specs - each introduces a different approach to making development of web components an even more amazing experience. To help make this more relatable, consider the following: jQuery : DOM :: X-Tag/Polymer : Web Components.”
  • 2014, Q4 (planned): ECMAScript 6 (ES6) will be standardized. New stuff: Classes, modules, promises, generators.

What will GWT be?

The GWT Roadmap and the talks at the GWT.create conference promise a number of things for GWT 3.0 and beyond:
  • (+) Interoperability with JavaScript: Instead of the current JSNI calls with lots of redundant Java code, GWT 3.x can auto-create annotated Java interfaces which magically just work to call the JavaScript API underneath.
  • (+) Incremental compile! This will give GWT developers a work-flow similar to other JS hackers. Hack, reload, see.
  • (+) Java 8 support - writing callback handler will use less syntax than JavaScript
  • (+) CSS3 support - mostly boring technical work which is simply required :-)
  • Most importantly: A new widget system, which is based on web components. Working draft of GWT team
  • (-) The DevMode will die. It never worked on mobile, and it will stop working in 2014 (based on out-dated/internal browser APIs). The new debug mode, Super Dev Mode, will run in the browser, not in the IDE. I see a serious problem here, and we have to see, how this turns out. At least SourceMaps will allow to de-obfuscate stack traces. More infos: “Beyond Dev Mode”.
Sources: GWT.create keynote, GWT Roadmap presented at Google I/O 2013

My Predictions

The Web: As the number of devices and operating systems grows, a unified development process becomes more interesting. With web components the web becomes a composable platform for application development. There will be markets for tags, in the same way as there are markets for Wordpress plugins today.
GWT: Let’s assume the GWT community of developers manages to do the following:
  • Deliver the features planned in the road map (JS interop, Java 8, incremental compile)
  • Provide a solid initial widget set, maybe inspired by Polymer and Bootstrap
  • Find a usable way to debug code
As soon as that happened (planned in 2014, likely to happened in 2015 :-), GWT will get a huge comeback. Why? Although the stated goal of GWT is performance, which always wins hearts of developers, the true magic is that GWT allows to tame complexity. I know, for GWT newcomers this is really quite the opposite, but for bigger apps it’s true. As requirements of users and the world only rise, the complexity rises with it. Combined with JS interop and Web Components, GWT will be the glue (and structure) that holds it all together.
The biggest apps (most complex in client-side business logic) will be written in GWT. Just like Google Sheets.

UPDATE 2015, June
Good: Technology, Usage
On Google IO 2015 there was not a single mention of GWT. However, GWT has its own conference by now, and it was even earlier than Google IO.
In Januar 2015, there was the GWT.create conference. Many Google employees spoke there. Of particular interest was the talk on Google Inbox. It turns out, the new mail client from Google, with the goal to replace GMail one day, was written 60-70% in GWT. The new Google Sheets was also written in GWT. 
Bad: Documentation
On the downside, Google seems to have used many GWT features that might or might not be released in a stable way yet -- the documentation is certainly behind. E.g. try to find something on "js interop" in the developer documentation: you find it only in release notes and some examples.
So the future in which GWT comes back is here, but its just not evenly distributed yet. Sadly, my prediction is, it will remain this way, as there are neither enough volunteers nor companies, which would have enough incentive to document GWTs new stuff.


  1. Really nice post!

    I'm currently working with GWT, JBoss Errai and Cordova to build a chrome-app + phone-app at the same time, meanwhile I see Dart and jQuery growing quickly with these new standards which makes me avid to see who gets it the right way.

    I really know very little about Dart and jQuery but I know that Dart for example has javascript optimization just like the GWT compiler and jQuery brings maintainable javascript code running across browsers, so I understand from what you say that the key feature of GWT will be its ability to compile code for each combination of browser+platform and a bunch of Java developer who don't want to learn Dart and jQuery :P

  2. Anyone interested in getting IDE support for sourcemapped languages, starting with GWT, see the sdbg project: https://github.com/sdbg/sdbg

    The goal is to make the eclipse debugger interface with browser debugger to live debug javascript while viewing source java. Currently the project has less features than dev mode, but when complete, it will be better than DevMode, because it can view any native object (elements / events / jsos). Coupled with super-dev-mode and incremental compiler, the gwt debugging experience will still be stellar.

    1. Not saying you'll be able to debug on mobile devices !
      Thanks James for your wonderful work. I hope to check with you again on the next GWT.create !

    2. This is very important to me (well, us, in the team). We consider the new "super dev mode" a step back in this sense and it seems that sdbg might address the issue.

  3. @carizo I see Dart as Googles Plan B if JavaScript turns out to make trouble (i.e. resist to some kind of optimizations required to do something they want to do). Dart seems planned to run natively in browsers with better performance. Maybe Dart is Googles CoffeeScript? Anyway, as you say, I also don't believe people want to learn it. Even if, tooling is far behind Java.

    jQuery is good across browsers, but JavaScript is not good to handle complexity. Complexity requires refactoring, refactoring requires tool support and automatic tests. JavaScript cannot have the same level of tool support, it's too dynamic by nature.

    @James Nelson
    Thanks for sharing the link

  4. Nice post. Good to see there is a lot of activity going on with GWT since Google open sourced it.

    I would question the title though, as I don't really see how GWT 'went' anywhere in the first place. It's great to think it is becoming more relevant as time goes on though.

  5. I miss the DevMode. SuperDevMode is cumbersome and unwieldy.
    I hope there will be a better solution in the future.

  6. Well, GWT is over. The future is AngularJS or Dart.
    Problems with GWT:
    1) functionality limited: it can only use the intersection part of Java and JavaScript, no Closure, for example.
    2) compile time is too long: even you change just ONE character, you may need to spend 20 minutes or more to compile it, for large projects - what a pain!

    1. 1) It compiles JS from Java. So your comment is not totally incorrect, just a bit misleading.
      2) Haha 20 minutes. Maybe on you IBM 386 computer. ;-) And you don't need to compile to run/debug. Only need to compile when you're ready to build your WAR.

    2. 1) Don't know what limitation you are talking about. It's almost Java7 (without reflection and multithreading). And any js library can be reused with JSNI and upcoming jsinterop.
      2) Compilation time is not so bad. Usually it's 1-3 minutes, depending on project complexity and used libraries.

    3. Started to work with GWT and found following:
      1. Configuration - It is very problematic to create development environments running with all configurations staff...
      Used eclipse as IDE it is very easy to break your project with just rename one file (using refactoring tools of IDE).
      2. Compilation time - not 1-3 mins (checked at small project with good comp i7 and 16G memory :) )
      3. Community - most of posts are outdated (checked at StackOverflow)
      4. Binding - What can be done at AngularJS in 2-3 lines of code here you need much much much MORE!!!
      5. SuperDevMode - When you have project with couple of libraries to configure SDM is going to be not trivial, in additional at dev tools (at chrome, FF) add watch is not working...

    4. It takes about 10-15 seconds for my screen to refresh after a change on my 5 year old MacBook Pro (2.53 GHZ i5). Its about half that on my 2 year old iMac. True a full 6 module compile of a big application takes 5-6 minutes on the iMac but I do that at most once a week. I do not know where you are getting your numbers from.

  7. Excellent article regarding GWT. I am a senior GWT/ android developer, having 4 years of GWT enterprise level experience, I can vouch for the easy development effort needed by a seasoned Java developer to churn out a fairly complex web application. What amazed me was the easy integration of feature rich GWT front end with the J2EE backend stack (Hibernate and Spring layers). Amoung the new feature in GWT I like the editable DataGrid component - it is a powerful beast - in a good way.

  8. All of the new bells and whistles are really nice and critical to the continued success of GWT. But there won't be great market growth of GWT until a lot of work is put into developer relations, tutorials, and making it easier to get started with GWT. Right now, it is trivial to get started with a JS framework. You can just send someone a jsfiddle or pulnkr and a tutorial. Within just a few minutes, they can understand a lot of it.

    Back when GWT was a major initiative of Google, there was a team that worked on dev relations and updating documentation, tutorials, and such. That just isn't true anymore. Some things are being done, but the main focus is still on the compiler and internals.

    It's good to see so many open-source contributions to the platform, but it is still too hard to get people started with it. I've tried to get a number of people into it over the last 2+ years and each time they have had massive struggles with the GPE and tutorials. In the end, every one of them gave up and said that they would not give GWT another shot.

    1. You right we are almost there :)
      Just let it burn...
      Google forgetting about GWT - now it is Google Webmaster Tools for some search requests.

  9. There is an alternative tool similar to GWT called Dragome. But this one is about compiling bytecode to js, and it also has UI components support. Things like Incremental compiling, Java 8, HTML template are already supported.
    And there is no need to wait to ECMAScript 6 to be standardized because it already allows use of dynamic proxies continuation (js yield), classes, lambda (arrow functions).

    Project URL: www.dragome.com

  10. I would seriously urge you to formalize Xtend support (unfamiliar with XTend? then: Xtend::Java :: CoffeeScript::JavaScript).

    Lookup the slideshare on Xtend with GWT. I think the combination with GWT 3.0 features will be one powerful framework to reckon with.

    1. I love GWT because it let'S me use Java and all the IDE power for writing complex business logic intensive apps. When moving away from Java, I see no clear advantage of using Xtend over, say, using Coffeescript, Dart, TypeScript, or even native JavaScript. That being said, Xtend doesn't look too bad :-) But http://projectlombok.org/ looks also cool.

    2. with xtend you don't fully move away from java: i.e. it compiles to java and let's you perfectly mix java and xtend.
      one great advantage of xtend is that we can use the same strongly typed language on server and client (which enables the powerful refactoring features for IDEs).
      Even on AppEngine (which still only supports Java7), we can use the concise xtend syntax for both client and server: i.e. we can configure xtend to compile to java7 and still use lambdas, etc.
      also xtend has some other great features, like easy templating, active annotations etc.
      the only thing I am worried about is how the debugging will work with GWT3 (i.e. xtend compiles to java, java is transpiled to javascript, ..)

  11. Interesting article, shame that it does not mention dependencies as probably a relatively big problem that GWT is facing. Libraries written in js will likely support npm or bower whereas libraries written in java will support maven. Thus you end up having a mixin of tools to interoperate with the two tools. Besides, marking the dependency agains a node modules is painful with GWT.

    I guess that's probably why google is looking toward a more unified solution like AtScript.


    1. Good point. The mixed build process is certainly an issue. I guess GWT makes most sense, if only some JS libs are used. Thanks for pointing me to AtScript. The world of TypeScript, AtScript etc. indicates that many teams try to avoid using JS in its raw form :-)

  12. I agree. Everyone seems to agree that compiling to js is the future. Even Brendan, the creator of javaScript, is working on asm.js which is supposed to help people compile to javaScript. Since Java is probably the most popular language next to javaScript it's only natural that people would use GWT. I'm not sure that GWT will increase in popularity for more than a year though because the trends on google trends and indeed job trends show that GWT is declining. If this was the only issue I'd say screw the trends, GWT 3.0 is awesome. However, javaScript, jQuery, HTML 5, JSF, and Vaadin are all going down too.

  13. Well it's 2015 now and It looks like this guy was right. GWT is delivering on it's promises and much more and there are now 3000 rather than 1000 googlers using GWT. Google is trying to reinvent email in GWT again with google inbox. What's interesting about google inbox is that they reuse up to 70% of code across multiple platforms! This looks like it'll be one of the biggest reasons for using GWT in the future. GWT will always be a tool for a niche of developers but cross platform apps are a new niche for GWT!

  14. Dear future commentators, author here, if you have comments, please make sure they contain any argument (more than I" agree" or "I disagree") and make sure to use neutral language (avoid "morons", "idiot" etc.). Those comments have not been published, as they provide low value.

  15. Hi,
    Is there are any news regarding the future of GWT?

  16. I'm exploring GWT for a project, and I see the last release was almost an entire year ago. That might be reasonable evidence of a dead project in the tech world. What's your take on it now [October 2015]?

    1. My current view is, (1) GWT has become a niche tool for extreme high-tech projects. GWT *does* offer some unique complexity and performance handling benefits, but most projects are not that extreme in their requirements. (2) The active GWT-producing community is too small, the release cycle is too slow and most importantly the public documentation is too fragmented and too old. I am reading all GWT steering committee meeting notes and sometimes look in the master branch. Things go on, the technology is alive and well. It just gets harder and harder as an outsider to dive in.

    2. Thanks very much, Max. Much obliged.

  17. Again as many might have mention earlier, GWT is not for faint hearts, its learning curve is tough for new comers especially from backend services side, or non-java developers, but it is an excellent tool for enterprise intranet based applications. Please use the activities, places (an MVP take by Google) paradigm when using GWT as well as UIBinders to reap the full benefit.


    1. I agree 100% on the learning curve. However, I think for intranet apps you can choose almost any technology, even all kinds of server side templates -- as long as your users are not coming via mobile devices. In the real internet, that's where I see the true value of GWT.

    2. Max, if you could please clarify what you mean by "the real internet" and how it relates to GWT. Also, what alternatives to GWT are you thinking of?

    3. Thanks for asking. With "real internet" I just meant the normal, open internet. Enterprise intranet has often a guaranteed minimum network quality and often even a defined set of browsers. The real internet consists of mobile networks, DSL dial-ups, satellite links, ... and a huge number of devices (mobile phones, smart TVs, desktop PCs, tablets, ...). In this more open, more dynamic, less predictable "real" internet, you need some serious cross-browser, bandwidth-saving CPU conserving technologies ... such as GWT :-) In the corporate intranet, you can often safely use almost ANY web technology.