https://kotlinlang.org logo
Join Slack
Powered by
Looking around I didn't see a clear answer for the...
# webassembly
i
Looking around I didn't see a clear answer for the GC roadmap. Will Kotlin WASM only work on latest browsers once the experimental browser GC feature goes production or will Kotlin WASM eventually switch to the Kotlin Native GC implementation enabling support of older browsers?
c
There are two Kotlin WASM implementations: the one discussed here is an entirely new platform that is not a part of Kotlin/Native, and thus has nothing to do with the Kotlin/Native GC. I don't know what the status of the Kotlin/Native-based WASM implementation is, but I doubt they'll want to maintain both?
i
Right and thus lies my confusion.
If this is clearly answered somewhere I'm happy to go do the reading but I couldn't find it.
a
K/N wasm32 target is deprecated
c
Ahah, so that answers it
I doubt the new WASM will ever work on old browsers
i
Alright so what about the GC implementation, is it the expectation that Kotlin Wasm will only ever work on future browsers that have the browser gc feature built in?
c
Can't say for sure, but that's what I understood It's not just browsers though, it's also the serverless stuff
i
Good point. In my use case I'm only considering browsers on "Smart"TVs which are based on Chromium versions from roughly 1756 AD
c
At some point, if no one has already done so, someone will create a WASM interpreter in JS to backport their projects
I wouldn't be surprised it already exists 😅
i
Not sure if that would solve the GC issue but I would be interested in it. Our struggle currently is the JS payload size continues to be massive and I know that is being worked on.
c
Well that would make it even worse
i
Very likely
c
How bad is the JS size for you? It's not a big deal for me
i
kotlin + compose html + a few libraries like Apollo, we have an ~1.7MB JS file output
for most modern systems that really isn't an issue though, the issue is the average TV uses potatoes for CPUs. A 2016 TV can take upwards of 10 seconds to load that JS
e
but once binaryen finishes gc support, I expect its wasm2js would work
that won't help with the JS blob sizes, though
f
So I'm guessing there's not much hope for, say, a Wasm-GC polyfill on top of older Wasm implementations in older browsers?
e
the issue I linked above is requesting a translation from WASM-GC to WASM (non-GC)
f
ah, I misread your comment, I thought it would be running all Wasm code as JS
e
it's technically possible - you "just" have to implement linear memory and STW GC - but tricky (GC uses anyref proposal which means you'll have to deal with references between WASM and JS/DOM objects, including cycles)
I somewhat doubt there's enough interest for all that work to get done - how many targets have WASM that aren't getting updated? - whereas there's a wider base for wasm2js, IMO
f
how many targets have WASM that aren't getting updated?
Tizen / WebOS smart TVs, as mentioned earlier in the thread
other than that, not sure of any others
i
so basically every house in 1st world countries has at least one TV running at minimum a 2 year old version of chrome, from what I can tell most are running 4 to 6 year old versions. It's a very sad state of things. I understand though at the same time that isn't really the target platform of kotlin js/wasm but it is unfortunate as even with pure node approaches most libraries supporting browsers that old have also just kind of stopped trying to support stuff that old. Samsung and LG have created an Android esk monster of perpetually out of date devices.
e
relative to the number of devices that are never getting WASM, I think the ones with WASM minus GC are going to be in the strong minority
but we'll see. I'm not going to stop anybody from building a WASM-GC to WASM transpiler :p
f
well, at least it's possible (in theory) 😛
s
e
yes, that's what I linked to earlier
s
Ah yeah, I missed it in the long thread.
23 Views
Open in Slack
PreviousNext
Powered by