https://kotlinlang.org
Join Slack
After <@UFT11FKSP> posted about the updated roadmap (about JS not having high priority compared to o...
# javascript
l
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?
r
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.
v
Where is that announcement? šŸ˜±
I can't develop my GitHub action anymore in Kotlin then.
r
There is no announcement about K/JS not being developed further.
I just noticed K/JS doesn't seem to be a priority for JB team.
l
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.
v
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
t
@loke FYI - We have all stable browser types in Kotlin Wrappers. WeakRef too.
šŸ‘ 1
l
@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.
t
Copy code
// from string
val a: BigInt = "33453545".n
// from number
val b: BigInt = 33453545.n
If you need some additional functionality - please file an issue
l
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.
@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:.
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?
t
We have no 
wasmJs
target support right now
l
Ah yes. I realised that. Thanks.
m
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.
šŸ”„ 1
šŸ™‚ 1
l
@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.
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.
m
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
l
Wait, ES module? I'm not familiar with this.
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.
m
l
Thanks. I'll try it.
m
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
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.
l
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.
I need to add some platform specific 
expect
stuff to deal with the inconsistent behaviour of 
%
though.
s
We have no 
wasmJs
target support right now
@turansky are there any plans to add it for kotlin-wrappers in near future?
t
Which problem will it solve?
r
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 šŸ˜‰
t
Kilua? We need link :)
r
l
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
t
Yes, similar functionality already exist
js.core
package is what you need
ā€¢ 
jso
ā€¢ 
Record
ā€¢ 
recordOf
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. šŸ˜‰
l
@turansky this is wasm though. There is no js.core there.
t
Temp copy-paste is fine :)
It will be more transparent which parts can be shared in future
9 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by