Shared publicly  - 
For people who've asked about GWT and Dart...
Ray Cromwell's profile photoJames Hollier's profile photoBruce Johnson's profile photoBoris Vacher's profile photo
It doesn't really say much, does it? People have been asking about plans, but that blog post doesn't really outline any. It just re-enforces that GWT is important.
I expect (and hope) that GWT will drop Java and use Dart at some point.
+Rodrigo Moraes When you say drop Java, did you mean Javascript? I don't see much point in interpreting Dart using GWT to convert into Javascript.
No, I mean Java. Sorry for being honest, but I believe GWT will, eventually, be implemented in Dart, not Java.

That said, I have no insider view or anything, but I think we still don't know the whole story.
I agree, no idea yet on the full story. I'd like to get a better view on what you mean here though. Would you like the GWT engine to be built on Dart, which reads Java and converts it to Javascript (or Dart in the future)? Because just taking Dart and converting it to Javascript is what Dart already does.
+Adam Hawthorne Why maintain both Dart and GWT in the long run if Dart came to do it more appropriately? Java/JavaScript developers will learn Dart in no time, so you can't claim this is a barrier.
GWT is too complex to rewrite in Dart. It relies a lot on the JVM and JDT. For examine, GWT compiles Java source to bytecode as well as reads bytecode, prior to converting to Javascript. It needs this for it's Generator system (ClientBundle, RPC, UiBinder, etc) to work.
I have multiple conspiracy theories about Dart: one of them says that it will replace Java on Android, beginning from the UI framework. So take what I say with a grain of salt! :D
The other says that it will replace UnityScript and C# as the scripting language in Unity3D, when Google buys Unity. See, my theories are crazy... you can ignore me. :D
+Ray Cromwell It doesn't need to be a port or rewrite. The question is: as more and more functionalities overlap, why both should be maintained in the long run?
I'm biased in this, since Ihelp maintain the GWT compiler, but in an ideal world, I'd build it more like GCC or LLVM. I'd keep the GWT backend optimizer, and make languages just frontends to it. So for example, right now, there is a Scala frontend for GWT that enables GWT to compile Scala code. For Dart, I'd build a Dart frontend.

The idea being, don't keep rewriting the optimizer and JS backend.

If Dart takes off, there will likely be many compiler implementations, just like there are multiple implementations for Java (javac, jdt, jikes, etc)
BTW, there are good reasons to have Dart written in Dart and as a separate compiler, because Dart has a different compilation model, does not need to be type checked (if you don't want), and doesn't have any dependencies on the GWT/Java APIs, so it makes less sense than say, Scala, which can call into Java APIs.
+Adam Hawthorne Regarding a Dart backend for GWT... I think we can wait and see how much demand there is. It doesn't seem like a particularly hard thing to do if it turns out that there's a ton of value that comes from it.

At the moment, I'm more focused on tools that help people write apps in Dart in the first place. But when the time is right, it's easy to imagine various useful code generation hybrids, migration tools, etc.
Do you have scheduled an integration between Dart and GWT?

Why Google will continue to maintain two projects with the same purpose?

GWT each day is making more space in the companies through which is based on Java and good integration with the server. The integration with android every day is better. I hope this will continue.
+Emilio Bravo Please see my comment above about integration between Dart and GWT -- it's too early to say what sorts of integrations will make sense or be worth the effort.

Why two projects with the same purpose? GWT exists, it's mature, and it's in heavy use inside and outside of Google. As I mentioned in the blog post, we think Dart can take GWT's mission to the next level. There's naturally going to be a long period of overlap. As Dart proves itself in the coming months, I hope and believe many GWT developers will find it attractive and will start experimenting with using it for new projects.
I dont ever mind trying a new language,pretty sure I could pick anything up quickly.

But my worry is the (vaste) set of usefull reusable gwt java code I have been building up will be useless in a few years, making me have to start from scratch rather then building up and up.
+Thomas Wrobel
Your existing GWT/Java code shouldn't become useless any more than the gobs of such code inside Google would. That's really the key point of the blog post -- nothing precipitous is happening. That said, I feel a lot of momentum around Dart. I think it will catch up reasonably fast, so making the switch at some point might be less disruptive than it seems. You can check in at to keep an eye on progress.
+Bruce Johnson What will happen to existing applications developed in GWT?, Are you planning a migration of these applications to Dart?.

Now is a great time to GWT, can be positioned as a preferred framework for developing RIA applications for business, thanks to both the front end and back end can be developed in Java.

To facilitate the adoption and stop the rumors are emerging about the death of GWT, I think it would be advisable to present a road map to both Dart and GWT.

I take this opportunity to congratulate you for the great work you have done with GWT.
+Bruce Johnson, if possible provide us a GWT road map. It will help us to make important decisions in new projects.
One nice thing about GWT is that you can use all the open source Java tools on it. With Dart will Google now have to develop DartUnit, findbugs, emma, ReplayDirector, etc all for the new language? It seems like GWT development has stalled, I haven't seen anything about GWT 2.5 or whatever is coming next. Seems like all the GWT programmers have already moved to Dart? Also not sure from the postings when a usable (rather than experimental) version of Dart will be available to really play with?
One of GWT's huge advantages right now is, write once, run on every browser, due to deferred binding. I save a huge amount of time writing UI's in GWT because of multi browser awareness. I wouldn't mind switching but because I see improvements, but dart will have to move to a higher level of multi browser awareness for me to switch. And maybe this is a non issue and I don't see that yet. +Stephen Smith is right, it does seem look like the GWT developers have moved to #dartlang.
<ahem> There are still GWT developers working on GWT. :)
From an external point of view, the activity around GWT has slowed down during the past monthes. Rjrj & BobV have left and their contributions seem to be frozen (Activity & Places need more simplification, RequestFactory/Editor is still buggy and over-complex, ...). I think, it is really important to make an official clarification around Dart & GWT. Talking about "a long period of overlap" means that the target is the replacement of GWT by Dart, which doesn't make sense regarding the Java language adoption.
All these comments and the GWT team's absence makes me notice that this is not a good time for adopting GWT in brand new projects.Thanks guys.
Many of Google's services are still being written in GWT and won't change anytime soon, for example AdWords and AdSense, from which Google derives the majority of their revenue, are written in GWT, so given that fact alone, GWT will be around for a long time and continue to be improved. 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.

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.

Obviously, we want Dart to be a huge success, but even if it is, Java isn't going away anytime soon. :)
Thanks Ray. We are anxious to see compile time improvements. Hope GWT never leave the Java world.
Thanks Ray, these all look like excellent improvements. Nice to see that GWT does have a roadmap going forwards.
Thanks for sharing, that is exciting to hear of more HTML5 stuff coming. I also saw a dev picked up issue 6813 recently Chrome OOPHM slowness, which is exciting to see too.
Love your enthusiasm Ray! the company I created 5 years ago work with GWT since the beginning, in fact since the day I discovered this class (which summarize very well what GWT is really) =>
The compiler is what makes GWT for me a unique technology (waiting Google to buy Ext-GWT when they will fill the gap with GWT core model). That said, I feel kind of uncomfortable when I see Bruce advertising a concurrent framework (I'm kidding Bruce ;-)) and Joel switching to other funny tools. And Scott, where is scott ? Lex ? Miguel ? I understand that turn over is natural but the GWT codebase is so complex that we need stable comitters if we want to improve it.

I hope to see Dart quickly joining the Dark to let GWT shine ...
Lex sadly left for a startup company a while back, but he still chimes in on Scala GWT once in a while. +Joel Webber works on just about everything, you can't pin him down. :)

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.
Thank you very much Ray. For too long we were left reading between the lines, and you comments here are both surprising (we are not used to too much information) and very welcome.
Reading between the lines got very hard since you guys stopped using SVN for your feature branches - at least in the past we could follow the work on the repository.
Another reading-between-the-line source were comments on the issues, but now most issues are "PatchesWelcome". I don't think anyone did really think that patches were not welcome, so, to be honest, "PatchesWelcome" reads more like "we won't do it". I don't see those issues getting done in the near future, and the list reads like the list of "no gos" you have to think about before choosing GWT.

Take Calendar - most starred issue: we have a few solutions out there, none of them really good. Sure, java.util.Date and java.util.Calendar is nothing to be proud of, and I am sure I am not the only one willing to accept a new API, any API, as long as we have one. None is no solution, and I am not going all the way back to the server for some date time operations.

Take Browser Plugins: I know that this is something that no one at the GWT team had seen coming. But the problem is here now. And I know the full story, and I am sure we should not spend any more minute on finding someone to blame. But, as a matter of fact, the plugins are part of the development cycle and we badly depend on them. I am on a Mac, and really, I have never seen something so buggy as like GWT plugin running on OmniWeb.

Could we get a little bit more insight?
In reverse order, Browser Plugins. So, DevMode has very stringent requirements for Browser integration, namely an API in C/C++ that allows synchronous, reentrant, calls from C->JS and JS->C. Two changes have happened to browsers that have created a perfect storm - sandboxing and fast updates. Once browsers starting trying to sandbox plugins in their own process, they realized that the legacy plugin APIs cause trouble. Safari5 (now based on WebKit2) and Chrome found workarounds to keep it going, but the workarounds cause problems with compatibility (See as well as performance problems with the extra overhead making inter-process calls through the sandbox. We have not yet found a way to fix DevMode for Safari5 and have been told to use WebKit2 APIs, but this is a substantial re-engineering effort for a tiny browser marketshare. Chrome on the other hand, has issues, but we may be able to fix them. But Chrome is promoting an alternative to NPAPI called PPAPI, so you can guess that NPAPI compatibility and performance improvements aren't high on the priority list for Chrome.

But the second problem is much worse: Browsers used to be a relatively stable target and would update once a year. Now Chrome and Firefox push out updates every few weeks. These updates often break DevMode (Firefox 6->7->8), and have outstripped our ability to keep up. Whereas DevMode used to be maintained by 20% effort of some team members, now we face continuous updates on 3 different operating systems every few weeks. It is not really the loss of Ray Ryan, Bob, Lex, or others that is the root cause, but the fact that DevMode is deeply tied to the guts of the major browsers, and they are now changing those browser's very often, and DevMode performance relied on fast C->JS calls which conflict with the goals of sandboxing.

Next issue, Calendar. Calendar has remained unimplemented (like String.format, and some others), because doing so would add significant bloat IIRC, and GWT has always been concerned with trying to avoid high costs for certain APIs, and we've been selective as to what JRE APIs we implement. In the past, people who have wanted Calendar functionality have ended up using GWT Joda Time. That's off the top of my head. I realize it is an inconvenience, but if someone were willing to implement Calendar, and in a way that isn't a lot of bloat, I'd be happy to look at including it, it just hasn't been a priority due to more pressing issues (DevMode) that block people from getting work done.

Patches Welcome: Even prior to the turnover, and Dart, the GWT issue tracker has been, shall we say, under nourished. After Google acquired Instantiations (for GWT Designer), we got Eric Clayberg to join the GWT team as a manager, and Eric doesn't like to see a bunch of issues piling up with no response. We decided as a team to spend some time triaging the issue tracker, and as a result, hundreds of issues that have been left unassigned (some for years) were changed. GWT is an open source project and we have always relied on our community to help us, in fact, I started out as an open source contributor, it's how I got hired by Google. PatchesWelcome is better than "WontFix", it basically means, we are willing to fix it, but we need community help. Right now, we are focusing on core issues that have broken GWT or blocked development, and so things that are 'nice to have' like Calendar would be welcome additions from the community.

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. So, for example, we are integrating Closure Compiler with GWT. If you look at the SVN for GWT and GWT Tools, you can see I've been slowly preparing this for weeks. First by checking in the closure jar files, and the source map code, and just yesterday, John Lenz landed an initial implementation (somewhat broken and switched off by default). In the past, we would have never landed code like this, instead polishing it completely in a branch first. Now, we land useful partials, and iterate on them.

Hope that answers some questions.
Ray your answers are welcome and shed some light on the murk, but having been working with GWT for many years i definitely see things have slowed down considerably. That might be due to some of the folks leaving, but i think GWT is going in maintenance mode for now till DART catches up. Nothing wrong with that, but DART itself has been fluid and there is no guarantee when it will be usable. I think everyone is waiting for a complete DART release, but that is long ways. In the meantime it will be hard to get new GWT adopters and maintenance mode will soon become "no longer supported".
I can assure you that GWT is not in maintenance mode. Not even close! Quite the contrary, GWT is very 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 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.
Thanks Eric, i am hoping there is a migration path if and when Dart matures. Have used GWT and love it and GWT guys working on DART inspires confidence.
+Bruce Johnson you at Google have tons of GWT code, so a GWT to Dart migration tool should be just a matter of time? It's not really about a GWT-to-Dart compiler but much more about a sufficient migration tool for GWT devs so they can transform their code to Dart once it's ready for production.
+Alexander Orlov Exactly, although when to attempt such a converter is an open question. An even more important question is how to manage expectations regarding such a converter, since it's likely to do an imperfect job. Still, a converter of some sort could be a good accelerator when the time is right. At present, Dart isn't yet in a position for use in production code in the way that GWT is, but it is a good time to explore Dart and provide feedback. I would particularly love to hear feedback from people using GWT, since it's meant to be suitable for the kinds of apps as GWT.
Dart is still very incomplete. From what i have worked with UI components are still missing and many features will need some more time to mature. That being said waiting for a complete library and hoping community picks up Dart and builds DartUI components like Jquery.
In a couple of weeks I'll release a GWT app that I've build for about one year (my full time job). For me Dart is the logical successor of GWT and I would like to add functionality to my app using Dart once it's considered production ready. Also there is the problem of how JS code generated from GWT and JS code generated from Dart will communicate with each other. This problem has to be solved as well as it's likely that huge GWT projects won't be converted in one single step. You've already mentioned that a GWT-to-Dart converter won't be perfect...
Thanks for all these explanations on gwt and dart. I feel now more confident in future of the gwt.
@Ray: Is there a plan to make the gwt git public anytime soon? It would ease the work to follow the technology and increase the link with the great opensource community around.
Haven't seen much GWT (Java) evolution from months. Actually I don't believe in its future anymore. I think Google forgot us Java people to focus on Dart. Unfortunately.. :-(
It has been about 4 months since Ray's post on what the GWT team is working on. In that time there has been only one GWT official blog update and no releases for 6 months.

There needs to be some official signs of life. If the GWT group is fully staffed then it should not be possible to communicate that in some way.

At Caltech we have been using GWT for over 4 years. We have build a very large and amazing set of web applications using GWT. We are very invested in GWT. While I think Dart has great potential, I would like to see some real sign of life in GWT beyond a Google+ post.
+Trey Roby just look at the SVN logs. Something is going on and GWT 2.5 will get some new but minor SafeHtml/Cell related features and especially a more performant DevMode. And thanks to source maps it should be possible to debug the GWT code within Chrome. But one thing should be clear: Dart is clearly the next generation GWT. #dartlang
GWT is relatively mature and there are diminishing returns to adding new and exciting stuff outside of bug fixes. Although there is some new stuff in the pipeline: SourceMaps, SuperDevMode, a new html5/collections library, Closure compiler as a backend, new CodeSplitter 2.

Even if Google decided to just drop development of GWT, consider that it is an open source project. Would Python die if Google stopped paying Guido? Part of the point of open source is to prevent a single company from holding vital projects hostage.

To some extent, we've actually done that, to the detriment of outside committers, and we're trying to rectify that. After Google started using GWT internally a lot more intensely, it became harder and harder for external committers to land patches due to the need to review and test everything to make sure it doesn't break Google products. It's my hope that external developers can contribute to GWT's evolution easier so that that Google internal management decisions have less of an impact.
Shen Z
GWT guys should stop playing with fancy ideas( like mvp or databinding things), but to create more useful UI widgets/plugins. I think GWT will attract more java developers because it has certain advantages over javascript (Jquery etc). But Dart? For God's sake why do I need to learn another language. There is no way Dart can beat Jquery or even plain Java script, there is no future for it.
"Dart is clearly the next generation GWT"

Dart is another language, it cost time and money to train developers a new direction. We use GWT because it is Java on both sides. It is fast, easy and it delivers. Why would we be using Dart instead.

GWT only has one drawback, it is slow on compile.
Unfortunately... I strongly believe Google will drop (or donate) GWT Java after GWT Dart gets up to speed. They have been doing this with many other tools/frameworks and, right now, I think they are trying to move away from Java because of the Oracle x Google dispute.
+Bruce Johnson [November 2011] "we plan to continue improving (and open-sourcing) GWT based on their real-world needs."

Happy birthday: lastest fixed issue for GWT API 1 year ago !
The issue tracker doesn't reflect the current state of the world. GWT 2.5 contains hundreds of fixes. For most of GWT's life, it was on a yearly release schedule (usually Google I/O). The new process when it is launched will make point releases more frequent as well as being able to depend on mavenized nightly builds.
"Oracle x Google dispute" ... now that's an interesting timeline coincidence here.  Btw, it seems pretty clear in wikipedia that DART would not be adopted across browsers...what good is that?  I haven't been following too closely so I must be missing something...
Add a comment...