Skip to content

Instantly share code, notes, and snippets.

Last active October 25, 2022 14:50
  • Star 45 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
Star You must be signed in to star a gist
Save sdeleuze/0da8c3d6a43c659977a16e017020503b to your computer and use it in GitHub Desktop.
My call for Kotlin as a major frontend language

My call for Kotlin as a major frontend language

I try to push for quite a long time for first class support for WebAssembly in Kotlin because I really believe that frontend development is a domain where Kotlin can be as strong as in mobile, and because this is something that would also help to increase even more the adoption on server-side.

I truly appreciate all the work already done by Kotlin/JS and Kotlin/Native teams. The dead code elimination tool and the initial WebAssembly support in Kotlin/Native are important steps in the right direction. But I believe that Kotlin needs now to make frontend a real priority to take it to the next level.

Need for a consistent and unified web frontend strategy

The first point I would like to raise is that what Kotlin needs IMO is a consistent strategy about web frontend wich includes both Javascript and WebAssembly related efforts. I can understand why it started focused on JavaScript and before multiplatform was a thing, but as I repeat it for more than 3 years now, Kotlin will never win on frontend with a JavaScript based strategy but it can win with a proper native frontend effort. What I mean is that if the main strategy is to leverage JavaScript ecosystem from Kotlin, the war is already lost, TypeScript has won. The lack of serious Kotlin/JS ecosystem is IMO a pretty clear confirmation of that.

What I would like to see is a strong Kotlin frontend strategy that would leverage both Kotlin/JS and Kotlin/Native assets via multiplatform APIs that could allow to leverage JavaScript or WebAssembly targets and ecosystems. We are living exciting time where WebAssembly provides a real web bytecode (JavaScript is not anymore the web bytecode, this is and will remain a hack) which is suitable compilation target and is supported by all major browsers. WebAssembly opens the web to new languages and technologies where previously being based on JS was required (TypeScript) to be successful.

Taking inspiration from Rust community

The feedback I hear for 3 years when I say that is that for now Web and DOM API are not available, and we will see when that will be the case. I can understand why frontend was maybe not the biggest priority at that time. But watching what happens on Mozilla side with Rust and Firefox lets me think this is not a real blocking point anymore. I strongly believe that Kotlin frontend effort should take inspiration about the work done on web-sys crate from Rust. Please also read Making WebAssembly better for Rust & for all languages and Calls between JavaScript and WebAssembly are finally fast where Lin Clark explains in a very clear way how things should be managed to bring new languages to WebAssembly.

These articles show IMO that the first key step if we want to make Kotlin a real frontend language is to provide a real statically typed Web and DOM API to Kotlin/Native WebAssembly backend, and the good news for Kotlin is that it could be also reused in Kotlin/JS thanks to Kotlin multiplatform capabilties. Kotlin has been successful on the JVM because it provides an awesome standard library that leverages the platform APIs perfectly. I deeply respect all the work done on Kotlin/JS, but the quality of the API generated from the Web IDL is bad (mostly because the source Web IDL is bad), and is a blocking point that prevents a healthy Kotlin frontend to arise. See KT-20743 and KT-22635 for a concrete example of what I mean. Watch also Building a Browser Extension with Kotlin amazing talk at Kotlinconf 2018 by Kirill Rakhman on that topic.

Building a multiplatform Web API

Here again, I think we should just follow what Rust team is doing: leverage a high quality Web IDL (in their case, the one from Firefox source code I think) to build a high quality Web API for Kotlin. And since frontend concerns both Kotlin/JS and Kotlin/Native, I think this is a very nice opportunity to leverage Kotlin unique multiplatform capabilities to build a multipatform Web API that could be used by both Kotlin/JS and Kotlin/Native.

For Kotlin/Native, the same API could work underneath in 2 ways:

  • A compatibility mode where JavaScript calls are used to invoke the Web and DOM API of the browsers
  • A native mode using reference types (already available in Firefox via javascript.options.wasm_gc preference) in order to avoid to go through JavaScript. Host bindings will also help when available.

The message I would like to share is that we don't have to wait the final version of WASM Web API to begin building this first class Web multiplatform API, we can move forward right now, by providing the right API to the Kotlin frontend ecosystem and adapt gradually when these pure WebAssembly Web API will be widely available.


In that world:

  • Developpers would build a Kotlin/frontend ecosystem where most of the code could be shared between JavaScript and WebAssembly platforms
  • JavaScript would be an interrop concern, not the mandatory building block
  • Frontend frameworks natively developed in Kotlin would arise from the community, like Vue, React or Angular style developed in Kotlin
  • Wrapping JS frameworks with Kotlin would not be the main way to implement a Kotlin frontend
  • We would be able to build frontend libraries and applications without using the complex and time consuming JavaScript toolchain, we would just use Gradle and nothing else
  • We need to provide a way to expose Kotlin/frontend libraries for consumption by WebAssembly based applications without using JavaScript in a mandatory way, like Rust do with its frontend oriented crates
  • Multiplatform Web API can even be used on Kotlin/JVM and Kotlin/Native servers to build isomorphic applications when renering can be done on server or client side.


Kotlin is the perfect language for the WebAssembly revolution. Rust is well suited for building high peformance WebAssembly libraries, but Kotlin is the only modern language (with Swift maybe) that is high-level and compatible with the native world.

Kotlin/JS as it is now has been built before multiplatform support, before WebAssembly, using a bad Web IDL. Putting more effort with the current approach will not make Kotlin successful on frontend. There is a need for major shift in Kotlin strategy about frontend that would make it ready for this new context, and multiplatform support gives the opportunity to leverage that in both Kotlin/JS and Kotlin/native worlds.

The key challenge in WebAssembly world is that it requires both native and web skills, and that's usually different people and/or different teams. The technologies successful in this WebAssembly revolution will be those where native and web teams work together or even better, are working in the same team. That's why Mozilla work with Rust and Firefox is visionary and something to take as a source of inspiration. If Kotlin is ambitious enough to adapt to this new context, I am truly convinced it could become a major frontend language.

Copy link

I really like this idea because I'm looking to Kotlin/Native to allow me to do Android and iOS development without having to learn both Kotlin and Swift (not a huge jump I know). Not only does this make my life easier as a developer but it would also optimize mobile development investment for companies. Can you write both apps in only Kotlin? I trying now but running into problems with tooling on the iOS side so jury is still out.

I would love to leverage that same knowledge to do JS work but I wonder how crowded already is the frontend work with languages like Elm, TypeScript, Pure Script, etc? That said, I would rather write Kotlin on the front end instead of the Elm code that I'm writing now.

Looking forward to seeing where this goes.

Copy link

dupski commented Oct 21, 2018

As an experienced JS and TypeScript front-end developer, I completely agree with what you have said.

I've watched a few of the talks on Kotlin/JS with React and they made me cringe - it seems like completely the wrong approach. JS has an incredibly rich ecosystem and enterprise-grade tooling in the form of VSCode, JSX and TypeScript. (and TypeScript has many similarities with Kotlin)

As you say, rather than trying to keep Kotlin/JS up-to-date with the JS ecosystem (and the thousands of continuously-evolving NPM modules!), I'd much rather see that effort spent adding first-class WebAssembly support.

Once we have good WASM support, hopefully some clever folks will be able to write a kick-ass kotlin-native UI rendering library that talks to the DOM directly, rather than relying on maintaining compatibility with non-kotlin libraries written in a JIT-compiled scripting language :)

Copy link

gbaldeck commented Oct 21, 2018

Great points, and I agree this would be a great strategy. I do not agree with this statement though:

"Frontend frameworks natively developed in Kotlin would arise from the community, like Vue, React or Angular style developed in Kotlin"

Angular and React did not arise from the community. Usually, "community developed" means open source and unpaid. Angular and React were created by Google and Facebook respectively with large teams of paid developers. Vue, on the other hand, did arise from the community. The Vue team is now paid by corporate sponsors but it did get its start in the community.

For Kotlin to have more adoption in the frontend community there will need to be a framework developed by a company, not necessarily JetBrains, that uses Kotlin as a first-class language. Similar to what JetBrains is doing with ktor. Since there wasn't a backend framework on the JVM that has Kotlin as a first-class language JetBrains decided to make one. There needs to be a "ktor" for Kotlin on the frontend before there will be widespread adoption.

Your focus on web assembly is spot on in my opinion. And I agree that focusing on it along with MPP will create a solid platform for frameworks to be built from.

Copy link

Thanks for your feedback.

In my mind community means outside JetBrains, because I would like they focus on this potential Kotlin/WebAssembly effort. Community includes both open source contributors (that could turn that into a suitable paid job if successful) like if I am not mistaken Vue.js guy, or companies like React or Facebook did for JS.

Also Lin Clark wrote an amazing blog post about the future of WebAssembly and what she describes seems to be compatible with my hope for Kotlin.

Notice that I am not sure yet if WebAssembly support should come via Kotlin/Native and its LLVM toolchain or via an evolution of Kotlin/Js toward Kotlin/WebAssembly, because GC, type references and host bindings WASM proposals will maybe be more close to a better Kotlin/JS that does not force developers to pay the price of JS toolchain and of the JS limits than something really native oriented. Future will tell ...

Copy link

JuniorCC commented Nov 5, 2018

I want to be part of it. I always hated JS since the beginning. JS made popular because it has JAVA in the name. And because it was the only alternative that we could take. I think kotlin and WebAssembly could be a solution. I want to help to provide this alternative.
In addition, because Java is not really free anymore. I think kotlin is going to increase in popularity. I could help writing things in Spanish or maybe creating samples.

Copy link

tpscrpt commented Nov 15, 2018

Great read!

Copy link

epabst commented Dec 5, 2019

I enjoyed reading this.

Copy link

This is great. Now that Jetpack Compose exists and is open source, it seems like the perfect candidate for a cross-platform UI framework.

Copy link

I'll just leave an update here:
Compose for Web

Copy link

assimbly commented Feb 1, 2022

I strongly agree and seems that WASM as serious compiler target is finally taken off:

One day we look back at this ridiculous time, when one need to program in multiple languages, where one must be JavaScript/Typescript...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment