Kotlin & Fritz2. I had to make some difficult decisions with the startup I'm a CTO of last year. I had a pretty junior team that knew Android, Kotlin, and a bit of server side Kotlin. Then for various reasons we decided to do web, Android, and IOS. So, web based development was a foregone conclusion as we did not have the bandwidth to ramp up separate teams. I did not have the resources to grow the team. And I did not want people to get side tracked learning a lot of new things.<p>Normally, I would have gone down the typescript + react route. I'm a backend developer but I've done some frontend projects with it before. But I was the only one on the team with relevant skills here.<p>So, instead I salvaged what I had which was lot of Kotlin know how in the team, a Kotlin multiplatform library that we built for Android already (api and model classes), and a Kotlin backend. So, I took a calculated risk of picking Kotlin-js as the main way to do our frontend.<p>I stumbled across a new framework called Fritz2 last year, which is written in Kotlin. I liked what I saw. We did a few spikes end of last year to check if it could do the job and worked as advertised (yes). Then we built a new web app with it in a very short time. I would normally not recommend people take that much risk but in our case it was defensible and it worked out great. In retrospect, we've been very fortunate as this is simply a very well designed framework. At this point we are very productive with it and have a feature complete app that we are putting in the hands of customers. Two months is not a lot of time to pull that off and I'm lucky with both the team and the technology we picked.<p>What do I like about this:<p>- It's just another Kotlin project. That means great tools, great language, and it happens to compile to javascript and run in a browser. We refactor at will, use nice Kotlin DSLs, have autocomplete for just about anything.<p>- Fritz2 is written by a small group of developers that know a lot about frontend development. So you get decent component technology (loosely inspired by react), everything is reactive by default (because Kotlin has great support for that), and they also integrated solutions for things like styled components, using and creating web components. So in short, it's a very modern feeling framework that should feel right if you are expecting clean code, components, and sane architecture.<p>- The Kotlin tooling for javascript is pretty great. It comes with lots of ways to integrate with the javascript world. E.g. we integrated leaflet and that was pretty straightforward: add the npm, adapt a few of the typescript mappings. Dukat which is the kotlin type mapping generator that does this automatically nearly worked but ended up generating a few problematic areas. So, I expect this to get better. But manually writing some mappings is not that hard.<p>- Kotlin StateFlows are a great way to represent state. Basically, components subscribe to state flows and respond to any changes you put there. This is a core concept that Fritz2 pushes hard with a concept of stores that store data classes and sub stores that you can derive from that for individual fields. It basically makes you do the right things with your state and you get very type safe and easy separation of rendering code and state management. If you come from Android, that's pretty much how things work there as well these days. Also, it's similar in newer frameworks like Swift UI and Jetpack Compose.<p>- Fritz2 uses kapt, which a compile time annotation processor, to generate code from model classes to make it easy to subscribe to changes in web components. That gets rid of a lot of boiler plate.<p>- It uses webpack underneath, which gives us a lot of flexibility for how we build our software. We also use cordova to produce native wrappers. With some plugins even.<p>- We use koin for dependency injection. And it's just as important of a design pattern in frontend as it is in backend code. Koin is what we used on Android and it's a great fit for Fritz2 as well. Nice testable code and we don't have a lot of Baron from Muenchhausen style self initializing code (like every messy js project I've ever seen).<p>Things I don't like that are long term fixable:<p>- The kotlin-js tooling still has some rough edges. It got a lot better with Kotlin 1.4. though. But undeniably, you will have to do some problem solving when dealing with this. Despite this, we pretty much hit the ground running with this and have not lost a lot of time over this.<p>- Source maps particularly seem flaky. So, debugging in a browser is a bit meh in a browser. If that matters to you, it's a problem for now. I expect this to get fixed as they improve the new IR compiler for kotlin-js.<p>- Performance of the build tooling and compiler is not great. In fairness, it's not a whole lot worse than the typical webstacks out there. It actually uses webpack underneath. But it's definitely not very fast. They do have incremental compilation and usually changes load in the browser after a few seconds. So, that keeps productivity high.<p>- There are not a lot of people doing this yet. So, you need to get creative solving issues. That includes reaching out to developers on the Kotlin slack, digging through OSS code to see how stuff works, etc. The community is very supportive. But if you hit a problem, Stackoverflow does not have all the answers just yet.