Your comments

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.

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...)

@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".)

Sad to hear you won't be at the conf - and keep the different viewpoints flowing. If you know someone who in JSweet who is willing to tell me where I'm wrong, etc, I'd love to hear it. Likewise, we should see if the other jvm->browser platforms can join the next conf.

(Don't just stand on the sidelines Diogo, help us decide what GWT goes for! "GWT" is its community, and needs your help and advice!)

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)

Thanks for the link, its been a while since I looked at it! I don't think I'll have time before the conference to examine it closely, so perhaps someone who has done so can point out where I am wrong below:


Personally, I don't want to look at GWT.next etc as a "JSweet killer" - I think that a reasonable person could say that even the existence of GWT3 shouldn't convince people to stop using GWT2. I also happen to like TeaVM for some use cases, and plan on continuing to see how they do things, and what GWT (version 2 or 3) can borrow. Competition improves us all in this space.


At a glance, it seems confusing that JSweet walks Java through TS on its way to JS - if memory serves, the TS compiler is _not_ capable of anything close to the optimizations that Closure (used with J2CL) can do, and something like https://github.com/angular/tsickle must be used to actually optimize TS code.


It is handy that JSweet, like J2CL, just borrows GWT2's Java emulation, and tends to suggest that a lot of GWT code will simply be JSweet compatible. I am bothered though by something like hashCode behaving badly, which will cut off your access to a great many classes that GWT properly supports. Lack of support for doubles is also very surprising, given that Java's double and JS's Number are very nearly the same type:


> Package java.lang: by default, most core Java functions are supported, however, some variations/limitations may appear on numbers, especially when dealing with floating point precisions (Java doubles and floats cannot be mapped to JavaScript numbers).


The annotations within jsweet.lang (http://public.jsweet.org/apidocs/org/jsweet/jsweet-core/5-20170726/jsweet/lang/package-summary.html) surprise me slightly, and seem to suggest that this tool is first and foremost a way to write TS in Java, not a way to transpile Java to TS. The distinction is that GWT doesn't make you think about Java, but from these annotations and other issues above, you are not writing Java in JSweet, you are writing TS with Java syntax.


I do like that of the two demos, one is specifically for running your app on the server, though I'm still struggling to think of a use case where one might write Java, compile to JS/TS, and run it where we already have a JVM. I'm sure such cases exist though.


Much like TeaVM, the JSweet community still seems very small (perhaps your question could be better phrased "How will you sell JSweet to GWT3 users"), but I am excited to see where it goes. Since it handles Java source, as GWT generators are ported to APT, all of these transpilers will work with the output, and we'll be able to watch as each grows. I think for this to happen, there must exist tools to translate JsInterop code (which so far seems much more descriptive than the matching jsweet syntax), but perhaps that is something we can work on. If JSweet can support existing Java emulation in GWT (including double and hashCode), can translate JsInterop, they might even be able to entirely automate porting GWT  projects to their platform - though at that point, teams would take a much closer look at the speed of transpilation for "dev mode", and the final sizes and performance of generated output.

If you've checked the agenda recently, the keynote has been updated:


Keynote: GWT3 and J2CL

By The J2CL Working Group

We'll tell you more at the conference, but the answer to the original question is yes, there will be news!

The venue doesn't have the bandwidth to stream the talks unfortunately. I will share my slides after the conf and a short vacation, and will also be sure to upload my sample work to github. In past years, the videos were available some months later, I'd expect it by January? No promises though, it is a lot of work.

@Diogo, I should have let you write the intro to my talk. If you'll be at the conference, you'll get to hear all about how much I think you are on the right track, and if not, I'll publish some of my preliminary work at some point after I speak, so others can explore it.