Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
Quarkus just moves the problem IMHO. I find it similarly convoluted to use as normal Spring. I had to deal with that a few months ago on a project. Honestly, it actually feels a lot like spring used to be; and not in a good way. Lots of annotation magic all over the place.
I use Spring Boot by default. But I aggressively limit the use of annotation magic. I've never liked the byte code hacks people do to make annotations inject magical behavior. Hard to debug and painful when it does not work as expected.
I don't think either of these frameworks have an edge over each other. You end up using a lot of the same underlying library ecosystem.
I do like the annotation less direction that Spring has been taking since they started adding Kotlin support 4-5 years ago. If you want to, you can get rid of most annotations for things like dependency injection, defining controllers, transactions etc.
Especially with Kotlin, this makes a lot of sense. With Java, dealing with builders is just a lot more painful without kotlin's DSL support. You basically end up with a lot of verbosity, method chaining, etc. But it's possible if you want to. It's a big reason, I prefer using Kotlin with Spring Boot. Makes the whole thing feel like a modern framework. The hard part with Spring Boot is being able to tell apart all the legacy and backwards compatible stuff from the actual current and proper way of doing things.
There's a project that they've been pushing to get rid of all annotations: https://github.com/spring-projects-experimental/spring-fu/tr.... I suspect a lot of that stuff might be part of spring boot 3.x later this year. And quite a bit of it is actually already part of the current version of Spring.
This makes spring boot very similar to what you'd do with ktor. All you do is call kotlin functions. No annotations. No reflection. No magic. Very little verbosity. It's all declarative. And a nice side effect is also that it makes things like spring-native easier, which they started supporting recently.
It's very similar to using ktor with koin (for dependency injection). That combination is worth a try if you are looking for something lightweight and easy to use. Spring Boot has more features and complexity but it can be as simple to use as that if you know what you are doing.
Mostly, keeping things simple is a good thing with Spring. Also, I don't tend to do everything the spring way. Spring integration is a bit of a double edged sword for example. It offers a subset of the features of the libraries that it integrates. If you want the full feature set, you end up working around that. IMHO, you should do that by default. I've removed spring integration from several projects.
This article seems to attract Spring sceptics or even haters. Spring is not that bad.
First, XML configuration in Spring is mostly a thing of the past. Most applications are configured with annotations and component scan these days. While it is true that there is some magic in it, it is relatively rare to cause problems. With proper tooling like IntelliJ Ultimate it is mostly easy to manage and understand. If that still feels too magical, you can use a Java API to manage your classes: https://docs.spring.io/spring-framework/docs/current/referen... Even nicer in the Kotlin edition: https://docs.spring.io/spring-framework/docs/5.0.0.RELEASE/s...
> Importing other Spring files
That sounds like mixing different projects or poor API design.
> Spring is now so complex that it has it's own framework, Spring Boot
That is not true as such. Spring Boot is not an abstraction over the Spring Framework. It is more a convenience layer with useful defaults and some auto-configuration.
From my experience Spring brings some advantages:
- Quick start with https://start.spring.io/