Is GWT3/J2CL === JSweet ?

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.

As an hardcore GWT user, the "sell" question was indeed something to stir up some discussion ;-)
Should organize a meetup with some JSweet devs...Having friends that think differently is good for your mind.

Can't wait to discover what GWT has under the hood.
Have a nice GWTcon!

T@nguy

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.

These discussions about JSweet and GWT could be interesting for you: 

• http://www.jsweet.org/comparing-the-gwt-transpiler-and-jsweet
• https://news.ycombinator.com/item?id=10741376