The potential of Kotlin/WASM

This feels like a good development! I hope devs actually do opt to relinquish "pixel-perfect" control (as this post & numerous other projects cite) for "text/html" intercompatibility; it's unknown atm. Im not really conviced projects even have to give up that much control/exactness to have a html/dom render target... it's heartening to hear at least one native world framework even bother to try & fit in, especially given how low it feels the lift should be. Good report! Thanks! But it does still seem contrary to the spirit of this post; Im glad to hear there's better/more respectfully positioned attempt, very glad, but the danger still seems ultra-real.

For most of the similar frameworks exploring making the web a target, there is zero interest or care in "text/html". Flutter, Qt, Uno: they come bearing no gifts, no respect, simply seeing the web's very lowest levels as an efficiently accessible delivery target they can exploit, & they have zero compunctions about ignoring the 99.9999% of the web stack that all other sites use in favor of the low level graphical interfaces.

It's increasingly a full stack language. I would say increasingly more so than javascript since it actually compiles down to native. So, you can use it in the browser, in the jvm, with node.js (not a great fit but it works), on edge networks or in lambda functions (with the native compiler or soon wasm), or on mobile devices.

The main things holding kotlin native back have been the compiler and the library ecosystem. The compiler has been making a lot of progress over the last two years. And the library ecosystem has a growing number of high quality multi platform libraries. So, there's less need for wheel reinvention.

Long term, given enough interest, it could start competing with Rust and Go for system programming type things. Right now, that's probably the weakest area for Kotlin but that is mostly because of the relatively immature library ecosystem around Kotlin native for this. IMHO the language actually fills a nice gap between Rust and Go. Easier than Rust, a bit more high level than Go. So far, Jetbrains seems more interested in mobile than in other use cases for kotlin native though.

Finally, Kotlin is actually a nice fit for data science jobs as well. Nicer than python to use for this and a bit less esoteric than things like Julia or R. There are some interesting libraries for Kotlin for this. But like with native this is all relatively immature and a bit niche at this point.

Some interesting things you might not be aware off:

- multi platform compose is a thing and as of recent releases it has an experimental IOS target as well. So, you can build desktop, android, web, and IOS capable applications now with using Kotlin. Unfortunately Desktop compose still depends on the JVM instead of using the native compiler. So, there's now a third alternative emerging next to Flutter and React Native for cross platform UI.

- ktor server can now be used with the native compiler. So you now have two ways of producing native binaries for ktor via graal and the kotlin native compiler. Great for use with e.g. lambda functions as well.

- kotlin scripting (KTS) is pretty nice and you can use it in more places than just Gradle. It works in Jupyter for example. Or you can generate github actions with it (we do this via krzema12/github-workflows-kt).

- you can plugin wasm to kotlin (and lots of other languages) via extism.org. Haven't tried this but looks intriguing.

> Finally, Kotlin is actually a nice fit for data science jobs as well. Nicer than python to use for this and a bit less esoteric than things like Julia or R.

Julia and R are esoteric? For Data Science? Also, Kotlin would be relatively low on the list of languages I would use for DS. F# is higher.

At some point someone will figure out the wire up between the reactive part (thing like "signal") on wasm side and and propagate changes to the effect side to render DOM nodes.

The difference between having, say, C++ code where the variable names are scrambled versus having assembly seems vastly different to me. And that parallel seems 100% accurate here. JS may be minified but you still are reading the cide that was written, where-as no one seriously authors wasm; it's a lower level (virtual) machine.

And it's worse. Because wasm is a separate process, so now there's multiple things to debug & learn. Tools like wasm-bindgen generate complex glue code to bridge wasm and the host/js side. The wasm-verse brings a ton of new challenges to legibility.

Learning minified bundled js codebases can be daunting at first, but it's ultimately js, most often built with normal-ish stacks, and the code usually shows it's nature pretty quickly after setting some DOM event breakpoints. It's nowhere near the joy of view source, but it's not bad.

Notably Chrome m111 just turned on pretty printing by default, so the first couple milliseconds of opening the debugger should be significantly less overwhelming. You used to have to know to press the prettify button.