by Adam Arold

How to go beyond Android and use Kotlin on the frontend

Photo by Jacob Miller on Unsplash

This article is part of a series. Check out the previous part here.

Though most developers use Kotlin on Android, it is also a viable option on other platforms. In this article, we’ll look at how it works in the browser. We’ll walk through an example which is rather minimal, but it comes with batteries included: testing, minimization, and deployment.

While the kotlin2js plugin has been around for quite some time, it was not considered production ready because the JavaScript code it generated was measured in megabytes. It was also hard to set up testing and external JavaScript dependencies. How this changed lately? Enter Kotlin Multiplatform Projects.

With the advent of this new feature, now it is possible to share code between multiple components in your program. Using the JavaScript compiler has also become much easier. I’ll talk about Multiplatform Projects in another article, so now let’s focus on getting it to work in the browser.

Project Setup

The source code for this article can be found in this repository. It is a simplified version of the code found here.

We’ll be using Gradle for building the project. There are other build tools out there, but Gradle has the best support for Kotlin.

When creating a Kotlin project which compiles to JavaScript, you can stick to the same project structure which you have already gotten used to: src/main/kotlin for Kotlin files and src/test/kotlin for test files.

Our build.gradle , however, will need some extra configuration.

First, in the buildscript next to the usual kotlin-gradle-plugin , we’ll also need the gradle-node-plugin:

This is a necessity, because we’ll delegate a lot of work to JavaScript libraries like Karma and Webpack.

Note: for those of you who want to completely get rid of JavaScript, I have bad news: currently it is very hard to completely do away with it. We are either stuck with some JS tools, or we have to completely rewrite everything in Kotlin, including tooling.

Next, instead of applying the kotlin plugin, we’ll use the kotlin-platform-js along with kotlin-dce-js and com.moowork.node:

kotlin-platform-js is used in multiplatform Kotlin projects, but it also works for standalone JS code like in our example. kotlin-dce-js is responsible for dead code elimination which will help us create very small JS files. com.moowork.node is for interfacing with node.js.

With all the plugins in place, we’ll need some dependencies:

kotlin-stdlib-js as its name suggests contains the Kotlin stdlib for JavaScript projects. kotlin-test-js is for testing our code.

The rest of the configuration is to wire together the kotlin2js compiler with the JavaScript world:

A quick JavaScript tooling crash course

We’re done with Gradle, but we still need to set up Karma and Webpack, and a package.json is also necessary. “Why are these necessary?” you might ask. The answer is that if we don’t want to rewrite everything in Kotlin, which is not part of our business domain (like testing tools, package management and such), we’ll need to use those which are present within the JavaScript ecosystem.

Fortunately the plugins we applied above help out with these.

Note that discussing these tools in depth is out of the scope of this article. There are links below so you can read their documentation.


Karma is a test runner tool for JavaScript. You can think of it as something like JUnit in the Java world.

It will pick up the karma.conf.js automatically when we test our project:

This config will work from our source and test folders, and will use a Chrome headless browser to run our tests.


Webpack is a module bundler tool which can be used to create JavaScript artifacts. It works in a similar way like Shade works in Maven and Shadow in Gradle. This is not entirely accurate, but this will do for now just to understand why we need it.

We’ll need two files. One for development:

and another one for bundling our project:

The package.json

The package.json file is essentially a way to manage locally installed npm packages (npm itself is a JavaScript build tool, like Maven or Gradle).

The example project uses yarn which is an upgrade over npm. But yarn uses the npm package repository in the background.

In our project, we’ll need a very simple setup with only some wiring for development and testing tools:

Are we there yet?

Yep, we’ve pretty much wired together all the tools and plugins. I have to note here that there are many ways to set up Kotlin frontend projects, like using the kotlin-frontend-plugin or using the gradle-js-plugin.

The reason why I chose this setup is that this way we can exploit all the functionality these tools give us like:

  • hot code replace
  • browser sync
  • using JavaScript libraries from npm
  • creating bundles with Webpack
  • Unit and functional testing, including async tests

Let’s write some code

Now that we have set up the project, we can finally start writing some code! Let’s create a Main.kt with a main function in our source folder:

Now, if we build the project with ./gradlew assemble , we’ll find an index.html in the build/dist folder. Let’s open it and check the developer console:

Congratulations! You have successfully compiled your first Kotlin project to JavaScript!


This is all well and good, but you won’t get far without the means to write proper unit tests. Luckily Kotlin provides us with a testing library with which we can write Kotlin tests. It will be run with Karma under the hood.

Let’s add something to test:

Then add a test for it:

Now if we run ./gradlew test we’ll be presented with a nice output for our test:

While this covers unit testing, we’re still not out of the woods yet. We also need to test our program in its native environment: the browser.

Note that, technically, the unit tests also work in the browser. But they do not touch functionality provided by it like the window object in the following example.

Fortunately we can use the DOM, and we also have the option to write asynchronous tests:

Now we have everything at our disposal to start working on real applications which will run in the browser!


While this article is far from exhaustive, we’ve touched on a lot of important points. I think that Kotlin development in the browser is definitely doable, and since the 1.2 version of Kotlin frontend development, it is also production ready!

We have learned that deploying Kotlin code to the browser is not hard, and it only comes with a fixed amount of boilerplate which we only have to set up once.

If you are interested, there are a lot of other examples including the kotlin-frontend-plugin with extra webpack config or a Kotlin Full-stack example.

I’d also recommend checking out the Kotlin blog and the official JetBrains repo.

The code for this example lives in this repository. Feel free to download it and fiddle around with it.

So go forth and Kode on!

Keep tuned! The next article in this series will be about multiplatform development, with a full stack example!

Thanks for reading! You can read more of my articles on my blog .