Hacker News Reader

Comment by simonw | Hacker News Reader

This is a really nice API design: https://javalin.io/documentation

Feels lightweight but powerful - it seems to cover everything I need from a framework in terms of URL routing and request/response handling, with minimal cruft and boilerplate.

View on HN

That was why I picked it awhile back. I hate that most Java development these days has a large component that deals with writing XML. It allowed me to focus on the code I needed to write and not figure out what parts I needed to cobble together.

Are you comparing to legacy java applications? Haven't written xml in soon a decade in spring boot.

What do you define as "Legacy?"

I groan every time I come across a Maven project, which AFAIK isn't quite yet "legacy."

What about dependecy management, testing, building, and all of the other non-java-code bits? Gradle only goes so far in my limited experience.

The non-Java parts of Java development are what repeatedly get me to choose Go, Ruby, Python, TypeScript/node.js, etc. The tooling is magnitudes easier to use.

Genuinely curious! Thx.

(edit: typo)

Not who you are replying to but I would define legacy as any project that is doing spring di and wiring the project together with XML (excluding Pom for maven building), rather than annotations or raw Java code. Or anyone still deploying to an application server.

But the project configuration has nothing to do with the web framework. You can use Javalin with Maven (and therefore XML), too. And you can use Spring without any XML by configuring the project with Gradle's Kotlin DSL. Modern Java development is not what it was 20 years ago.

Go to most Spring Boot pages or examples, XML is in your face. "legacy"? Modern examples still push the xml injection bs.

This isn't factual, Spring and Boot have been 100% annotation configurable for almost a decade. The Spring documentation I read has zero XML.

No, they don't. There is some xml in getting dependencies through maven, perhaps. But that's not really a huge issue.

One of the good things about it is that using asynchrony is optional. If you don't have to call out anywhere to build the response, processing can all stay in the handler's calling thread. If you do, you can return a future and have the library handle the async for you.

One downside is that it is based on Jetty which isn't considered the most performant backend. A lib with a similar API but based on Netty is Jooby [1] which scores well in the Techempower benchmarks.

[1] - https://jooby.io/

>Jetty which isn't considered the most performant backend

This definitely needs some supporting links. Jetty itself is extremely fast in my experience.

Concur, Jetty has been faster than Tomcat in my experience. Undertow seems even faster in my testing.

The cookie support seems lackcluster. I'd prefer good support for real cookies instead of "stuff JSON into a single cookie".

Also the URL parameter API is clumbersome:

    Integer myValue = ctx.queryParamAsClass("value", Integer.class).getOrDefault(788) // validate value

I would prefer some specialized API like:

    int myValue = ctx.queryParamAsInt("value", 788);

Given that it's kotlin, one could easily make an extension function like that yourself and enhance the API to your liking.

Reply on news.ycombinator.com