Hacker News Reader

Comment by abeppu | Hacker News Reader

Anyone who has actually tried this have any comments?

I think it's interesting that they seem to position themselves as an alternative to programmers of jvm languages needing to switch to javascript for browser-side work, but they don't make a clear comparison to eg scala.js or kotlin js, where js code is generated, but not from class files.

I've tried playing with those, and one source of challenges is working with js libraries, which need some wrappers expressing method signatures, which is sometimes a challenge. TeaVM has a bunch of annotations for js interior, as well as the ability to deal with js code as just strings. But I can't see that it clearly solves the issues I find most annoying about scala.js or kotlin js. Is this only a great fit if you're in a polyglot jvm team that also wants to run that code in the browser?

View on HN

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/

> Anyone who has actually tried this have any comments? I manage a Java/Kotlin WORA toolkit called Codename One that deploys to all the major platforms (iOS, Android, Windows, Mac, Web, etc..). We use TeaVM for our web platform, and it has been fantastic. It was the first solution to provide support for threads in JS. (i.e. Your java programs can use synchronization, and they will work properly when deployed to the web).

The performance is very good (we tried other options to get a web port working before we found TeaVM, and none could compare).

The developer is responsive to bugs - but it has been rock solid for us. At this point the JS port is one of our most stable platforms.

The development environment is also nice to work with. I work with all of the native SDKs that we deploy to, and TeaVM is my favourite. In particular, the JS<->Java interop is smooth and easy with minimal boiler plate. On most platforms, using a native API is at least a little painful - with some boiler plate necessary. On TeaVM it has annotations to be able to "drop into" javascript without a lot of fuss.

TeaVM is nice if you want to bring existing Java code depending on the Java standard library to a browser. Kotlin-js does not do that. You only have the Kotlin standard library if you target kotlin-js (well plus all the multiplatform stuff that is getting released lately). Multiplatform is the reason why this is getting interesting. There are a lot of good quality libraries that just work on kotlin-js now.

I've been using kotlin-js lately for browser development (with the Fritz2 framework). It's fine and improving rapidly. Just a year ago, this would have been a bit of a rough experience doing anything with it. But I've been using it since two months and have not really encountered any major issues. The Kotlin 1.4 release really improved things. And we indeed have a lot of Kotlin code for Android and our server so that made that an easy choice for us.

It's early days for WASM and languages like Kotlin and Java but I'm guessing that a lot of stuff is going to happen there in the next years. In the end you need more than a compilation target: you also need platform integration, development tools, and libraries. Kotlin-js is getting pretty nice for each of those and with all the multiplatform stuff coming out, you don't really need or miss a lot of the npm stuff. But if you do, it's fairly easy to deal with that as well (e.g. we integrated leaflet just a few weeks ago).

WASM support in Kotlin is still pretty immature. They recently kicked off an effort to improve support for that in the multiplatform gradle plugin. But there's still a lot of work to be done there. But, long term, I'd expect to compile to that rather than to Javascript.

I have had great experience bringing my desktop apps to the browser with TeaVM. The performance is great, the generated JS is small (usually about 1mb gzip for my midsized apps).

I do have the benefit of a UI abstraction - my UI kit runs on Swing/JavaFX on the desktop, and on HTML/DOM (canvas based) in the browser.

https://reportmill.com/snaptea

I use TeaVM exclusively now to build web apps. It is rock solid and performant in every respect including runtime speed and download size. It is great alone or in conjunction with its SPA toolkit Flavour (https://blogs.oracle.com/javamagazine/java-in-the-browser-wi...)

Some examples:

* MerchMaker (make Roblox merch): https://frequal.com/merchmaker/

* Funniest Stories Ever (fill in the blank stories): https://fse.frequal.com

* CoronaWait (store wait times and in-stock reports): https://coronawait.frequal.com/

To piggyback on your request from someone who's tried it, I'm also curious about how this deals with the fact that Java is garbage collected but wasm (in itself) is not. Did they actually port a GC to wasm, or do they work around this in another way?

The WASM port is experimental. The Javascript target produces better performance. For JVM languages it will always be the case that the Javascript target performance better than the WASM target, mostly because of GC. For the WASM port the developer wrote his own GC.

Targeting WASM is just like targeting a CPU, most of them also don't have hardware support for GC algorithms.

Most anti-GC FUD regarding WASM and GC kind of stems from people not getting how GCs are implemented.

They do have a GC on their roadmap, I assume to better support running languages that need a GC without having to pull their whole runtime into WASM. Isn't it fair to say WASM is somewhere in-between a CPU and a VM?

There are CPUs with hardware GC support, then tagged memory is coming back into fashion as means to tame C derived languages, and most Assembly languages are actually processed by tiny runtimes (microcode), as the pure hardware based gates is long gone in most high performance CPUs.

So between a CPU and VM depends pretty much on how one looks at it.

I've used it because my uni still forces us to use Java (https://github.com/alphahorizonio/jnebulark) but the experience hasn't been that great for the actual framework (bindings are way to hard to do; I haven't found a way to do Promises yet, see https://github.com/alphahorizonio/jnebulark/blob/main/src/ma...). In general, docs are lacking quite a bit as well (you have to use the development version for most things now, which isn't in sync with the docs). We just took the sane route, wrote the backend in TypeScript (and ported to Java for Uni), and used React for the frontend. The WebAssembly support of TeaVM is fun to use for small modules though, we integrated it into a WIP project: https://docs.webnetes.dev/getting-started/develop/java.html

"I haven't found a way to do promises yet". TeaVM provides Java wrappers for most JS APIs, including promises (https://github.com/konsoletyper/teavm/blob/master/core/src/m...). If you require an API that doesn't have a wrapper yet, it is dead simple to create your own wrapper. Or just use the @JSBody annotation to write your own ad-hoc Javascript.

Thanks for the link! This looks like a significant improvement over my current solution of trying to pass callbacks ... which aren’t transferable types sadly ;)

Reply on news.ycombinator.com