Hi everybody.
recently I came across the current plan, to support WebAssembly as a compile target directly from IR instead of Kotlin/Native. I think this is great!
Also, I saw that Kotlin will integrate with the WebAssembly GC proposal and thus not implement a custom runtime / memory manager. I also think this is great!
(Source: https://youtrack.jetbrains.com/issue/KT-42292)
I however would like to understand what the implications of this strategy are regarding the library ecosystem.
Most of the libraries that most kotlin users are utilizing every day are jvm libraries. Take for example pdfbox, a jvm library to generate and manipulate pdf files.
Going forward with KT-42292, how will I be able to utilize existing jvm libraries? Probably, I will not. If so, how would that work?
Example: I would like to write a kotlin app that compiles to WebAssembly which allows editing pdf files in the browser. For actual pdf generation and manipulation, I would like to utilize the existing pdfbox library.
I tried exactly that with C# / blazor and the iText library. It just worked. Start a new blazor app, add the iText nuget package and generate pdfs in the browser. I was stunned.
Of course, I can just use C# / blazor just fine, it is all there at my disposal. However, I have multiyear experience with Kotlin (and the jvm ecosystem) and was wondering where JetBrains and Kotlin is headed in this regard.
So I am wondering:
- Why did Jetbrains decide to implement WebAssembly support by compiling “only” Kotlin code to WebAssembly, effectively preventing the use of the jvm library ecosystem?
- Why not put effort and resources in something like TeaVM or CheerpJ which would allow utilize existing jvm libraries?
- Is the long term vision to become independent of the jvm ecosystem and have all the libraries written in Kotlin directly?
- Will there ever be something like WebAssembly libraries which Kotlin could interopt with?