javalin VS kiit

If you've read this far, you might be interested to know that Javalin has been offering Brotli compression through jvm-brotli for three years already, and that there have been no (reported) issues. In other words, the effort required to release and maintain this is probably not huge.

I'm a big fan of Ktor (ktor.io) but another reasonable lightweight alternative is Javelin (https://javalin.io/). Heck even Spring Boot isn't that bad. HikariCP + JooQ (has both java and kotlin codegen) for DB access if you need and you're good to go.

A similar alternative that does not rely on web sockets is https://htmx.org. I have greatly enjoyed using it with some simpler web frameworks like https://javalin.io to do some prototyping and smaller projects. I'm sure if someone made a plug and play UI library like material UI for Angular on top of htmx you could absolutely fly through MVPs.

Javalin

If you're already familiar with most of the concepts around HTTP and web services, I'd recommend using something like https://javalin.io/ which is light weight frame work that makes getting something up and running quickly a very easy task.

I've been looking at https://javalin.io/ Seems close enough to express and some big names are using it, so I wouldn't say it's fizzling out

Javalin (https://javalin.io) is strongly inspired by Express and Koa, so you should feel right at home:

If you want to do a proper comparison between the two, I would be happy to help with code examples from Javalin's side. I could even host it on https://javalin.io as a "Comparison to Jooby" blog post.

I’ve been building a comprehensive Kotlin framework called https://www.slatekit.com/

Tests : All unit-tests ( for now, will be cleaned up later )

I don't use arrow or Category theory myself, but looking at the docs, they have valid reasons for deprecating Option ( from the docs and more so for creating type aliases for Either ). I'm doing this same approach with my implementation ( shameless plug ) of the **Result** type which is becoming somewhat universal for modeling successes and failures, and as an alternative to **Either**. You can easily type alias **Option = Result** and **Try = Result**. More details here. https://github.com/slatekit/slatekit/tree/main/src/lib/kotlin/slatekit-result

This post discusses using an application identity ( a convention based unique name to identify any app ) to organize, identify an application, and properly link the identity to the logs, metrics, alerts, and other diagnostics of the application. This was designed for a Kotlin framework called Slate Kit; codebase at Git, and code for this component here at Identity.kt.

I’m building my own micro-actor library to support some of my own use cases. Specifically I need to have the ability to start, stop, pause, resume actors multiple times gracefully. My design is not fully ready but pretty close. https://github.com/slatekit/slatekit/tree/main/src/lib/kotlin/slatekit-actors

Agree completely with everything you said and your observations regarding job market. I’ve been doing Scala for a few years and I also would not recommend it to anyone unless they have a deep desire to do pure FP(functional programming) on the JVM. The ecosystem/libraries are unnecessarily complex IMHO.

If you want FP-Lite, I recommend Kotlin, it’s very pragmatic, reasonably functional. I actually converted all my personal projects from Scala to Kotlin, including my framework https://github.com/slatekit/slatekit which took about a 4-6 weeks from the original code base.

I wish Kotlin designed their own Result type similarly to how Result is implemented in Rust or Swift, instead of defaulting the error type to Exception. I actually implemented my own version of Result for this specific reason (although I customized it to support a status field ). https://github.com/slatekit/slatekit/tree/main/src/lib/kotlin/slatekit-result

Well, thats finally it. I created a homebrew installer to allow for a command line tool to generate slatekit projects making it very easy for new users to get started quickly. It sounds like quite a lot at first, but there are only 3 concepts, the package( your script, app, tool), the tap (git repo for formulas), and the formula (installer). Hope this helps!