GWT doesn't mandate MVC, and it is not meant to "hide the Web", it states as such in the original mission statement. GWT is three things: a cross compiler to Javascript, a development environment, and a bunch of libraries that are layered. GWT != HTML Panel. The naming is unfortunate, GWT really should have been called 'j2js' or some such, to emphasize the fact that its most important function is an optimizing compiler (it is not a transpiler)
You can build GWT applications that use nothing but HTML templates, low level jquery-like operations, and avoid all of the high level MVC cruft, in fact, many GWT applications, like Google Flights or Google Shopping Express are built exactly this way. I wish the Widget system had never been layered on top (along with MVP) because it gave people a false sense that it was the only way to use GWT, and it was primarily useful for supporting older browser like IE6. There was a justification of 'hiding' some of the Web when you had to bridge IE6 to modern, and many third party JS libraries took similar approaches at the time. The days of IE6 support were painful and once of the reasons for the success of GWT in enterprise is all of those WinXP IE6 desktops.
The primary pain of using GWT these days is the compile times, and the overhead of interacting with Javascript (JSNI). Both of these are being solved in GWT 3.0 along with language boilerplate complaints thanks to Java 8. For example, here is an example of GWT using Polymer components effortlessly https://www.youtube.com/watch?v=wFMD1GXR2Tg
GWT 3.0 deprecates the old DevMode and replaces it with a fast incremental compiler. It replaces JSNI with a new @JsType interface. It boils away asynchronous callback boilerplate with auto-conversion of Java8 lambdas to JS functions and vice versa. The new DOM apis will be auto-generated as @JsType interfaces by directly reading W3C IDL specs, not hand-written as they are today. And it will be possible to read JsDoc and TypeScript interfaces and extract API interfaces from them.
GWT 3.0 will be about lowering the barriers, the friction, between the Web, JS, Native, and GWT code bases, to make polyglot programming as easy as possible. It will also be about hybrid apps, that are part native, part web. See the new Google Sheets 2.0 as an example, it's Java code cross-compiled via j2objc and married with a native UI on iOS, and cross-compiled with GWT and married to Closure UIs on the Web.
I'm endeavoring to make things "and" not "either-or", to give developers as much choice to use as little or as much of GWT as they want. As an example, see AngularGWT, which uses AngularJS 'as is' but lets you write Angular controllers, directives, etc in Java, including using JSR303 BeanValidation to do form validation in Angular.
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.
Did you ever saw a GWT application that was not done using the GWT hierarchy of widgets, apart from Google Flights or Google Shopping Express?
Because I have seen many GWT apps and I never saw GWT being used that way, I can't see how a very large portion of developers completely misunderstood the right way of using a framework.
Usually the full GWT ecosystem is used in order to build enterprise apps: templates in UIBinder, GWT widget hierarchy, MVP frequently not always, Editor often, Request Factory often, etc.
You mention that the problem is compilation times, but this is not a problem. In Dev mode there is no need for compilation, the compilation happens in the background in the build server whenever a release is needed.
What you describe for GWT 3 seems way more complex that just using plain Html, CSS and Javascript with some framework on top.
I don't see how all that complexity of compilers and plugins and dev modes can pull it's weight compared to one 100k js file.
>Did you ever saw a GWT application that was not done using the GWT hierarchy of widgets, apart from Google Flights or Google Shopping Express?
Fights, Hotels, Shopping Express, Wallet, Google Sheets, Collide, Animatron AFAIK, Angry Birds and most PlayN games, I'm on vacation now, but if I was at my desk could probably did up a lot more Google internal ones. Also look for projects using GwtQuery.
>You mention that the problem is compilation times, but this is not a problem. In Dev mode there is no need for compilation, the compilation happens in the background in the build server whenever a release is needed
DevMode is going away. The NPAPI APIs we used have been taken from us by the browser vendors. Neither Chrome nor Firefox support the ability of DevMode to run anymore. IE will probably continue to work because of how slow they retire older browser versions and APIs. No mobile browser engine not Mobile IE, not iOS Safari, nor Android browsers, supports DevMode.
That is, the very majority of the market has locked down plugin APIs (for good security reasons), which unfortunately means the way GWT was inserting the JVM as a JS bridge during development will no longer work. The new path forward is SourceMaps + Fast incremental draft compilation.
As for complexity in GWT 3.0, the idea is you just use HTML and CSS, and any JS you want, and SuperDevMode for any Java.
As for how the compiler can justify it's existence, that's primary a question of aesthetics for Java developers who prefer their existing tools, and for people who prefer optimized code.
And the SuperDevMode in GWT 3.0, will it be browser-only debugging like the current experimental SuperDevMode?
Because if it's browser only, then it would pose a problem for most Java developers, that like you mentioned prefer their existing tools, in this case the IDE-based debugger.
Note that GWT 3 will see the birth of incremental compiler plus super dev mode, which will actually be FASTER than Dev Mode.
I don't know about you, but the dev-mode lag of jumping back and forth between browser and jvm actually makes dev mode painful to use, especially on very large projects that can take many seconds to reload fresh code.
As someone who does work a lot on raw js projects using GWT (including Collide, as mentioned by Ray), I can say I'm very happy to see widgets de-emphasized in favor of using html5 features, like web components.
When I'm building a view, I rarely care about a widget hierarchy; rather, I just want to construct some html, inject some css, and attach some event listeners.
Writing my business logic in java means I can share it with web, android and ios (via j2objc); for that web view, I'm building html, and rarely need the abstractions provided by widgets. If I do need widgets, I usually use a composite with ui binder so I can control the html myself anyway.
Wow, this is fantastic. After a couple years of heavy use, I abandoned GWT during the lost-its-marbles insanity of MVP and and what appeared to be a concerted effort to give GWT all the grace of EJB2.0. I still miss GWT-RPC, dead code detection, static typing, and the sane deployment model. GWT3 could bring me back.
One thing that always bugged me though is the mismatch between Long and JS numbers. GWT is trying to be pedantically accurate with numbers, which is great from a "compile Quake and see it run on the client" perspective but incredibly annoying when trying to interop with native JS code. Many of my ids are numbers; I need these numbers to easily convert to JS numbers - and yes, I do actually know that they will fit within JS precision. Does GWT3 fix interoperability between Java Long and JS Number?
If you want IDE based debugging for sourcemaps, please see http://github.com/sdbg/sdbg which is a sourcemap (super dev mode / draft compile) based eclipse plugin, for making java debugger speak chrome debugging protocol.
The project needs more users to try it out, report reproducible issues, and drive its development.
You can build GWT applications that use nothing but HTML templates, low level jquery-like operations, and avoid all of the high level MVC cruft, in fact, many GWT applications, like Google Flights or Google Shopping Express are built exactly this way. I wish the Widget system had never been layered on top (along with MVP) because it gave people a false sense that it was the only way to use GWT, and it was primarily useful for supporting older browser like IE6. There was a justification of 'hiding' some of the Web when you had to bridge IE6 to modern, and many third party JS libraries took similar approaches at the time. The days of IE6 support were painful and once of the reasons for the success of GWT in enterprise is all of those WinXP IE6 desktops.
The primary pain of using GWT these days is the compile times, and the overhead of interacting with Javascript (JSNI). Both of these are being solved in GWT 3.0 along with language boilerplate complaints thanks to Java 8. For example, here is an example of GWT using Polymer components effortlessly https://www.youtube.com/watch?v=wFMD1GXR2Tg
GWT 3.0 deprecates the old DevMode and replaces it with a fast incremental compiler. It replaces JSNI with a new @JsType interface. It boils away asynchronous callback boilerplate with auto-conversion of Java8 lambdas to JS functions and vice versa. The new DOM apis will be auto-generated as @JsType interfaces by directly reading W3C IDL specs, not hand-written as they are today. And it will be possible to read JsDoc and TypeScript interfaces and extract API interfaces from them.
GWT 3.0 will be about lowering the barriers, the friction, between the Web, JS, Native, and GWT code bases, to make polyglot programming as easy as possible. It will also be about hybrid apps, that are part native, part web. See the new Google Sheets 2.0 as an example, it's Java code cross-compiled via j2objc and married with a native UI on iOS, and cross-compiled with GWT and married to Closure UIs on the Web.
I'm endeavoring to make things "and" not "either-or", to give developers as much choice to use as little or as much of GWT as they want. As an example, see AngularGWT, which uses AngularJS 'as is' but lets you write Angular controllers, directives, etc in Java, including using JSR303 BeanValidation to do form validation in Angular.
https://github.com/cromwellian/angulargwt