Sorry to flood with links, but this new one is from somebody that a lot of people listen in our industry https://twitter.com/monkchips/status/1121005136766275584

I'm considering implementing a WebAssembly App as 'just another Client', following the MVP pattern, and using Kotlin/wasm32, writing a View layer using the HTML DOM klib. One obvious problem I'm wondering about when taking this approach, is the browser back button: if writing a stateful WebAssembly 'Application', then the browser back-button would, on the face of it, be like an 'immediate quit', losing all the App state and potentially ruining the UX. Is there a way to veto or intercept the back-button? (I'm an experienced mobile dev. but a dummy when it comes to front-end web... hoping to crack that with wasm) Normally I'd be against taking control of the back-button but this seems like a valid use case (i.e. intercept the 'back's for your Apps own purposes, until it's at 'root' and the next 'back' is then passsed to the browser for an actual 'back').

As expected https://swiftwasm.org/

Anybody converted the JsValue to Kotlin String?

Remember Blazor, they compile C# to WebAssembly, but also to Flutter...

Can anyone say if there have been any significant advancements in Kotlin/WASM tooling since the publication of this article, little over a year ago? https://superkotlin.com/kotlin-and-webassembly/ I'm truly surprised at the apparent silence on this front; since the push towards WebAssembly (read: away from JavaScript) is one of the most exciting frontiers in mainstream technology at the moment - and with a lot of reward up for grabs. I would not be at all surprised if JetBrains have a dedicated WebAssembly IDE (perhaps as a major iteration of WebStorm) quietly in the works.

@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

That was my conclusion when first trying it over a year ago; coming back it seems nothing's changed - obviously not a JB priority which is a shame given the potential.

What makes LLVM not suitable for wasm? Isn’t that what Rust is using? I was under the impression that it worked very well for it.

Hello everyone. Is there any lib / framework similar to Microsoft Blazor?

Indeed https://github.com/JetBrains/kotlin/commit/6e6ffa12a6893b8078986cd3b16c08f41ebb4809 ❤️

We started to experiment with a dedicated Kotlin to WebAssembly compiler backend. It supposed to generate code directly without LLVM. We are looking to target upcoming versions of Wasm with garbage collector and other post-MVP features.

Do any of the browsers currently support wasm garbage collection?

message has been deleted

Just want to ask what sort of jsinterop calls do you guys miss,use or need most in wasm? I'm writing a generic browser jsinterop module for my wasm lib and thought it could have the commonly used js calls in it as well for reusability

Is there an http client i can use for kwasm? Or do i have to delegate to js?...

Just released KVDOM MVP: https://gitlab.com/lt.petuska/kvdom/-/releases What's KVDOM you ask? It's an MPP implementation of virtual DOM available for js and wasm targets (also common module targeting them both). In addition to that, kvdom-dom module exposes some basic DOM bindings to kotlin-wasm directly and can be used as a standalone lib.

Is the WASM compiler backend going to evolve into a new Kotlin development platform (aka Kotlin/WASM)? Will there be any Kotlin WASM announcements made during KotlinConf?

FYI: Some changes in KVDOM versioning. • To better indicate that the project is at the experimental stage, version was changed

1.0.1 -> 0.0.1

. • README updated with some light on how to set it up. • Baseline DOM window api hooks added for easier setup Other than that,

v0.0.1 == v1.0.1

. Also note that

v1.0.0

and

v1.0.1

were removed from bintray. https://gitlab.com/lt.petuska/kvdom/-/releases

any good news for Kotlin Wasm?

What is the expectation of performance comparing Kotlin/Native to Kotlin/WebAssembly? Or will it depend much more on the quality of the specific implementation used?

is it possible to remove the JavaScript interop support when compiling to WASM? we're also looking at removing other runtime features as well (like GC). basically we're looking for as barebones as possible. we tried setting compiler flags through gradle but they aren't working and we can't seem to find any documentation on it. any thoughts? thanks!

After fooling around a bit, we finally could get a simple Kotlin program to export the entry point we needed (using the annotations to keep and export the symbol didn't seem to really do what we hoped for tho). That's also working around the WASI expected functions to pretend they are there, not a big deal, but we'd rather not have the whole JS interop part of our modules… These are expect to be lightweight functions (think FaaS, loaded as dyn libs effectively). Are we looking at Kotlin Native's support for Wasm in a too early stage? Or are we just looking at the wrong set of documentation? Or source code? Anyone can point us to either where we could find something to help ourselves, or if what we're trying to do is just not a real option right now using Kotlin? We'll keep on giving it a spin tomorrow, but any pointers would be greatly appreciated.

Are there any plans to bring

dynamic

keyword into wasm?

What is the status of the Kotlin/WASM compiler at the moment, and is there a way to follow development?

Interested in this too

Hi, everybody! I just wanted to clarify the current situation of supporting WebAssembly in Kotlin. We are working on a dedicated Kotlin to WebAssembly compiler backend. So all works on wasm support in Kotlin/Native (through LLVM) were suspended. For the new compiler backend, we have set the following goals: • produce small binaries -- to achieve it we decided don’t use own memory manager and use builtin one instead (see GC proposal); • fast compilation while developing -- for that we are going to be able to generate binaries directly; • better integration with hosts, especially with their GC to avoid leaks. Besides GC proposal we also depend on some other proposals that aren’t finalized yet. It’s hard to predict when all of them will be finalized and implemented. We have joined WebAssembly community group to work on proposals along with other stakeholders. Also, we are collaborating with some of Wasm VM vendors to get things done as early as possible and with our interests in mind. As well as other kotlin compiler backends it’s developed inside a public repository, so actual sources could be found here. We’ll try to keep you up to date, stay tuned!

Is there a definitive list of types that can be used as external js function arguments and return types on kotlin wasm?