Great read Sebastien, very inspiring

Thanks

I honestly hope you get to convince whoever needs to be convinced; it all sounds like a hellish amount of work, but completely worth it. Good luck!

Kotlin/Native contains a good basis for that with the WebAssembly support, what I describe is not small work indeed but I am not sure it is unrealistic. The main challenge come from the fact that currently Kotlin/JS and Kotlin/Native seems to be 2 distinct teams with little interactions. What I describe is more a Kotlin/frontend initiative that would leverage Kotlin/Native WebAssembly support and leverage Kotlin/JS knowledge to make Kotlin a real frontend language.

You stated that very clearly in the gist, yes; and as I said, it doesn't look easy but it also looks like the best path to take as it comes to kotlin+frontend. The question is, how do we make it be the safest path as well? I would be all in, but not everyone is the personification of YOLO I am.

I think one of the key strength of Kotlin team is to listen feedback from the community, and I think the core stuff of what I described need to happen on JetBrains side. After that, we as a community will be able to build a strong Kotlin/frontend ecosystem. But for now I would say the ball is in JetBrains court.

Frontend is not the same thing as web, mind you. The most Kotlin-ish way to write frontends with Kotlin is still JavaFX/TornadoFX, as that uses the original language that supports things such as multi-threading.

yes, maybe @sdeleuze should change the wording from

frontend

to

web

, as

frontend

also includes desktop and mobile, but his point is only about

web

and he was very clear about it

I indeed mean frontend web development

I'm not a frontend developer but it sounds convincing. There are few small typos like 'general general'

Client side Web development means Angular and React to most people though. In that perspective, Kotlin/JS as a replacement for Typescript does seem to be the right thing to do..

As explained in my post, Kotlin/JS doesn't offer a good Web and DOM API right now because it is not generated from the right Web IDL, and I think you can't beat TS by generating JS. If we want a first class web client support, Kotlin should provide first class WebAssembly support and build its own frontend ecosystem not based on JS (while still providing JS interrop). TS is designed for JS era, Kotkin needs to be designed for the WebAssembly era which open the web to non-JS languages. Otherwise it will never feel "web native" for frontend developers.

I think it will help (for me at least) if you will give an example

I've been waiting for usable WebASM for ages, would be nice to be able to write it in Kotlin. Custom HTML components using Unity or something similar for example is something that would be great, you can have something look exactly the same in all browsers with no extra effort, it'll be much more performant when having to display lots of data (JavaScript + HTML suffers when you want to display enormous data tables)

@oshai What kind of example would you need ? About the limitation of current Web & DOM API in Kotlin/JS ? About building frontend web applications without JavaScript leveraging WebAssembly ?

About the dom limitations and idl

How would WebASM fit into the Angular and React ecosystem?

It will not, and this is the point of Sebastien, as I understand That WebAsm is new platform for web and all existing JS frameworks not relevant anymore, so it gives some room for Kotlin

That gives more Kotlin a better chance in a new space but that also is something that is not currently mainstream. If you ask a web dev what they would use for client side apps, I'd wager WebASM is pretty low on their list unfortunately 😔

As said by @gildor, my point is that there is a need for frameworks like Angular or React but natively developed in Kotlin, not wrappers on top of JS based frameworks which will always lag in term of feature, will always be seen as not first-class solutions and will combine the drawbacks of the 2 worlds: you need to use a non-JS language and have to pay the price of using a JS ecosystem and toolchain.

my understanding is that with WASM the DOM and JS APIs are still not really available

As said in my blog post:

ah, sorry 🙂

yes + a native mode using reference types is already available in Firefox via

javascript.options.wasm_gc preference

I'm hopeful that this gains some traction. I think you made a lot of good points.