Once again GWT is rebooting and has a whole new way of doing things as an effort to take over the world, at the expense of people who bought into one of the previous visions and have large legacy code bases.
Every release since 1.5 (which is as long as I've been paying attention) has come with an entirely new best practices paradigm and neglect for keeping the penultimate new shiny working. Remember deRPC? Integration with Spring? LayoutPanels? Activities and Places? Is RequestFactory even part of this brave new 3.0 world, or is it all supposed to be JSON now?
There's a severe mismatch between the people that develop GWT, who seem to wish they were working on a bleeding edge library in a trendy language and be popular among social start-ups, and the people that use GWT, largely enterprise programmers working on LOB applications. That doesn't seem to have changed any with the new council model.
It doesn't matter how many times the project pivots, the hipsters are never going to use java. Much better to care about the users that have actually adopted GWT -- people that want backwards compatibility, stability, and bug fixes.
A project that closes the majority of longstanding bugs with status ASSUMEDSTALE rather than fixing them really doesn't care much about its existing users. Or new ones really, since many of those old bugged classes don't have formal deprecation notices on them.
> Once again GWT is rebooting and has a whole new way of doing things as an effort to take over the world, at the expense of people who bought into one of the previous visions and have large legacy code bases.
Same could be said for new-again JS frameworks popping up every year or so. If your legacy code is in any previous JS framework it's not going to magically update itself to the latest hotness.
> It doesn't matter how many times the project pivots, the hipsters are never going to use java
GWT isn't aimed at hipsters. The changes are for the people using it already, who want to build things and would like improvements. Not to convince the cool kids that they need to replace their 1-line monkey-patching nirvana with objects and static typing.
It's not about building something in less time or abstracting away the document model because we don't understand it. It's about not losing your mind a year later when you need to make a change. It's about refactoring cleanly and knowing that when something has compiled, a whole class of problems is off the table.
You are right that GWT has been a lot of things over the years, but, to be fair, it's been around since 2006. E.g. you mentioned the GWT 1.5 release, that was in 2008.
What other web (or client-side JS) frameworks that were released in 2008 look today at all like they did back then? Or how many of them even still exist/are actively maintained?
GWT's biggest obstacle is it's continuity.
Take the circa-2010 MVC/RequestFactory push; in retrospect, that (and LayoutPanel, and Spring Roo integration, and...) should have been completely separate "webapp frameworks for GWT", not "in GWT".
Then they could have gotten some users, e.g. picked up by that era's greenfield LOB apps, and then quietly aged away. Just like the normal life cycle for any other legacy webapp framework.
But because it's under the "GWT" roof, it lives on, and people have expectations that it'll supported by the GWT team just as much as the core "Java to JS" translation engine.
So, yes, all of your criticisms are valid.
But I assert GWT has learned its lesson: the language (GWT's j2js compiler) should be divorced from frameworks (GWT widgets, userland, etc.), because they really are separate things, and can better evolve on their own. Unfortunately it'll be a hard transition process.
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.
Every release since 1.5 (which is as long as I've been paying attention) has come with an entirely new best practices paradigm and neglect for keeping the penultimate new shiny working. Remember deRPC? Integration with Spring? LayoutPanels? Activities and Places? Is RequestFactory even part of this brave new 3.0 world, or is it all supposed to be JSON now?
There's a severe mismatch between the people that develop GWT, who seem to wish they were working on a bleeding edge library in a trendy language and be popular among social start-ups, and the people that use GWT, largely enterprise programmers working on LOB applications. That doesn't seem to have changed any with the new council model.
It doesn't matter how many times the project pivots, the hipsters are never going to use java. Much better to care about the users that have actually adopted GWT -- people that want backwards compatibility, stability, and bug fixes.
A project that closes the majority of longstanding bugs with status ASSUMEDSTALE rather than fixing them really doesn't care much about its existing users. Or new ones really, since many of those old bugged classes don't have formal deprecation notices on them.