If JSweet claims about GWT are inaccurate they will be fixed. But you have to understand that JSweet is a syntax mapper to TypeScript (explained here: http://ww

If JSweet claims about GWT are inaccurate they will be fixed. But you have to understand that JSweet is a syntax mapper to TypeScript (explained here: http://www.jsweet.org/papers-and-publications/ http://www.jsweet.org/papers-and-publications/). So they are really different techniques. With JSweet, what you see is what you get. There is a direct correspondence between the written Java code and the output TS/JS, and that for ALL the program (not only fractions of it). So we are probably not always referring to the same features and certainly not the same ways of doing things, which probably explains some misunderstanding in JSweet assertions about GWT. JSweet is not meant to obey JLS because JSweet is "just" Java syntax. It is not Java anymore. However, some specific transformations (very few) have been implemented so that Java programmers are not confused by JavaScript runtime behavior (as explained here for instance: http://www.jsweet.org/language-specifications/#Variable_scoping_in_lambda_expressions http://www.jsweet.org/language-specifications/#Variable_scop...). JSweet is not meant to be at all compatible with Java legacy APIs. With JSweet, you will not even be able to access the Java Object API nor the Java String API. Instead you directly access the Object and String JS APIs. So who cares about JLS semantics then? What JSweet is trying to compile is JavaScript applications, not Java, and the examples show that it works for not-that-trival code. In short, JSweet is for writing real JavaScript applications in a Java compile-time environment (not runtime). Nothing more, nothing less. I understand that GWT new generation it aiming somewhat at integrating JS apis too... But AFAIK, JSweet is the first project to give access to hundreds of JavaScript libraries in Java thanks to the TypeScript to Java API translator.