<https://blog.scottlogic.com/2021/06/21/state-of-w...
# webassembly
d
a
Nice review, thank you. You really need to step on it to fill the niche.
K 1
2
👍 2
j
Kotlin should be able to make an impact there once the tooling for that gets usable. Currently kotlin-js is getting quite popular and a lot of that ecosystem could transition to wasm. Especially libraries. IMHO this could also lead to a little renaissance in browser based UIs. The current DOM based stuff is just not great and there are a growing number of applications that basically sidestep that. We're using Figma and Miro for example. Most such applications are developed using Rust or C++ currently. WASM + compose for web and some nice webgl backend for that could be quite nice to deal with in comparison. And there are a lot of Android developers and plenty of good design patterns to potentially target such a combination that currently have no interest in dealing with browsers, React, DOM trees, etc. A key challenge is in the next years is coming up with a stack that works on IOS, Android, and Desktop (windows, linux, mac) that allows people to use Kotlin all over the place. Make it a full stack language.
👍 6
🙏 3
n
After reading the article it is interesting to see that Java, Swift, Python, and C# (via Blazor) aren't desirable languages to use with WASM. Partly this is due to all of the languages requiring use of a GC, and another being that they don't have a large presence in frontend web development. Kotlin would be seen as a Black Horse that could be one of the major options in the future. However the GC requirement is problematic (performance concerns), and the language needs to make further moves in frontend web development that are completely independent from JS.
The fact that WASM is mainly used for web development (high level development) opens up the door for Kotlin to make its mark. Looks as though WASM usage in other high level software development areas is set to increase in the future (especially Serverless). What will likely occur in the future is that the use of high level programming languages (eg Kotlin) using WASM increase at the expense of system level languages (Rust, C++ etc). Serverside development used to be dominated by system level languages at the beginning but are now dominated by high level languages. WASM could share a similar story.
a
I do not think that GC restriction is viable anymore. New Kotlin WASM backend will rely on WASM experimental GC. And GC performance issues are mostly a myth. GC restricts performance only on very rare allocation-heavy workflows like game design or high load backends. And it usually could be mitigated by pooling and reusing objects.
n
Would be nice if the Kotlin WASM members coordinated with the Kotlin Native members on the GCs. There would be less work involved if Kotlin WASM and Kotlin Native had access to the same GCs.