After <@UFT11FKSP> posted about the updated roadma...

# javascript

[loke]

After @Robert Jaros posted about the updated roadmap (about JS not having high priority compared to other features) I took another look at the wasm target. My project being somewhat performance sensitive (it's a language runtime) having wasm support would actually be much better than JS. However, I don't understand how to properly integrate with the environment using wasm. I use js() quite a lot in order to access the JS runtime features, such as Javascript bignums, or getting access to Javascript weak references using js("new WeakRef(...)). Am I to assume that none of these things are available in wasm, and I have to find workarounds for every use of js() that I have in the code?

[Robert Jaros]

You can use js() in wasmJs target:
https://kotlinlang.org/docs/wasm-js-interop.html#kotlin-functions-with-javascript-code
It's just a bit more limited.

[Vampire]

Where is that announcement? 😱

[Vampire]

I can't develop my GitHub action anymore in Kotlin then.

[Robert Jaros]

There is no announcement about K/JS not being developed further.

[Robert Jaros]

I just noticed K/JS doesn't seem to be a priority for JB team.

[loke]

Right. I should have been more clear. It doesn't seem it'll go away, but that further improvements (especially performance, I think) will come from the wasm target.

[Vampire]

Oh, ok, don't scare me like that.
Focus probably still is on finishing K2 in Kotlin 2 and then JS hopefully gets some more love again too

[turansky]

@loke FYI - We have all stable browser types in Kotlin Wrappers. WeakRef too.

[loke]

@turansky Thanks. But there is another one I need which seems not to be available, which is bigint. I just wrote wrappers around all bigint maths operations.

[turansky]

Already on board

[turansky]

// from string
val a: BigInt = "33453545".n
// from number
val b: BigInt = 33453545.n

[turansky]

If you need some additional functionality - please file an issue

[loke]

Thanks this looks pretty neat. If only I can figure out how to work around the issues caused by KT-63014 I might be in business.

[loke]

@turansky I'm trying to use the kotlin wrappers, but I have trouble getting it to work following the instructions. Of course, it could be because I suck at gradle, but I keep getting error messages telling me that :array:wasmJsMain: Could not find org.jetbrains.kotlin-wrappers:js:.

[loke]

It doesn't matter which subproject for kotlin-wrappers I use, they all give that. Unless it's me that is very stupid, it would be helpful if the documentation addressed more specifically how it should be done?

[turansky]

We have no wasmJs target support right now

[loke]

Ah yes. I realised that. Thanks.

[Mike Dawson]

I've been following the Wasm target and it definitely seems to have high potential. The two pain points I see are:

Bundle size: trying the online demos - skia wasm is 3.4MB (after gzip compression). Then the actual demo app seems to be around 1MB. For desktop users on broadband, probably not a problem. For mobile web users, especially in low income settings, could be a problem.

Compose multiplatform would be the expected UI framework, but it's still quite a niche thing. On Android you can use AndroidView components, on JVM you can use Swing/JFX components, not sure what that would be on Compose Multiplatform/WASM.

I'm generally pretty happy with the Kotlin/JS using the React wrapper, even when no wrapper is already there, it's straightforward enough to create one, so I can still take advantage of the React community and existing components.

I haven't done any scientific performance measurements, but have used the resulting React app on some pretty old limited capacity phones for testing, and I don't find any noticeable difference between the performance of the Kotlin/JS version and anything else.

[loke]

@Mike Dawson My application is an language interpreter, so performance is nice. The JVM version is 10 times faster than the JS version, so if I can get a 2x performance increase out of wasm, that gets it below one order of magnitude slower than JVM, which would be nice.

[loke]

Now, a lot of the slowness on the JS side is because of heavy use of 64-bit values. In JS these are emulated using a pair of two doubles if I'm not mistaken. I think wasm allows for them to be a single value? If so, that would be huge for me.

[Mike Dawson]

I think support for BigInt was added, if you switched to the es module output I think it would apply. That's been on my todo list but haven't tested it directly. I saw the BigInt support in the release notes

[loke]

Wait, ES module? I'm not familiar with this.

[loke]

That said, bigint is horribly slow in JS in general. My interpreter uses it to handle overflows in the underlying language, and when I benchmark it, I'm getting awful numbers compared to the other platforms. I haven't investigated it too much, but while the regular tests show about 10x slower on JS, for the bigint tests that gets closer to 100x if I remember clearly.

[Mike Dawson]

This was the es6 announcement I think https://kotlinlang.org/docs/whatsnew19.html#experimental-support-for-es6-classes-and-modules

[loke]

Thanks. I'll try it.

[Mike Dawson]

I might have been wrong about the LongType - but if you search this slack for BigInt Victor posted something about it as an extension function

[Mike Dawson]

I'm not familiar with the language processing use case, sounds CPU intensive. Maybe you could offload that using a web worker module?

eg. you can use Kotlin/JS React wrappers etc. for UI, then pass what needs processed over to a web worker that is compiled using WASM.

In our case we run a client side database and lots of queries. Those are handled by a webworker in the background, so performance and responsiveness for the user is pretty good.

[Mike Dawson]

https://github.com/JetBrains/kotlin-wrappers/blob/34f1fef20e25c0f19c89c6117e3835ecb4b4a65e/kotlin-js/src/jsMain/kotlin/js/core/BigInt.kt#L13

[loke]

Yeah, that's what I do. All the computation happens in a webworker. The webworker is currently compiled to JS, but I just managed to get the interpreter engine compiled to wasm, so now there isn't much left for me to be able to replace it with the wasm version.

[loke]

I need to add some platform specific expect stuff to deal with the inconsistent behaviour of % though.

[loke]

Mine looks like this by the way: https://codeberg.org/loke/array/src/branch/master/mpbignum/src/jsMain/kotlin/com/dhsdevelopments/mpbignum/bigint-js.kt

[suresh]

We have no wasmJs target support right now

@turansky are there any plans to add it for kotlin-wrappers in near future?

[turansky]

Which problem will it solve?

[Robert Jaros]

In theory it could ease development of apps targeting both js and wasmJs. In practice it would require moving all external declarations to common source set, which requires really a lot of work and compromises. I've done this for basic DOM wrappers in my Kilua project and it was a painful experience 😉

[turansky]

Kilua? We need link :)

[Robert Jaros]

https://github.com/rjaros/kilua/tree/main/modules/kilua-dom

[loke]

I ended up doing this thing in order to be able to create jsobjects. Surely something like this must have been created already? Did I miss something? https://codeberg.org/loke/array/src/branch/master/clientweb2/src/webworkerWasmjsMain/kotlin/array/clientweb2/webworkerwasmjs/compute-queue-worker.kt#L224

[turansky]

Yes, similar functionality already exist

[turansky]

js.core package is what you need

[turansky]

• jso
• Record
• recordOf

[turansky]

js() dark magic is for very rare cases required.
Most of such cases we hide in Kotlin Wrappers.
I have zero js() calls in projects, which use Kotlin Wrappers. 😉

[loke]

@turansky this is wasm though. There is no js.core there.

[turansky]

Temp copy-paste is fine :)

[turansky]

It will be more transparent which parts can be shared in future