Kotlin For The Web Frontend

Web frontends in Kotlin are done through Kotlin JS which has had a very rocky start. When development first started with Kotlin JS its stable release was delayed by about a year, which didn’t help matters with ensuring Kotlin was competitive in the Web Browser (for developing web front-ends). After Kotlin JS has its first stable release as part of Kotlin 1.1 it lacked some key performance tools/features (eg dead code elimination), which should have been available straight away. As a result Kotlin JS was only suitable for developing internal business web front-ends. This delayed Kotlin JS’s wider adoption by about four months before it could be used in other areas like web apps for example.

Interoperability

Many statically typed languages like Kotlin struggle to provide decent interop with JS due to its dynamic (magical) nature. You never know with great certainty what JS code does, it is extremely unpredictable (very little explicitness is there). Unless a programming language is very similar to JS (eg TypeScript) then interop with JS is hit/miss and fraught with major difficulties (aka trying to fit square peg into round hole scenario).

To make matters worse the JS ecosystem is very volatile with no standardisation in sight. JS doesn’t have a official coding standard, a proper standard library (aka the comical LeftPad disaster), and has multiple variants like C which results in a fragmented language landscape (you never know exactly what JS variant/version is used). This makes deployment of software to the Web Browser very difficult, and testing can be a hellish experience.

Currently the preferred approach in Kotlin JS to handle JS interop is to convert TypeScript definition files to Kotlin source files via the Ts2Kt tool. However that approach is problematic since Kotlin needs to fit in with two languages (JS and TypeScript) which are moving targets. Also many TypeScript features (eg Union types) can’t be mapped to Kotlin features which will often require inspecting/correcting Kotlin source files generated by the tool. All other platforms that Kotlin supports don’t have this issue, only a single language needs to be accounted for.

Opportunities

With the advent of WASM the stranglehold of JS being the only programming language that is supported in the Web Browser has been broken. This has opened the doors for other languages to target the Web Browser. For the first time in web development history all major Web Browser vendors have decided to allow languages other than JS to run in the Web Browser by implementing WASM. All major Web Browsers (including the mobile ones) already support WASM.

Transpiling to JS has always been an option for many languages but has been far from ideal. For one thing transpilation creates unnecessary code bloat, and introduces a build step which slows down software deployment/prototyping. Another is that the resulting JS source code from transpilation can significantly add delays to loading a web app which is very costly (all JS source code has to be parsed by the Web Browser which is a slow process).

WASM would allow for a clean slate approach and include best of breed approaches (interop system based on Kotlin Native, use Kotlin JS as a fallback system for older Web Browsers etc). If Kotlin heavily relied on WASM for performance then there would be a lot of time saved which could be spent in other important areas (eg documentation/education).

Web Frontend Approach

If Kotlin is to gain significant traction as a major language for developing web front-ends it needs to switch tactics by taking advantage of WASM as a major platform (to handle performance/JS interop), and have a standard web front-end lib/toolkit/framework with the following qualities:

• Handles web development in very explicit ways (explicit development approach)
• Minimal use of magic/meta programming
• Avoids heavy use of JS libs/frameworks/tools
• Heavily embraces/promotes Kotlinic (idiomatic Kotlin/aka the Kotlin way) web front-end development
• Low learning curve
• Adaptive documentation (can easily/quickly update documentation via a standard process) that is Kotlinic
• Web UI is built/managed via a Kotlin DSL that is Kotlinic
• Keeps pre requisite knowledge to a minimum (only need to know the basics of HTML/DOM/CSS/JS)

Many of the key qualities mentioned heavily rely on embracing the Kotlin culture rather than the JS culture, which is where many of Kotlin JS’s issues come from. Going with React for handling the web front-end isn’t a good way to achieve progress for many Kotliners. JetBrains needs to realise that there are a significant group (large in size) of Kotliners that can be characterised by the following:

• Experienced with developing software using Kotlin
• Many already have some experience with developing back-ends using Kotlin
• Interested in developing a entire web stack (back and front ends) using Kotlin
• Want to do web front-end development using Kotlin which is Kotlinic
• Have no significant web development experience (on the front-end)
• Are not interested in using a JS framework to do web front-end development
• Disillusioned/confused/bewildered with the very volatile (unstable) JS ecosystem
• Want UIs built/managed declaratively via a Kotlin DSL that promotes loose coupling/type safety
• Need a very easy/quick/professional way to develop a web front-end that is done through EXPLICIT software development (keeps magic to a minimum)

These group of Kotliners (for a lack of a better term Kotlin Web Developers) feel very neglected as though they aren’t being listened to (taken seriously). A great way to address this is to have a Kotlin web front-end lib/toolkit/framework developed in collaboration with JetBrains and the Kotlin community, in concert with expanding WASM support at the same time.

Conclusion

In order for Kotlin to have significant adoption for web front-ends it needs to utilise WASM (for performance/JS interop), and have a standard lib/toolkit/framework for developing a web front-end (that is Kotlinic), where there is extensive collaboration between JetBrains and the Kotlin community. Also the reliance on the volatile JS ecosystem (tools/libs/frameworks) needs to be kept to a minimum to avoid many major issues.