Future of GWT and GWT 2.5 [updated]

Unfortunately, there is no official GWT roadmap. In the past we used to foresee the future of GWT by reading between the lines. There are many sources of information, like:

  • reading the logs in the repository commits
  • discussions on the gwt google user group,
  • issues and the respective comments,
  • google+ postings
  • tweets

But recently the team started using Git – like many others. Some team members left. And then there is Dart, and people started saying GWT is dead, like Heinz-Joachim Belz after visiting the Google Developer Day 2011 in Berlin:

Dart is to be watched. If this project takes flight, it will almost certainly replace GWT (see below). (…)
In the long run, GWT is dead: No single mention in the sessions I visited, apart from (anxious) questions by visitors of the Dart session. Google’s Dart advocate asked about Dart’s relation to GWT underlining that many former GWT developers are now working on Dart is telling, I guess.

This is just one of many postings stating concerns about the future of GWT.

So, is GWT dead?  Here is a compilation of recent comments and statements from the GWT team.

First, there is the official statement from Bruce Johnson in the official GWT blog:

Dart and GWT both share the goal of enabling structured web programming. In fact, many of the same engineers who brought you GWT are working on Dart. We view Dart as an ambitious evolution of GWT’s mission to make web apps better for end users, and we’re optimistic about its potential. As Dart evolves and becomes ready for prime time, we anticipate working closely with the GWT developer community to explore Dart.

Meanwhile, rest assured that GWT will continue to be a productive and reliable way to build the most ambitious web apps — and even games like Angry Birds. Key projects within Google rely on GWT every day, and we plan to continue improving (and open-sourcing) GWT based on their real-world needs.

Eric Clayberg joined the GWT team (as team manager) after Google acquired Instantiations (the company behind GWT Designer).  His comment to whether GWT is dead or not:

I can assure you that GWT is not “dead” at all. Not even close! Quite the contrary, GWT is quite healthy, and the GWT team continues to focus on making GWT a great choice for building structured web applications now and in the future. If you have the need to start a new web app project, GWT would be an excellent choice, and there is no reason to avoid it. The goal of Dart is also to be an excellent choice for building the same kinds of apps (and more). Both can certainly coexist (and likely will for a long time).

You should not read anything into the fact that many former GWT developers are working on GWT. Google is a big place and a lot of folks have worked on GWT over the years. In fact, GWT has been a training ground for many folks working on exciting new technologies at Google (including Dart). The GWT team is fully staffed, and we have very ambitious plans for GWT’s future. GWT is used by many large, important projects within Google (and outside Google), and that is unlikely to change any time soon.

Only time will tell if Dart will actually replace GWT at some point. That depends more on the developer community than it does us. I am a fan of both technologies and would recommend either of them (depending on your specific needs right now).

So it looks like both Bruce and Eric are reacting to community concerns and publicly making statements.

In the follow-up comments Ray Cromwell provides some insight on the upcoming release GWT 2.5:

The next release or two of GWT may include more core improvements than the last few point releases of GWT so far, consider:

1) Compiler optimizations that reduce code by size by 30% uncompressed, and 15% gzipped
2) SourceMap support and Source-Level Java debugging in Chrome (and hopefully Firefox)
3) A “super draft mode” that can recompile many apps in under 10 seconds and most under 5
4) New “to the metal” “modern browser” HTML bindings
5) Testing framework that makes GUI testing delightful
6) Incremental compile support to speed up production compiles

So code will be getting smaller, faster, easier to debug (in some situations) and test, and compiles will go quicker. This reflects somewhat the shift in GWT team composition, but as people ramp up on other parts of the SDK (e.g. MVP stuff), I’m sure there will be improved responsiveness to fixing bugs in that area as well.

Ray also provides some insight on the GWT team losses:

The loss of Ray Ryan and Bob were a big set back (unrelated to Dart), and we have people trying to get up to speed on their contributions to maintain them, but honesty, we rely on many of our top external users like Thomas Broyer and Stephan Haberman to fill the gap until that time. (Thanks guys) Turnover is natural and happens at all companies, and it’s always rough.


On the other hand, we picked up the fabulous Closure Compiler guys (+John Lenz and +Alan Leung) who have more experience than all of the GWT team put together on black magic tricks in Javascript. Alan for example, is working on improving the CodeSplitter for RunAsync to significantly reduce the size of the leftovers fragment automatically.

So, in my opinion, GWT is not dead.

There is an impressive list of google projects that are built using with GWT shared by GWT team members.

GWT is, in my opinion, the best framework to build web applications for the web, the web as it is today. The web may change – maybe Dart really takes off and does change the web. But this is another story…

GWT 2.5 RC1 is out. I am test-driving the release and collecting impression and release information here.

Short URL for this post: https://blog.oio.de/7SpjD
This entry was posted in Java Web Frameworks and tagged . Bookmark the permalink.

25 Responses to Future of GWT and GWT 2.5 [updated]

  1. Pingback: GWT 2.5? » pgt

  2. Lars Vogel says:

    Strange to see Eric answer in writen form. I asked him last week this question on the Google Eclipse Day and your statement is almost what he said. Have you been on the event? Did you record his statement?

  3. Yes, that’s true. And not only Eric, it seems to be a GWT team thing:
    “We don’t comment on specific timing for future releases.” – see issue 7013
    But in this special case, he did. Here.

    • Note that commenting about GWT itself is different than commenting about exact release dates for a future release. We’re happy to talk about some of the things we are working on (see Ray C.’s recent comments in this thread: https://plus.sandbox.google.com/117487419861992917007/posts/6YWpsHpqMqZ), but try to avoid mentioning specific dates (which could always slip). Once you see milestones and release candidates starting to show up, that is a pretty good indication that a new release is imminent. We will often delay an actual release by several days or even weeks to make sure that we get it just right and all tests are passing.

  4. “But recently the team started using Git”

    What makes you think so? (I mean, http://code.google.com/p/google-web-toolkit/source/browse/ is still SVN) And how is that an issue?

    Here’s how it goes (not 100% sure though):

    Google internally uses Perforce,
    most (if not all) Googlers use Git with git-p4 (or probably an internal equivalent project), just like I use git-svn when working on patches for GWT
    every change goes through code review, most of the time publicly on http://gwt-code-reviews.appspot.com, but sometimes on their internal system, before being committed to perforce
    the perforce commits are periodically (within a few hours) pushed to the public SVN repository

    What makes it hard to know what’ll be in GWT future releases, is that, as far as I know, they’re working on pretty big changes internally at Google, and we’ll only see them when they’ll be almost complete (or at least when their design will be stable). In the mean time, we can only grasp some information from the sources you listed.

    Recently, there have been commits along the lines that Ray mentions:

    • added a hook (temporarily commented out) to the xsiframe linker for an alternate DevMode; this is related to the “super draft mode”, and will eventually replace the browser plugins for DevMode (which are a pain to maintain: the one for Chrome is plain broken, and Firefox requires that it’s recompiled for each new release)
    • hooked in the Closure Compiler (under a compiler switch for now): this is likely the announced compiler optimizations
    • SourceMaps support is already here (but still being tuned a bit)
    • the testing framework could be based on the side-project of Brian Slesinsky that I mentionned on Twitter a few weeks ago
    • incremental compile is already partly here (and already in GWT 2.4 actually) in the form of “precompiled modules” (look within gwt-user.jar, you’ll find *.gwtar files), but I suspect Ray was talking about something else

    (edited by P.G.Taboada, added UL/LI formatting)

    • Hi Thomas,

      I was quite sure the GWT Team is using Git. Ray somehow confirmed that:

      Finally, on SVN feature branches. Back when I started, all GWT development happened in SVN and via ant and git didn’t exist. At a certain point, we needed to start using Google’s internal/massive build infrastructure to speed up development (e.g. build GWT and run tests on a farm of test machines, for IE6/7/8/9 OSX and Linux, all browsers), and GIT. Internally, I use git for development now and changes to our internal repo are mirrored to SVN.

      What’s actually happened now that we’re using GIT is that we push smaller useful partials more frequently, rather than create big code-bomb SVN branches which cause merge pain, because branching and merging are cheap in GIT, small branches are more viable.

      Don’t get me wrong, using Git is not an issue, please don’t take it out of context. I am not that close to the GWT development as you probably are, so following the branches in SVN was one way to see where the GWT team is heading for. With Git, SVN branches are no more, one of sources of information is gone. In fact, there is nothing more left, I am blind.

      The issue (a weird one to put in the tracker, IMHO) is, that we don’t have a roadmap. The issue tracker itself is a mess (I have an open issue since middle August) and does not really help.

      Companies are in fact investing a lot in GWT projects, and managers and developers must blindly trust Google. GWT is not a technology to build Hello Worlds, most of us are building missing critical applications (like Google did) with GWT. But unlike Google, we do not have unlimited resources and cannot do the Dart-Jump-Trick even in the long run. As a kind of “GWT advocate in Germany” I fell like the whole Dart thing is doing some serious damage concerning GWT adoption. Google did never advocate GWT, that was left to us developers, conference speakers, but is hard to fight such bad marketing. Being blind does not help either.

      This is why I posted this compilation of statements from the Google Team here. This is something that should be happening not in Google+, but in either on the official blog, or in the discussion group.

      The problem is: GWT is an amazing technology. Googles effort put into GWT is close to unbelievable. But it is not a product, at least it lacks everything I would expect from a product: roadmap, better support, better documentation. I can not blame it, and the community is doing a good job. But as I said, we cannot fight the shadow being thrown by Dart.

      • I do agree that the GWT issue tracker has been a mess. One of my goals as the new GWT team manager has been to start cleaning up the issue tracker and get things triaged properly (Thomas B. and Stephen H. have been doing a great job helping us with this). We have also been increasing our efforts in accepting and integrating patches from the community since we feel community involvement is the best way to address many of the issues that are coming in.

      • Thomas Broyer says:

        Re Git: yes, I just saw Ray’s comment. So has Google abandoned Perforce for Git?

      • I perfectly agree, the most damaging thing that is happening to GWT is Google’s communication about it. It’s just a shame, because then companies are afraid to make the leap to use this wonderful technology

  5. Sorry for the formatting; I though WordPress would preserve ULs and LIs, and it unfortunately doesn’t include a preview.

  6. Ray Cromwell says:

    Just a quick comment on GIT. Thomas Broyer is essentially correct. Internally, Google’s code is in Perforce. But many people don’t like Perforce (I don’t). So there is a tool we use called git5, which is like git-svn. It basically mirrors perforce checkouts into a git repo, we do work in a git repo, and then when it’s ready, we commit it back to Perforce, where it is then mirrored into the SVN repo. (nit: I’ve fought for changing over the public repo to git but got argued down :) )

    Because we are using git, I now do a lot of “groundwork” on GWT in several git branches simultaneously, as opposed to past practice of using an experimental svn branch. At any given time, I probably have half a dozen branches going, for example: source maps, new stuff for GWT logging, new optimizations, closure integration, super-dev-mode, a source-map server, etc.

    This probably sit around for a month or two before they are fully baked for public review, because we are often testing them.

    As an example, often new compiler optimizations break applications in weird ways. Internally, I can test new optimization branches against Google’s internal continuous build infrastructure, and usually, but not always (which is why you see svn rollback commits) catch all of the egregious problems before public review.

    • Stephen Haberman says:

      > nit: I’ve fought for changing over the public repo to git but got argued down

      Nuts. :-)

      The perforce/git setup makes sense. Sounds like a pretty awesome CI infrastructure you guys have.

  7. branflake2267 says:

    I know for a fact GWT is not dead! And there is a roadmap to make GWT better.

    Brandon Donnelson

  8. Pingback: Google is using GWT – and you? | techscouting through the java news

  9. Veronym says:

    More and more apps are forced to run as portlets. What is your preferred approach here? There is an incubator project aiming at creation of a GWT portlet bridge. Or you can minimize your GWT client code so that it does not need the portal (i.e. Portlet API implementation). Is there any long-term strategy among GWT folks?

  10. John Pieces says:

    [quote]In fact, GWT has been a training ground for many folks working on exciting new technologies at Google (including Dart)[/quote]

    Except AdWords and Google Wave (RIP), can anybody tell me which popular Google services were built on GWT ?!

  11. Eric Clayberg - Google says:

    Ads (AdWords, AdSense, DoubleClick/xFP, …), Wallet/Billing/Payments, Offers, Shopping, Travel/Flights, Blogger, Groups, iGoogle, Web Fonts, Moderator, Orkut, Android Developer Console, Chrome Webstore, PlayN (used for Angry Birds), plus lots of internal corporate apps and additional external apps that have not been announced yet. GWT is an extremely important piece of software infrastructure here at Google.

  12. What is a Rose says:

    GWT is dead. Dart is also dead.

    News at 11: http://www.bizjournals.com/atlanta/blog/atlantech/2012/04/google-said-to-move-engineering-ops.html?ana=twt

    Google will migrate their current GWT projects into Google Closure library. We^H^H They are not going to rely on technology that they don’t control.

  13. Pingback: Pertinence de GWT en milieu industriel

Leave a Reply

Your email address will not be published. Required fields are marked *