Better integration with k8s, mainly through more opinionated libraries (you're less likely to accidentally choose heavyweight thing which tend your service towards monolith), faster startup & faster reloads during development.

https://github.com/spring-projects/spring-framework/issues/2... is an open issue for Spring; the moral equivalent is closed for Quarkus. If you have DI misconfiguration, you tend to get it at build time rather than runtime.

The equivalent would be actually Spring GraalVM Native. Not bad either but somehow for me it didn't work, so I started with Quarkus and didn't look back.

Just about to put a substantial project into production using Quarkus. I would say the main advantages vs SB are:

* mostly uses standard javax/Jakarta/Eclipse etc APIs so code is relatively portable (in ~600 classes I found 8 quarkus imports)

* build time DI/weaving

* best dev-mode autoreloading I have seen

* in general, less Spring-y

* less reliance on classpath-searching and reflection voodoo, less weird shit breaking bc of dependency version conflicts

* stack traces and class names (https://gist.github.com/thom-nic/2c74ed4075569da0f80b) that fit within a human’s field of vision

* less overriding feeling of death by OOP

We started with Spring Boot, switched about halfway through and never looked back.

> mostly uses standard javax/Jakarta/Eclipse etc APIs

This is the selling point for me, never was a Spring fan.