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 compilesSo 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.
[update1]
There is an impressive list of google projects that are built using with GWT shared by GWT team members.
[/update1]
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…
[update2]
GWT 2.5 RC1 is out. I am test-driving the release and collecting impression and release information here.
[update2]
Pingback: GWT 2.5? » pgt
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?
I would certainly hope that my written and spoken comments on the subject are consistent. ;-)
Very consistent. Like you typed it after you spoke. :-)
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.
“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:
(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:
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.
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
Sorry for the formatting; I though WordPress would preserve ULs and LIs, and it unfortunately doesn’t include a preview.
I added the formatting, nothing to be sorry for. WordPress does not shine when it comes to discussions…
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.
> 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.
I know for a fact GWT is not dead! And there is a roadmap to make GWT better.
https://plus.google.com/110412141990454266397/posts/ivVepvxCu3g
Brandon Donnelson
http://gwt-examples.googlecode.com
Thanks for sharing!
I have compiled a list of projects from the thread into a posting here:
http://blog.oio.de/2011/12/14/google-is-using-gwt-and-you/
It would be great to have a few comments sharing other project references.
Pingback: Google is using GWT – and you? | techscouting through the java news
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?
[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 ?!
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.
Thanks Eric.
Impressive list. I am working on a public reference list of who is using GWT here:
http://gwtreferencelist.appspot.com/
I already have 50+ companies registered, hope to see more coming.
Suggestions are welcome.
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.
What a bunch of noxious FUD. This is emphatically not true for either project, and the article your reference is incorrect on several points.
The GWT project moved out of Atlanta more than a year ago, so the Atlanta closure had little effect on it. In fact, GWT’s future is very bright as announced at Google I/O this year. There is a new steering committee (Google, Sencha, Red Hat, ArcBees, Vaadin, etc.) managing the project, Google is staffing up the GWT team, and GWT 2.5 (one of the biggest ever) is close to release…
http://www.infoworld.com/d/application-development/google-hands-over-control-of-google-web-toolkit-steering-committee-196753
https://groups.google.com/forum/#!topic/google-web-toolkit-employment/NJmWmKsXQlI
https://groups.google.com/forum/?fromgroups#!topic/google-web-toolkit/eQtWYgkUB04
The Dart language project was never based in Atlanta (a small team worked on part of it), so the closure there had little impact and certainly did not put the future of the project at risk in any way. The Dart language is coming together very well, and we have some wonderful tools available that you can use to get started…
http://www.dartlang.org/
Several of the engineers in Atlanta that worked on either GWT or Dart transfered to other Google offices, and many of the ones who left Google as a result of the closure have, in fact, signed up to be external contributors to the GWT project.
http://code.google.com/p/google-web-toolkit/people/list
Pingback: Pertinence de GWT en milieu industriel