I have shared my thoughts in this gist called "My call for Kotlin as a major frontend language" https://gist.github.com/sdeleuze/0da8c3d6a43c659977a16e017020503b

in the C# world, they are using wasm to great effect in Blazor: https://github.com/aspnet/blazor

I am proposing indeed to use WASM as the target for the entire frontend and keep JavaScript as an interrop concern, not the mandatory building block than unlike Java is not seemless when used from Kotlin. Everything compiled to WASM can be exposed with a JS API if you want to consume it from JS world, see Lin Clark articles about that.

There would probably need to be a frontend framework (like react and others) developed along side this WASM support for it to get adopted quickly. Of course there would be community frameworks made down the road if this was adopted but it could take a very long time.

Didn't @abreslav sort of touch on this whole WASM only idea at the KotlinConf 2017 keynote? He seemed to like it but also seemed to think it was more for the future. It was really brief, I don't think he said what his reasons were.

What would the interop be like with WASM compiled from other languages like C and Rust? Would it be similar to kotlin/native where interop needs to be worked out for each language separately? Or would we go through the js bindings they generate? Or just have no interop at all?

This blog post is pure gold, please read it: https://hacks.mozilla.org/2018/10/webassemblys-post-mvp-future/

Binaryen looks like a pretty interesting WebAssembly toolchain, and it also allows to compile WASM to JS. While LLVM is designed mainly for C/C++ languages targeting a huge number of different architectures, Binaryen seems natively designed for WASM, allowing faster compilation (to be verified but likely), generating more optimized code and it seems it will be natively compatible with upcoming WebAssembly GC (this info is from Luke Wagner , WASM lead at Mozilla). Sounds like a good basis for Kotlin/WebAssembly 😉 https://github.com/WebAssembly/binaryen/blob/master/README.md

And I personnaly think that when it will have GC and concurency, it would be the perfect target plateform for Intellij IDEA. Desktop Java is clearly not something very well suppported by Oracle, and for long term I don't see a bright future for this plateform. WebAssembly has only 20% performance penalty compared to native, and could allow to run something as complex as IDEA in the browser in a secured way. The competition will be hard with VSCode + GitHub on long term. So while this would be a huge work to move from the JVM, at some point I think this will be needed, and I think WebAsssmbly would be a great target plateform that could allow to provide both web and standalone versions.

Thread https://twitter.com/seldo/status/1061461318765555713

Java catching up is definitely a risk, if they maintain compilation speed.

@pabl0rg Indeed, catching up with Flutter is another reason for Kotlin to work seriously on WebAssembly. And I do think that only a Binaryen based toolchain will allow fast dev cycle able to compete with Flutter.

Google Chrome developers video on WASM and threads (Kotlin logo is shown in the video):

https://twitter.com/mkheck/status/1068150103905615872 -> https://twitter.com/mirkosertic/status/1068146124979167232

... and what is it?

I’m having a hard time gauging where Kotlin support is at with wasm. I’m running formal tests for Kotlin Native at my job (aiming at multi-plat) support for iOS/Android. I am wondering if it is worth the effort to see if my cross-plat components should include WebAssembly targets as well.

How does this relate to Kotlin + WASM? A good Kotlin/WASM solution may be the only way to create a competitive developer experience

unless you're talking about how they ignore the native UI toolkit and render everything themselves which i'm sure everyone will be happy to abandon standards-controlled specs for the language, layout, and styling that's used for putting faith in a single company now dictating all three

Hey, guys. Thank you for all your hard work for Kotlin! I have a question. We're choosing technical solution to migrate from JS to "something that generates WebAssembly" and we're measuring dis-/advantages between Rust and Kotlin in terms of WebAssembly. Could you please answer why you haven't reused LLVM-backend (codegen) written for Rust to generate WebAssembly? Is it correct that you haven't reused it? What's your feelings (or measurements) of generated WebAssembly "quality" by Kotlin compared to Rust one? (I know it's uncertain criterions for "quality" term but i think you know what i mean).

@sdeleuze have you seen Yew? Kotlin has much nicer syntax but yew seems awesome b/c there’s no gradle and no webpack https://github.com/DenisKolodin/yew

for example, what is Pointer? what is Arena?

I know @sdeleuze is doing a great job of selling it, but is it officially on the radar/roadmap for Jetbrains?

@sdeleuze, interesting perspective. Why do you think LLVM is not a good fit for Wasm? And what makes Wasm a significantly faster target to compile to compared to native binary?

2 questions I have regarding to an hypothetic Kotlin -> Kotlin IR -> Binaryen IR -> WebAssembly toolchain: - How much Kotlin/Native is tide to LLVM? Could we imagine some kind of Kotlin/Native IR not tide to LLVM that could be used to generate Binaryen IR when targeting WASM? - I heard that Kotlin/JS team is working on an IR, is there some kind of generic Kotlin IR effort or is it specific to Kotlin/JS?

Is it possible to export a Kotlin function in the

exports

of

WebAssembly.Instance

? I have tried using

@SymbolName

on the functions I want to export, but it's not showing up in the exports object

Is it simply that non of the IDE's yet support klib format to the extent that they can extract auto-completion data from them?

So above I noticed a thread where they were talking about Kotlin IR... what does IR stand for? Instruction Register? And what is it's purpose?

Standardizing WASI: A system interface to run WebAssembly outside the web https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/