GWT hasn't ever rebooted, unless you count HostedMode -> DevMode. It has removed hardly any of the old APIs going back to 2006, which is part of the problem. Ev

GWT hasn't ever rebooted, unless you count HostedMode -> DevMode. It has removed hardly any of the old APIs going back to 2006, which is part of the problem. Everything you refer to was an add-on layer of functionality that did not remove the old. Every single platform adds new layers. Windows, Android, iOS, J2EE. Each release brings new and better ways to do things. We have paid the price of actually supporting the old APIs for too long. 1) GWT widgets were designed to overcome IE6 memory leaks and layout deficiencies. IE6 is gone, not even Microsoft supports it any more. 2) deRPC was an experiment and marked as such. It did not change the API calling surface or semantics, and apps could switch between the two very easy. The theory of deRPC was that it would be faster than deserialization code, that turned out to be wrong for most browsers. To make deRPC work required all kinds of hacks in the compiler, in DevMode, and yet another symbol map format. Removing it makes GWT better. It's also incompatible with CSP and introduces yet more security surface area to worry about. 3) Google applications like Adwords continue to rely on old GWT APIs, and we have been fixing serious core bugs as we find them, but we are not a large team and we have to support over 3,000 internal engineers. Part of the reason GWT is now controlled by an external committee is because the focus of Googlers is to prioritize and fix bugs for internal applications, that's how we continue to keep our jobs. GWT is an open source project, and if a particular bug is not getting a lot of love, we invite either the contribution of a patch, or to talk to ArcBees, Vaadin, or RedHat who are providing commercial support. 4) Issue Tracker, I talked about this in my Google I/O announcement of the steering committee: The reality is, around 2009, as GWT got more internal popularity at Google, engineers paid more attention to the internal Google issue tracker rather than the external one, and the external one became unreliable as a source of truth. This was a bad situation caused by the mostly exclusive control of GWT by Google, which is why I advocated turning over control to external users, and moving the entire GWT development process back to non-Google infrastructure (until the recent change, our internal source repository was the real source of truth). Ideally, we'll eventually move everything to GitHub. So yes, from about 2009-2012, honestly, we didn't pay attention to external users bugs, we prioritized internal bugs. We're trying to rectify that now, but we can't tell which of the thousands of issues in the issue tracker dating back to 2006 are still unfixed and how many got fixed and no one ever marked them closed. The 'ASSUMEDSTALE' status is an attempt to crowdsource the fixing of the issue tracker, since we assume if someone had starred a bug, and it got closed, they will complain it's not fixed, which gives us valuable feedback. Once he issue tracker is triaged back a usable state, we'll be in a better place. It's not like other projects don't aggressively close bugs, many use robots which auto-close bugs are a few months. 5) We are not just trying to get "the cool kids". The world has changed since 2006. The modern browser environment is substantially different. Javascript VMs have evolved a lot. Mobile browsers are now a substantial force. The world is changing, Google, who is the biggest backer, writes bleeding edge web apps, and so changes with it. We don't get paid if we can't support the kinds of apps Google wants to write, and that's increasingly a modern Web world. If someone else things this is a bad idea, they can fork GWT, freeze it in time so support the Windows XP/IE6 legacy, that's the power of open source. The steering committee is already planning to keep the 2.7.x line updated with bug fixes from the 3.x line.