konsoletyper

TeaVM supports Kotlin as well. The difference with Kotlin/Wasm is that with Kotlin/Wasm you are limited only to Kotlin and can't use any code written in Java.

TeaVM author here. Personally I use it to bring a large (500KLOC) project that's written in Java and Kotlin to the browser (also we are using Graal VM Native Image to compile the same app to iOS, and Android supports). It's virtually impossible to maintain another 500KLOC code base on TS and on Swift and make sure that they behave and look 100% same. So the target audience is any team that wants to write in Java and/or Kotlin applications that works in JVM as well as in the browser.

As an author TeaVM I can tell you about advantages of TeaVM compared to GWT.

1. TeaVM can compile not only Java, but Scala and Kotlin. Actually, any JVM language, which is not using much reflection, invokedynamics and dynamic class loading in its runtime. It's possible because TeaVM uses JVM bytecode, not Java source code, as an input. 2. TeaVM can emulate threads. TeaVM won't spawn real threads, it will turn Java methods into coroutines and schedule their execution upon one physical thread. This won't speed-up programs by using multiple cores, but for example you can use Java synchronous IO APIs in a background thread. 3. TeaVM has more advanced reflection support. You can list class' methods and fields, call methods and get/set field via reflection (but as in any other AOT compiler you should list reflectable methods and fields). 4. Maven and Gradle plugins both available out-of-the-box, you don't need any 3rd party tool. 5. I usually get positive feedback from my users about compilation time compared to GWT. 6. TeaVM already has some limited support of compilation to WebAssembly.

As for latest Java version, TeaVM currently supports Java 21.

There are separate compiler backends for Wasm and JS. JS BE does not support WeakReferences (or rather supports them as a class, but does not support weak reference semantics). For Wasm BE I written my own GC, which supports weak references.

TeaVM Flavour does not compile Jackson. Instead it comes with its own JSON serializer that supports subset of Jackson annotation. As Kotlin serialization, it relies on code generation, no reflection used at all.

I'm an author of TeaVM. Currently, I don't do TeaVM as a replacement for React/Angular/Vue. There's a use case which is not covered by React at all: cross-platform CPU-bound applications. Java runs in Androd and Windows natively and on iOS with help of tools like MOE or RoboVM. TeaVM helps to run Java application in the browser (in Chrome OS in particular). Yes, JavaScript runs on all platforms as well, but it's performance (altough great nowdays) is still worse than Java. Having really large applications (0.5MLOC in our case) makes it nearly impossible to have separate code bases for every platform. Also, Java strict sematics makes it possible to perform various optimizations to generated JavaScript impossible with pure JavaScript.

No, WASM is slow. As a developer of TeaVM I can claim this. First of all, JS engines been developed for many years, while WASM is a new technology and browser engines don't optimize it well. Another reason is WASM was not designed to run languages like Java, at least in version 1.0. Here are the reasons:

* To make GC work properly you have to maintain GC roots. GC roots are static fields + variables in stack. There's no way in WASM to walk the stack! You have to maintain your own shadow stack, losing performance. In case of generating native code (e.g. x86/64) you can access native stack freely and finding GC roots produces no overhead (which is already done by JS engines).

* To make exceptions work properly, you need to walk the stack, and not only read it, but also write to it (in case of x86, update RSP direcly). This is not supported by WASM. But JS engines already do it natively, with no overhead for exceptions, until you throw then. With WASM you have to check after each call whether the exception was thrown or not, and that affects performance.

* In native environment you can do memory protection magic for different runtime things, e.g. to detect null pointer access, and that's not possible with WASM.

* In WASM you can't mutate code, so it makes impossible to implement lazy initialization logic without some overhead. JavaScript engines can detect that certain function got changed and de-optimize calling function, then optimize it again.

So, according to my experience and my benchmarks, compiling Java to JavaScript is a better option, both from performance and code size standpoint. WASM team is working on GC and exception handling, but they do it slowly and current design is far from perfect. I failed to convince them to just give access to stack, perhaps in some limited way (for security reasons).

And yes, the lack of access to stack even affects C code. For example:

int i = 23; foo(&i);

Why do you think so?

GC is only about 300 lines of code. There's no JNI in TeaVM (and never will be), instead of JNI there's JSO to interact with JavaScript, and still no interop layer for WebAssembly (that's why I claim WASM support to be experimental). JSO is rather lightweight, and I hope I'll be able to implement a lightweigh interop for WASM.

As for Java libraries, TeaVM is able to throw away unused parts of it, producing relatively small binaries.