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.
Looks like most people have misunderstanding: they think that WebAssembly is the only way to run their favourite language in the browser. However, there's another way that exists for decades: simply use compiler of their favourite language that produces JavaScript! As for Java, GWT exists almost 20 years. Another example I know of is Brython which runs Python on top of JavaScript. However, looks like Java developers don't like to write websites, even while GWT is there.
And according to my experience, WebAssembly is not a game changer: it does not provide extra performance here, neither does it allow to get smaller binaries. I'm a developer of another Java-to-JavaScript compiler, TeaVM. I recently compared performance of JavaScript and WebAssembly targets, and in one particular case WebAssembly is slower: https://teavm.hashnode.dev/comparing-teavm-with-kotlinjs-pef.... There's another example where WebAssembly is only slighly better: https://teavm.org/gallery/jbox2d/index.html. In both cases WebAssembly binary is huge compared to JavaScript. On one hand this can be because of I don't target Wasm GC, so binaries get bloated because of need to maintain shadow stack. On another hand, there's Google Closure Compiler, which produces Wasm GC binaries, and from what I heard of it, WebAssembly binaries still don't win in their size.
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.
FYI I, an author of TeaVM, used to work in Kotlin/JS team in JetBrains. Later I came to conclusion that Kotlin is still very Java-ish language, which inherits a lot of design of JVM platform and will always be 2nd class citizen in JS world. In that sense Kotlin/JS is not that different from TeaVM. There were same challenges on designing interop between Kotlin and JS, as with TeaVM and JS. True, in some rare cases having source code makes things easier. True, Kotlin/JS interop is little bit better that TeaVM's. This was not caused by impossibility to make better interop in TeaVM, this was deliberate choice. There's always trade-off between performance and interop quality. My decision was folloing: since it's impossible to make perfect interop and be 1st class citizen, I better make TeaVM perform good its primary job: execute Java.
These thoughts made me quit my job at Kotlin team and join Delightex to work on their product that uses TeaVM heavily: https://edu.cospaces.io/
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:
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.
Currently, if you run TeaVM with 'debug' (-g) option, and WASM target, you'll get both '.wasm', '.wast' and '.c' files. C file is compilable with GCC and you should write several trivial functions manually to get working binary, either '.so' or '.exe'.
One of the most important features in TeaVM is its inteprocedural dead code elimination algorithm, which allows to produce very small code for simple Java programs. For example, Hello World produces about 40 kb JavaScript, TodoMVC (http://teavm.org/live-examples/todomvc/#/) is only 125 kb.