I love JavaScript web development except for the JS part. It's not personal: in fact, JS is pretty cool and imo it helped push concepts like closures into imperative languages (don't @ me, functional languages).
The thing is, I make mistakes that compilers identify & remedy really easily. I what static types do for me. Computers are very good with structured data. Have you ever tried to refactor a method like gross_pay in a dynamic language? 😵 Structural certainty lets us reason more like mathematics and develop proofs. Halting problem aside.
Indeed: TypeScript was the fastest growing language in 2022 (see JetBrains State of the Developer Ecosystem). Maybe like Sorbet for Ruby. These brought a sigh of relief. Being able to incrementally migrate a codebase… really? No need to rewrite it all in another language? 🤩
Still– all else aside, I simply prefer languages designed and tooled around static types. Think: IDE refactoring, static analysis, automatic optimization… While that opinion is fine for the server, it's been a non-starter for the browser. (It's also tricky vis-à -vis Python for scientific computing but that's another story.) Ya can't avoid the JS.
WebAssembly changed that. For example Microsoft developed Blazor to run C# in the browser, similar to Kotlin Multiplatform by JetBrains. I know many developers from both .NET and JVM lands who'd love to avoid loosey goosey scripts.
While these frameworks run in the browser, WebAssembly doesn't use HTML. Instead, apps render pixels to the window canvas much like mobile or desktop apps in operating system windows.
The kobweb project–where Kotlin renders HTML & JS–lists some disadvantages [permalink] of the canvas approach; these stood out to me:
- robots would lose the ability to crawl and index your site, hurting SEO.
- your initial render may take longer.
- your UI will be opaque to the powerful suite of devtools that come bundled with browsers.
- accessibility tools for browsers might not work.
It would also prevent a developer from making use of the rich ecosystem of Javascript libraries out there.
As languages, HTML & CSS bother me on a whole other level… 😤 but nobody has time for that rant. Rants aside, it's true that HTML tooling for consumers & developers alike is simply better. In any case, I wanted to use Kotlin.
Kotlin/JS looked like a way to have my cake and eat it too. It transpiles Kotlin to JavaScript, which becomes business as usual for the browser. Now, "all" we need is code to render our app's HTML right?
Any web developer knows one does not simply render html apps with a few functions. Entire frameworks exist to maintain the HTML document based on application state. Just managing the state is a big part of a browser app let alone creating HTML.
The Kotlin/JS page recommended two frameworks for rendering HTML: KVision & fritz2. I went with KVision somewhat arbitrarily; I did like that it supports UI elements like panels, grids, etc., and is less DSL-heavy.
Armed with this question,
how much Kotlin can I do in the browser?
I started this web app, based on a practical need in my home routine: You Need a Splitter
Stay tuned for what I learned!
Top comments (0)