Kotlin has taken the world of Java by storm. It is in fact the default backend language at DripStat.

Kotlin on the JVM has 2 primary selling points:

  1. Better syntactic sugar than Java
  2. Completely seamless interop with Java code

The first point is especially relevant to the Android ecosystem which is stuck in Java 6 land. But even for server-side usage, Kotlin offers much better syntactic sugar that Java folks have been longing for decades.

But it would all be for nothing without the second point. Kotlin is 100% seamless with Java code. You can introduce a kotlin file in a Java codebase without disrupting anything.

Kotlin for JavaScript

Kotlin for JavaScript however has slightly different selling points:

  1. Saner, more typesafe language than Javascript
  2. Interop with existing javascript code and libraries
  3. Use same language on both backend and frontend

However, all of the above is complicated due to the presence (and popularity) of TypeScript.

Saner, more typesafe language than Javascript

TypeScript is already typesafe. While its still Javascript at its core, it allows you to avoid most of the blunders of Javascript. Unlike Java, TypeScript already has a lot of syntactic sugar that Kotlin offers and existing libraries in Javascript ecosystem utilize them.

For a TypeScript user, the syntactic sugar part of Kotlin doesn't have enough to offer to make the switch.

Interop with existing javascript code and libraries

Interop is vastly complicated for Kotlin in Javascript world. In the JVM, Kotlin has type information in the bytecode of java .class files it can use to offer seamless interop. In Javascript, no type information exists, making this much more harder.

TypeScript's solution was to get library developers to write additional type definition files. Even after many years the type definitions continue to break/mismatch across library and typescript versions. It is unlikely those authors will now write another set of type definitions for Kotlin.

Kotlin for Javascript thus tries to read type information from the existing typescript definitions instead. This not only makes it depend on TypeScript, but exposes the end user to dealing with all the fragilities of TypeScript's type definition files.

Suffice to say Kotlin's interop with Javascript code will never be as seamless as it is in the Java world.

Use same language on both backend and frontend

This is the prime selling point of Kotlin for Javascript. However, in practice this will not ring true anytime soon.

You cannot avoid knowing javascript on the frontend. You will be forced to look at javascript code since you will be using javascript libraries and for things like debugging code in the Chrome dev tools. Not only that, since Kotlin will require TypeScript type definitions for those libraries, you will also need to learn Typescript so that you can debug when you run into issues with those type definitions.

Conclusion

Kotlin for Javascript has a very different set of challenges compared to JVM. It is complicated since the lines have moved from Javascript to TypeScript. In fact, TypeScript has already done in the JavaScript world, what Kotlin has in Java. To win, Kotlin will have to prove its value-add against TypeScript, which it currently doesn't offer enough of.