How will GWT win back its community ?

Waiting for GWT 3 has always been confusing for me - no deadlines were given (though some might have seemed implied, but by the same token Java9 and Java8 were failures since they even didn't ship everything that was promised), and shipping an inferior product seems strictly worse than continuing to use the existing stable, long-lived compiler.

Likewise, "not finding GWT devs" confuses me - if you truly need expert level work to modify the compiler, your options may be limited, but even something as advanced as a Generator is plain Java (and has been discouraged for years in favor of the plain Java technology: APT).

A "GWT Dev" is someone who can write Java, and someone who knows the browser (or can read documentation). I sometimes suggest that it is easier to take a great JS dev and teach them ("force them to use") Java so they can better function in larger teams or on bigger products (do you know a lot of million-line JS apps?), than it is to take a bad Java dev who can only write the same hibernate beans and spring services over and over again and try to make them understand events and the dom. Maybe your hiring pool is full of terrible Java devs, or maybe your JS dev pool hasn't realized that Java is invading JS (JS supports "class" now, and Java has lambdas). Alternatively, if your dev pool only builds things based on fads... I'm not sure how to help you ;). Maintainability will never be a fad, and while "testing" was for a bit, it seems to have faded.

The direction ("use APT, not Generators", "use JsInterop, not JSO/JSNI", "use JRE classes, they will keep working") has been clear and consistent, though perhaps too simple, and easy to confuse for "no roadmap". This advice works in GWT2, and will work in GWT3 - the chief difference will be "how should my app organization change?" "how do I compile my app?" and "why is this so much faster?"

Admittedly, there are pain points around Elemental2 still, but they are fairly easily worked around. But the prime selling point for GWT for me has always been "Use Java, so your codebase and your team can scale, and can stay maintainable." Equally easily, you can write only shared/logic code in Java, and export it to JS for a JS-only team to use it in client-side products - JsInterop has given us that easily for several years, and various JSO exporters before it.

But there is no ticking clock on GWT2 - it isn't going to stop working, it has been actively maintained all the while, with new releases and bugfixes. If you can only code with the "next big thing", how do you ever start a project - there is always a "next big thing" just around the corner. GWT3 isn't going to change the world, but it isn't meant to - you'll still do what you do today - write Java, get highly optimized JS. Maybe maintainers don't pitch it well enough, but I'm not sure I want anything to do with a toolkit that relies on flash and noise, rather than solid substance.

(Sorry if that sounded ranty, but the initial post seemed like it had its own frustration, and the message confused me. Downvote as necessary, or lets discuss! And I'm very happy to argue any of this in person at the conference as well)

My question is mostly about how will the GWT team win back public interest. I don't see it answered anywhere. The core team and steering comitee seems to be a bit disconnected from reality. This question has been asked by many people and like it or not it is an important factor in deciding what technologies to use for large scale applications.

Big companies who want to invest 100+ staff years projects want to have some confidence that the technology they use will adapt to future needs. Maybe you see that as irrelevant but in enterprise development it is an important consideration - obviously not the only one, but it is a factor. So if we chose GWT 2.8, we need to know what the path ahead looks like. 

The current message we get is not very nice: There will be a GWT 3.x but we haven't started on it yet oh and don't use anything except for a few basic features. I'm hoping that GwtCon will reveal some more concrete information on the direction.

As for seeing GWT development as just Java is clearly a misleading view. When you hire people with Java skills you expect that they know more than just how to write a class. They need to understand how to write a maintainable applications with clear design and understand multithreading, database technologies, J2ee related technologies.

The skillset for a good GWT developer is not really the same as for a Java developer. Such a developer needs to understand that he is working inside a browser with other technologies. There are no threads, not all Java api's are available. CSS and HTML is not something you can ignore (especially since Widgets will no longer be supported)... so the skillset is quite different. Writing APT is also an interesting aspect that is not well documented and also requires a different way of thinking. Java people are often using introspection for tasks that with GWT requires generators for example.

I won't be present at the conference otherwise I would have been glad to have a further chat about my reason for asking this question. The reason why I am probably also sounding a bit ranty is that I believe in many of the ideas behind GWT and I believe that 3.x will be a very good step forward (2.8 is already a major step, I really love the lambda support and JsInterop is nice as well).

I am also confused, i have seens developers at the company i work for who learns some really complex frameworks and libraries, then when i show them some gwt project, they argue that they need lots of time to learn it, come on ... A java developer needs time to learn java ???!!!!!! How that could be???!!! Gwt is basiclly java nothing more, you just get that java to javascript transpiler as extra.

Recently i was able to make my own gwt platform in which i made a simple todo application that using the same code base, i could run it as web application with 2 different flavour of the ui, polymer elements and material design widgets, and as a plus the same application using the same code base now runs as a desktop application using javafx.

I dont think js frameworks can give you that, I CANT IMAGIN A BETTER GWT THAN THIS YET I AM WAITING FOR ONE BECAUSE THERE WILL BE ONE.

It is about personal interest if people chose a career path in backend development or UI development. Saying that learning GWT is just learning Java is clearly an understatement. Java is just the language and it allows you to share code with the backend as you mention - and that is great. 

But at runtime there is a huge difference. You cannot implement a large scale GWT based application unless you have a good understanding of the underlying platform it is running on.  Just like you can't implement a scallable backend with Java developers who don't understand threading, garbage collection, classloading, introspection, resource management, database technologies,  ... the skillset is obviously different.

<quote>... and that is a hard sell if you need to develop software now.</quote>

If you need to do it now, just take GWT 2.8.x, you have some nice UI frameworks on the top like: GwtBootstrap3, GwtMaterialDesign, Sencha GXT, Vaadin (ok, this has a server-side part), Errai, ... They work now. So I'm not sure whether I understand you correctly? Or maybe you need a framework which is supported by big companies like Google, Facebook? Google still uses GWT. Eclipse Che uses GWT too (http://www.eclipse.org/che/docs/assemblies/sdk-parts/index.html). 

I think the question is more something like "I would like to join the JavaScript hype" or stay in Java with all those pros for Java.

Nope the question is: how will GWT win back public interest. 

As for going for your proposed solutions ... it does not sound like a convincing argument since we all know that most of these things will not be supported in the next major release. Staying on 2.8 for 10 years does not sound like a good idea. I'm not talking about porting a todo application but about porting an application with hundreds of non trivial screens.  It's not like we will be able to go from the 2.x branch to the 3.x branch on a screen per screen basis, it will be a major effort where everything will need to be ported.

Today presentation from Colin would be interesting for you... 2.8.2 is in a full development, please see the commits in GitHub. 2.9 and 2.10 would be the next. GWT 3 == J2CL still not finished yet, and some tools still missing but we have seen J2CL in action.

In your position I would refactor the monolith structure into Micro UIs. It is always tough to have to migrate the whole thing at one time. This is also the advantage of Microservice architecture. See the presentation of Alberto today about TURDUCKEN. When you already have the microservice structure you can migrate as you go.

I'm looking forward in seeing the videos of the presentations.

I am indeed thinking of having smaller applications. But these apps have to be consistent even if they are not all implemented with the same technologies. So some things will become Web Components or just JS objects with TypeScript definition but developed with GWT.

Yes, Microservice and Micro UI are the way to go, see my slides and my blog. Rewriting everything without thinking of the value is waste of time and resources.