GWT 3.0

I do agree with you and such basic overview could be a great thing to have.

I am especially interested in the Widget system.
Will this still be usable in GWT 3.0.

We created really advanced widgets like Grids with locked headers, grouped data, editable, sortable, .... that we really would like to continue to use. Leaving the widget system out will be a huge disappointment for us. The Widget system was one of the key reasons to use GWT.

Thanks for the feedback - we have some limitations here in what we can talk about in general, please forgive how the process has to work.

The plan for GWT3 is ongoing, and we already know what the language will look like - Java, with JsInterop to talk to non-Java code. The build system and the ecosystem makes for a more complex topic, though until the tools are ready to be used there isn't much to say. The ecosystem on the other hand - that is a topic that can be started already, and need not wait on anything more from the steering committee or GWT contributors - JsInterop is here and stable, Elemental2 is approaching stable, and we're already seeing new tools and ideas pop up like elemento, and research across the community into APT.

Frank, I personally think you are right about widgets, even if they aren't com.google.gwt.user.client.ui.Widget - why even use Java if we don't have rich, well thought out abstractions that we can code against. Many of us are experimenting with work to port existing GWT staples into a future without jsni and JSOs - nearly all of them look reasonable and some might even not require any substantive changes at all in downstream projects.

Here is the one argument against com.google.gwt.user.client.ui.Widget: like GWT2 itself, it was designed for a world which thankfully no longer exists: We no longer have a majority of browsers leaking memory just for daring to listen to events and change the dom. The whole "sinkEvents"/"sinkBitlessEvent", root panel with attach/detach cycle, and the __listener property to hook into all of it can go away, and we can freely mix dom elements and "widgets" without risk of leaking memory even after the tab is closed.

Removing all of that mean that some protected methods (that may be used for other things) would stop getting called in certain cases. Many downstream classes rely on that method, so something like the webcomponent lifecycle would need to be plugged in here to interoperate cleanly when added to a non-widget parent. It isn't a simple problem, but either we bring Widget in all of its bloated glory to GWT3 (after porting all of the JSNI...), or we redesign it from the bottom up, along with the ecosystem of classes which rely on it. I'm not yet sure which is better, and haven't heard a lot of people tackle this issue yet.

Unfortunately, things are not that easy for me in the communication with my management.

In my company I have acceptance issues with GWT's long compile times (if you are a background developer, which is the majority of the developers).

I told them: "With GWT 3.0 we will have a 'blazing fast' J2Cl transpiler. "

The next question is: "When will it be available?"

Then I have to tell them: "I don't know."

"Will it be a year, 2 years or who guarantees that it will show up at all?"

"I don't know"

Therefore my management will consider GWT a dead horse and will abandon GWT (which I would regret very much).

But I have no real argument against such a decision, because I have not even a clue about the time frame, when GWT3.0 will show up. And since this is not available, management is not really keen on investing in preparing for GWT 3.0.

I think Daniel Kurka mentioned in last years GWTCon that J2Cl was already piloted within Google.

But in this year's conference no one from Google is showing up at all.

If I compare GWT road map announcements with Angular2 it is pretty different. Angular2 always announced it was coming and it took years until the final release was available. And people waited patiently for it. I am not convinced this will be the case with GWT, too.

I have been in the position you are in now, but i have few things to say:

First : we had the same slow compilation issue you already have, we have a framework that was built with GWT we started with GWT 2.1 if i remember, the framework handles the ui part of all of our application and we distribute it to other teams and they only write backend code, but one of the issues was the labels, for every language we add that was + 1 X Supported browsers permutation, so we started initially with about 12 permutations, and to make things worse, application team has nothing to allow them to build the framework on development machine and they could only do that by building from bamboo, so changing one label or adding one labels needed around 50 minutes to see the effect on the developer screen, it was a pain, but we didnt panic, but actually we looked for a solution, and by externalizing our labels and internationalization stuff we ended up with a constant number of permutations of 3 and less than 20 minutes total build time , not only that we also now dont need to rebuild the whole framework for a label change, with our solution you change the labels then you click a button and you refresh the page, that is less than 3 seconds, and we lived happy for ever after. my point is that you need to identify what makes your build slow and fix it.

Second : regarding GWT 3.0, you should not wait, really, remember that you are writing java, and it is easy to make a good structure for your app, doing so you can isolate the parts that might change later and it will be easy to replace or change them, and actually in this part if we compare GWT with angular i think GWT wins, angular as you said keep announcing things and put a road map, but a road map that breaks things and does not care for backward compatibility, remember what happened with angular 1, while in the other hand GWT gave us hints and suggestion and  the most important TIME, to change and to be ready, it was a clever move not to make sudden major changes, i would really thank the steering committee for this. they hinted that we need to avoid widgets but they kept them while introducing elemental, to avoid generators but kept them while introducing APT, to avoid RPC's but kept them while introducing REST, so in fact i am writing GWT applications now without fear, and i wouldnt be in such calm state if i were to use angular and every day they comes up with dramatic change.

Last : That management and what they think thing, i have been in this position before too but with in different topic, 6 years ago i fought so hard with the management to convince them that clean code matters and is very important, i fought for a year but the answer was always -as long things works we dont care if its clean or not- and year after year they paid the bill. 2 years ago and finally the CTO admitted that he was wrong and clean become a policy, and none clean code will not be committed into our repositories, with TDD and clean code applications of 120K LOC were written for 25k LOC and they performed better and had less than 10% bugs of the original code base. 

the bottom line is : when it comes to technical decisions you are the expert the management guys let them focus on the requirement and policy and take the implementation part but still you also need to hold responsibility. our CTO now have no role in picking up technologies since it is our job, he might suggest one but we research it we do POC's and we give the final decision.

and one more: GWT is not about google any more, the steering committee are doing an amazing job, i have seen GWT advancing during the life time of the steering committee much better than before, they are like the user perspective being considered into GWT, and if you really want to hear more about J2CL, wait for the conference presentations, having no one from google does not mean that J2CL is not going to be discussed in the conference, its a GWTcon not google conference. 

While searching i found this
http://www.gwtproject.org/meetingnotes.html

it might not be detailed enough i agree but it tells that there is something going on, it would nice if few links presented there for github projects and youtube videos and presentations for those meetings.

Well, we don't really talk code in _those_ meetings - there are no github projects or links passed around (except to "hmm, we better ship an update soon because of that bug report"), nor youtube videos, and rarely any real "presentations" (though they do happen).

Thanks for clearing things out +1.

Thanks for your answer!

@Helmut it is a pain to be sure. Here is what I can tell you, and what we have been saying since GWT 2.7:
If you are using JsInterop and otherwise gwt-legal java, your code will work in 2.x and 3.x. We also know that J2CL will compile individual Java files to JS, and that the (already open sourced) Closure compiler will perform the optimizations, as it does for so many other prominent JS-based applications.

GWT 2 continues to advance (see my talk for more on this...) - GWT 2.8 added java8 support, 2.8.2 will be out soon providing the ability to run on JDK9, and GWT 2 development is not stopping just because GWT 3 will exist someday. There is at least one fork out there which even has had Java9 language support. If you are watching the commits to GWT 2, they are ongoing from both inside Google and outside. I'll speak more about all of this at the conference.

Angular is a bit of a different story - by my reckoning, Angular 1 wasn't worth using for any data dense application, and I'm led to understand (though haven't yet tried) that Angular 2/4 still has similar issues. If we released "easy-to-use" but hard to deploy and _support_ software as angular, I would agree we would need extremely detailed advice on how things will look, and what you will need to write. But GWT is stable and mature, and moving to GWT 3 will _not_ require you to change languages, or entirely rewrite your application as you shift - you can do it before (and if my suspicions about how J2CL+Closure works are correct, we may even be able to continue some aspects of migration afterward).

If you are following the guidelines about how to write code for "GWT 3", then your code is already compatible with GWT 3. If you are writing an application that will be _finished_ before GWT 3 even launches, then you can maintain GWT 2 compatibility, as it continues to be improved. If you just stub in GWT 2-only features like GWT's existing generators, then take part in discussions here (and the mailing lists, gitter, etc) to see how those can be migrated to GWT3-compatible tools, like APT.
 

@Colin is it possible to access J2CL interim codebase. I mean is it opensourced already ? Where can we access a build to try it out. I came across the information about your J2CL presentation and its very hard to find more info. 

Great to see the demo from Colin about GWT 3, the J2CL stuff. He showed a running small webapp written in GWT 2.x and the same webapp compiled and running by J2CL...

@Debasish It isn't my code to give away - Google has graciously provided preview access to the J2CL so that the working group (which has no Googlers on it) can investigate what it does so far, and explore the options required to ship it as part of GWT 3.

The chief concern with handing it out is that it isn't usable to build a "GWT"-style project yet, only to compile individual java files to individual JS files. This would inevitably result in "why did anyone release this, when it can't be used yet?!?", and rightly so.

As such, the J2CL working group is looking at what it takes to turn "J2CL" into "GWT3". We have built some sample tools and a few small apps have been compiled, and we presented some of this work at the conference. As we continue, there is work that the community and our various ecosystem maintainers can do: Keep porting JSNI and JSOs to JsInterop, and Generators to Annotation Processors.

Discussion at the conference touched on this: as we do this, do _not_ submit these changes as fixes to GWT 2, as it will break some backward compatibility that we have committed to, but instead, start your own project and share code on your site of choice, and consider deploying to maven central so others can see it too. If you'd like help, please reach out to any of us (https://gitter.im/gwtproject/gwt, https://groups.google.com/forum/#!forum/google-web-toolkit-contributors are good places to start discussions). As people start this work, we'll need a "roster" of who is working on what to avoid too much duplication - but duplication isn't all bad, competing implementations ensure that the community ends up with the best result.

Eventually, we plan to move this work out of com.google.gwt, and into org.gwtproject (signaling that it is "official") or keep it in your own namespace if you'd prefer. We'll have more discussions about this as people continue this work.

(and, for what it is worth, this work has long since begun - the Xml module, the Places, SafeHtmlTemplates, and Editors generators have all been long since been ported, and should already be "gwt 3 compatible".)

I just saw this thread... I have voiced similar concerns in other places.

Just as a language, Java is way better for large development than JavaScript can ever be, for reasons we don't need to discuss here. However, this is not enough to make GWT or any other framework successful in the browser world.

1. Java is not something that other developers make things for to run in the browser, so we rely on interop. Interop isn't needed if you are writing in JavaScript.
2. Java requires compilation. JavaScript does not. This is a step that many new developers aren't accustomed to and see as a nuisance, however short or long it takes.
3. Debugging Java code in browser was never solved fully. Classic dev mode was painfully slow, "Super Dev Mode" is painful to inspect. Yes, you see the code but you can't see the data correctly.

To us and, I suspect, to many others, the GWT was a hit because it answered the following:

1. Java syntax/language offers control and discipline and a way to avoid pitfalls of JavaScript. This only fully works, however, if you only stay in Java world. The more you interface with JavaScript the less of this you have. Furthermore, I don't need GWT for this. I might as well use just J2CL or any other available approach, such as TeaVM (heck, that even runs faster than GWT/J2CL as it can compile to WebAssembly).
   
2. Code sharing so that we do not have to write the same code separately for the client and for the server. No, atrocity called 'node.js' does not count. That is a separate discussion anyway. Yes, GWT 3 can check this box between the client and the server of the same thing but does significantly less than GWT 2 does. Sharing composite widgets? Forget about it. Sharing code that communicates data? Forget about it. There is no framework that can replace GWT RPC to the level needed. If you are creating a large product, you will end up using different code from different people. If those don't agree on RPC-replacement frameworks to use you're in trouble. Any data you may want to communicate has to be exposed even when you don't want to... goodbye private data. Goodbye safe API development.
   
3.  Ability to encapsulate screen content into reusable and composable widgets. Widgets may not be popular in HTML/DOM world but they are, without a doubt, the most reusable and maintainable approach for building UIs that also abstracts the underlying technology. If I wanted to work directly on HTML DOM and use JavaScript frameworks, then I would use what these are made for and will support until their own death... and that is NOT GWT/Java. But GWT 3 gets rid of widgets. The desire is to use what JavaScript guys are using. That's not better, that is a defeat and death. I don't need GWT/Java for that.
   
4. GWT offered a way for the client (browser) and server code to work together seamlessly. This was and still is clumsy, lousy and painfully slow to compile - the GWT RPC. But it made things possible and took a huge chunk of boilerplate development away that nothing in GWT 3 can do (I mean it). We have put a lipstick on the pig that is GWT RPC and it is a pleasure to use (you don't see it anywhere, you don't even need to do GWT.create, you just call the server method you want, it feels almost as if the server code is *in* the client). We only suffer the compilation time due to it but there are ways to solve this. GWT 3 approach? Don't fix/improve, remove. Use other frameworks, reconcile multiple of them when you are forced to, create a lot more boilerplate code.

Like some other companies, we built products around GWT. We exposed our APIs and encouraged others to build extensions, plugins. We bring/link those together at deployment time. Our product is huge and complex due to the nature of what it has to do.Sharing code is important. We allowed our plugin developers to share their code between the browser, UI server and even other components of the system. To optimize performance we often have to communicate objects from multiple plugins bundlled together, through common calls/requests. We implemented server pushes. We implemented the entire UI as widgets to which they can add their own. The API is well documented (JavaDoc) and clean/safe - not everything is public/protected. We intentionally change and improve our widgets and that does not affect anyone in a bad way, whether their widgets contain ours or the other way around. All this was done with GWT widgets and GWT RPC.

The voices of those who do not need features, like Widgets and, especially, RPC seem to be louder than those of people who do. They are calling for diluting of GWT and making it more like anything else. When you do that, however, you lose differentiation and your benefits too.

We are now in a pretty desperate position. The company does not see any spark of hope to steer GWT 3 back where it should be going, so we're not even attempting anything. Hence the anonymous postings from me. Yet we have a huge code base and 3rd party plugins to work with. It really should be simple:

a) Remain compatible with widgets. Many will be grateful. Make them optional and, perhaps a separate project if you wish, but have them. BTW, we also use Sencha GXT. Care to guess what is going on with that?

b) OK, get rid of GWT RPC. It can be done much better than it has been done anyway. But allow a J2CL extension point that can be used to implement all the functionality that RPC was able to do, including communication of unannotated classes with private fields. For example, the plugin could leverage the code representation objects and generate synthetic accessor methods not visible to anyone else. 

That's all that's really needed, if not too late. There's other stuff that can be done such as not requiring the source code, operate on byte code. JBytecode2CL if you wish. Don't require source code. Sure, existing code generators would still have to work via source but that isn't impossible to address. What does this do? It opens doors to many more libraries, makes them easier to use, can use languages other than Java that compile to Java bytecode and allows library or plugin developers to not have to ship their source code. 

Super disappointed,

Learner

That's a long post to disagree with, so I'll just very quickly hit a few points.

Regarding compilation - many in the JS world have given up on _not_ compiling, so we should expect the terrible browser debugging and sourcemap protocols to continue to improve. Dart, TypeScript, and a variety of others try to make JS more usable, but nearly all stick to the same premise of "don't ever let the user forget they are writing JS". Annoyingly renamed variables, poorly mapped sources are the way of life if you want anything saner than raw JS.

TeaVM does a better job in debugging - I've been very impressed there - but they trade it away in compiled size, producing executables (in their own examples) double the size that GWT comes up with. Performance is also impressive, but I'm not convinced that GWT can't adapt those same improvements through the use of typedarrays. Do note that until WebAssembly actually supports garbage collection, it isn't a realistic tool even in TeaVM, unless you write your Java like C, and what's the point there ;).

RPC isn't dead. Shame on me for not posting the slides yet, but I have a proof of concept that I'm very pleased with. I've been hearing about other replacements for years, we'll see if anyone else presents something. Give me a week or three, I hope I can impress you. I'll get the slides of my talk out within a week, to at least present my defense of historical RPC, and my roadmap to keep thinking in Java on both sides.

Widgets aren't dead. My team has plans (and just needs someone interested enough in the idea to help fund us, or the patience to wait for us to finish it in our spare time) to port them to GWT 3. Most of these plans involve re-imagining them as web components, either with no changes, or just simple ones.

GWT 2 isn't dead. Until GWT 3 isn't here, it will continue to get upgrades, and our roadmap continues well after GWT 3 has arrived and gains popularity. Until you are ready to move to GWT 3, "classic" widgets and RPC will continue to work, and as you migrate your code to the upcoming transitional packages, you will increase your GWT 3 compatibility, until finally you can switch compilers, hopefully with no changes required. This is what was discussed at the conference, and aside from those telling us (as they have been for how many releases?) that GWT is dead, we're all still moving forward.

Sencha and GXT, okay, that might be dead, they've made that pretty clear. My team is dedicated to supporting GWT and the ecosystem, including GXT. We have more concentrated expertise in GXT than what in what remains of Sencha, and we actually have the willingness to help support it. Granted, the licensing may cause issues, but as long as we don't publicly release patches, we should be in good shape.

Bytecode to closure would be amazing. The loss of erased generics might be a problem with code sizes (I'm looking at you, TeaVM), but there could be options. (But if another "Sencha" happens, wouldn't you much prefer that all library author ship all source code, so you can at least make fixes as you try to decide what to do next? Closed source means collapsing companies may take all their users with them...)

Re compilation - yes, I agree that "many" have given up on it and I am aware of those listed. But the huge majority did not. The whole reason JavaScript and pure JavaScript frameworks are so popular in its raw form is that it requires no development tools at all to get started. Every Joe and Jane can get started and accomplish something. This is also the proof that "most popular" has nothing to do with the "best" by any stretch of imagination.

TeaVM does come up with larger code but I wouldn't say double. Furthermore, this is about the optimization stage. TeaVM brings its own (albeit simple) garbage collector to WebAssembly making it possible to start... and shift to the WebAssembly one when it appears. Finally, if the optimizer planned for GWT 3 is really just a JavaScript optimizer, then it can be applied to TeaVM as well...

Re RPC I am *VERY* interested. I was digging through this myself but have come up with two approaches. One requires interfacing with the compiler. This is a better/faster approach. The other requires massive source pre-processing to inject synthetic methods into the input for the GWT compiler. This is needed even for standard library classes as they too can (and should) have private serializable fields.

GWT 2 isn't dead. We are at 2.8.0 right now, about to take on 2.8.2 and check it out. The problem is that GWT 3 is advertised in a way that spells a dead end for GWT 2 code.

Sencha GXT is a big problem for us. Licensing is a big issue. It is a zombie now.  Neither alive and OK to be promoted further nor dead so that we can claim the corpse and do stuff with it. 

Bytecode to closure is possible. If you have the source code you can use it, but this isn't absolutely required. With respect to "another Sencha" happening we're in between a rock and a hard place now. (1) We depend on Sencha. (2) In order to support 3rd party deployment-time plugins we have to ship with our source code and we also require those 3rd party devs to do the same. We obfuscate this code to a point but we can't really do much to it. I know this is almost pointless as one can decompile Java, APIs are hard to obfuscate and, if we were to write in JavaScript it would have been all source code anyway, but it is a sensitive topic for companies that follow the traditional non-open source model.

@Colin, I noticed your comments about RPC in another thread re this, not really related to what the thread is about either ("GWT csrf protection EXPERIMENTAL methods"). Can you share more details about capabilities, approach, timeline and licensing? I'd really like to know my alternatives as soon as possible and any impact. I am not concerned about GWT.create at all as we completely wrap+abstract that, but I am concerned about other things. Specifically:

1. Needs to be able to serialize private fields with no annotations, getters, setters or constructors that set them. No source or binary code changes must be required.

2. Effect on compilation time, participation in (Super) Dev Mode, etc.

3. Ability to run this at product deployment/installation time (post-development, we run GWT compiler to "link" the base product with the plugins made by other parties). Also what does it take to have our (independent) plugin developers use it?

4. Open source? If not, what assurances we'd get this does not end up like Sencha GXT (another headache I have)?

We're really taking a turn here in the conversation away from GWT 3.0 @LearnerEvermore, shoot me an email (colin@vertispan.com) if you'd like to discuss, or we can have this conversation somewhere else.

Short version: Annotation Processor based, Apache v2 license (since it is based off of RPC, plus I'm a good guy like that), currently only can do getters and setters (but private fields are on the roadmap), no worse than existing RPC for compile times, can run on anything that can run Java. Can't tell what you mean by "link", since that can mean so many things, but I'm sure we can work something out.

Check out the slides from my RPC talk (and soon, the video), shoot me an email. Do note that as our company's expertise is in GWT support and services, this is being worked on in my free time, or when a client specifically directs us to focus on it. If you want it sooner (I think I could have it ready in as little as two weeks or less), that can be arranged.