<@U8LCS2KK9> Is the Kotlin/WebAssembly target curr...

# webassembly

[darkmoon_uk]

@jetbrains Is the Kotlin/WebAssembly target currently under any active development?
https://discuss.kotlinlang.org/t/wasm-wasi-where-do-you-go-kotlin/12175/3

[napperley]

Very concerning that Kotlin's WASM support has come to a standstill, unless there are some recent developments that JB will be sharing soon.

[napperley]

What are the plans for Kotlin's WASM support?

[elizarov]

What missing features are you waiting to be implemented?

[napperley]

Some major features that are missing:
- Access to JS APIs (eg manipulate the DOM)
- Automated memory management (GC/ARC)
- High level data types (eg Strings)
- Bi directional communication layer between WASM and Kotlin Native (eg have a Kotlin library on one platform that can be accessed on another platform)
- Coroutines/multi threading support
- Exception handling

[darkmoon_uk]

- Everything @napperley suggested ✔️
- Coroutines & Serialization are fundamentals for useful App development (and a blocker for me to use WASM)
- Ktor Client Support would be a 'gold standard' (as this is a JB project)

[napperley]

One thing that would be nice (not essential but would provide Kotlin with a large advantage over its competitors) is to have a WASM web front-end library/framework:
- Designed from the ground up to target WASM via Kotlin Native
- Does things that are Kotlinic (idiomatic Kotlin/ aka the Kotlin way)
- Provides good performance
- Has a standard way to easily develop custom web controls
- Isn't heavily reliant on a major JS library/framework
- Uses a easy build/deployment process
- Provides a rapid/iterative prototyping system (eg hot code reloading)
- Code based DSL system for building/managing views (including data binding/styling)

[darkmoon_uk]

...such a thing would be a huge enabler. In Mobile Dev, myself and colleagues are universally of the view that we've love to be able to work in web front-end, to treat the browser as another client; just not at the cost of having to touch JavaScript.

[napperley]

One of the biggest issues with Kotlin JS is dealing with a complex build system imposed by JS (so many steps that shouldn't be needed to do basic things). Also the JS ecosystem moves at a ridiculously fast pace, which at times is overwhelming to deal with for back-end/mobile/desktop developers. There is a opportunity with WASM for Kotlin to do front-end stuff (from the ground up) at a sane pace that developers can easily keep up with, which isn't bogged down by a new JS trend/standard ( https://xkcd.com/927/ - aka JS fatigue ) that lasts about 3-6 months 😆.

[olonho]

Further development of LLVM-based Kotlin WASM isn’t our top priority indeed, but another backend specially for WASM is being considered.

[darkmoon_uk]

Thanks @olonho ...feels like it could be a missed opportunity, but it's good to have an answer either way.

[darkmoon_uk]

@napperley 😭

[darkmoon_uk]

@olonho Maybe you have already seen it; but for your consideration this WASM transpiler project looks impressively made:
https://github.com/mirkosertic/Bytecoder

[sdeleuze]

@olonho Glad to hear that 👏

[gildor]

I don't think that it is missed opportunity. K/N (and llvm toolchain in general) is definitely not the best choice for wasm. I would say it's focus of effort.
All feature requests mentioned above are hardly related to K/N in general.
And Kotlin JS or even separate backend is way to achieve it, not llvm and k/n

[elizarov]

I’ve just started reading the wish list and I already see that it has nothing to do with Kotlin. This is mostly a list of missing things in WASM that we are all waiting for.

[gildor]

Exactly my thoughts! Most of those things just do not exist in wasm (or on some technical preview stage)

[darkmoon_uk]

Ok, thanks for the enlightenment 👍