5 ms·

Micronaut or Quarkus seem like good competitors, does Spring Boot have the edge over them?

krzyk 5y ago
Quarkus had a really annoying static only DB layer which turned me off. Spring Data was way better with the interfaces. I don't know if Quarkus changes recently (well, in 2-3 years) in that regard. And 3 years ago it didn't support newer JDK versions, it supported up to JDK 11 AFAIR, while there was already JDK 13 or something like that. It was a bummer for a framework that advertised as hipster-new. AFAIK they migrated out of jboss library that was holding them back in newer JDK support but I was burned twice already and didn't want to give another try.
- jxi 5y ago
  It has to be static or AOT compatible to compile to native with Graal.
- invalidname 5y ago
  I really like a lot of the ideas in Quarkus. They also pushed for Spring Native which is an interesting new direction. But to me one of the biggest values is sheer traction. Spring controls the market completely. You have so many engineers with deep real world experience with Spring. So many books, blogs etc. When you run into a problem there's someone. When you need to hire, it's easy. That's a huge benefit.
StevePerkins 5y ago
The only things those frameworks offered were compile-time dependency injection (Spring injects at runtime, and can make startup slower)... and support for building AOT native executables with GraalVM (Spring couldn't do that before because Graal has poor support for its reflection-based dependency injection). Within a few months of Micronaut and Quarkus emerging, Spring started working on the "Spring Boot Native" project. Allowing you to build AOT compiled native executables with GraalVM. That’s now fully released for production if you want it. Ironically, aside from perhaps some "serverless" applications where startup time is more important, the traditional JIT applications typically outperform AOT native executables. Especially in the kind of long-running server tasks that Java is mostly used for in the enterprise. This is mostly about marketing and appearances, because newbies see the eye-popping AOT startup times (for "Hello World" demo apps), and Spring has to keep up with those bullshit examples. But the point is that Spring DOES keep up. The Java enterprise ecosystem is at a point where occasionally something new gets introduced, but then Spring adds support for the same thing within a year or two. Since "a year or two" is a snap of the fingers in the enterprise world, there's just little incentive to migrate just because a new thing is "cooler" on Reddit. Especially when the new things have a minuscule fraction of the community, working out the bugs and producing the blog posts and StackOverflow answers that you rely on.
- sixbrx 5y ago
  Apparantly with the enterprise version of GraalVM which enables PGO, there's no longer any significant performance penalty, with GraalVM running at 97% of regular JVM throughput: https://www.infoq.com/articles/native-java-graalvm/ https://www.infoq.com/articles/native-java-graalvm/ (section "Peak performance On Par with JVM")
  - StevePerkins 5y ago
    The point is that most newbies don't understand the ramifications of JIT and AOT. And assume that AOT is dramatically BETTER performing, based on overhyped startup time benchmarks. You try to explain to people that once an application has been running for 30 seconds (or whatever), AOT will never be as good as JIT let alone better. And half the time, you just draw blank stares like the "But this goes up to eleven!" scene from "Spinal Tap". Java (and to a somewhat lesser extent .NET) exist in a totally different social bubble. Because most of the students and early stage startup workers on Reddit and HN simply don't know what they're talking about most of the time.
- Tsarbomb 5y ago
  I feel you about that startup time garbage. I did end up working on a GraalVM based Spring Boot app that was super cool as part of our business requirements were taking in user provided Python and Javascript code for execution and executing that code on incoming events, sort of like a rules engine.
- gavinray 5y ago
  I agree with your point about a year or two being nothing in Enterprise timelines But to chime in, I much prefer the Quarkus/Vert.x ecosystem if I have a choice, due to developer experience and the overall ergonomics.
jillesvangurp 5y ago
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/tree/main/kofu 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.
karmakaze 5y ago
My biggest beefs with Spring is its use of Hibernate being a solution for late 90's EJB apps not well suited for shorter transaction scopes used today. Sadly most Quarkus references seem to use Hibernate as default. Micronaut seems to be showing more choices, but then still Hibernate comes up more than others. Leaving Spring/Boot and keeping Hibernate isn't much of a change other than perhaps some possibly efficiency (e.g. startup time or infrastructure cost).

Quarkus had a really annoying static only DB layer which turned me off. Spring Data was way better with the interfaces. I don't know if Quarkus changes recently (well, in 2-3 years) in that regard. And 3 years ago it didn't support newer JDK versions, it supported up to JDK 11 AFAIR, while there was already JDK 13 or something like that. It was a bummer for a framework that advertised as hipster-new. AFAIK they migrated out of jboss library that was holding them back in newer JDK support but I was burned twice already and didn't want to give another try.

jxi 5y ago
It has to be static or AOT compatible to compile to native with Graal.
invalidname 5y ago
I really like a lot of the ideas in Quarkus. They also pushed for Spring Native which is an interesting new direction. But to me one of the biggest values is sheer traction. Spring controls the market completely. You have so many engineers with deep real world experience with Spring. So many books, blogs etc. When you run into a problem there's someone. When you need to hire, it's easy. That's a huge benefit.

StevePerkins 5y ago

The only things those frameworks offered were compile-time dependency injection (Spring injects at runtime, and can make startup slower)... and support for building AOT native executables with GraalVM (Spring couldn't do that before because Graal has poor support for its reflection-based dependency injection). Within a few months of Micronaut and Quarkus emerging, Spring started working on the "Spring Boot Native" project. Allowing you to build AOT compiled native executables with GraalVM. That’s now fully released for production if you want it. Ironically, aside from perhaps some "serverless" applications where startup time is more important, the traditional JIT applications typically outperform AOT native executables. Especially in the kind of long-running server tasks that Java is mostly used for in the enterprise. This is mostly about marketing and appearances, because newbies see the eye-popping AOT startup times (for "Hello World" demo apps), and Spring has to keep up with those bullshit examples. But the point is that Spring DOES keep up. The Java enterprise ecosystem is at a point where occasionally something new gets introduced, but then Spring adds support for the same thing within a year or two. Since "a year or two" is a snap of the fingers in the enterprise world, there's just little incentive to migrate just because a new thing is "cooler" on Reddit. Especially when the new things have a minuscule fraction of the community, working out the bugs and producing the blog posts and StackOverflow answers that you rely on.

sixbrx 5y ago
Apparantly with the enterprise version of GraalVM which enables PGO, there's no longer any significant performance penalty, with GraalVM running at 97% of regular JVM throughput: https://www.infoq.com/articles/native-java-graalvm/ https://www.infoq.com/articles/native-java-graalvm/ (section "Peak performance On Par with JVM")
- StevePerkins 5y ago
  The point is that most newbies don't understand the ramifications of JIT and AOT. And assume that AOT is dramatically BETTER performing, based on overhyped startup time benchmarks. You try to explain to people that once an application has been running for 30 seconds (or whatever), AOT will never be as good as JIT let alone better. And half the time, you just draw blank stares like the "But this goes up to eleven!" scene from "Spinal Tap". Java (and to a somewhat lesser extent .NET) exist in a totally different social bubble. Because most of the students and early stage startup workers on Reddit and HN simply don't know what they're talking about most of the time.
Tsarbomb 5y ago
I feel you about that startup time garbage. I did end up working on a GraalVM based Spring Boot app that was super cool as part of our business requirements were taking in user provided Python and Javascript code for execution and executing that code on incoming events, sort of like a rules engine.
gavinray 5y ago
I agree with your point about a year or two being nothing in Enterprise timelines But to chime in, I much prefer the Quarkus/Vert.x ecosystem if I have a choice, due to developer experience and the overall ergonomics.

jillesvangurp 5y ago

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/tree/main/kofu 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.

karmakaze 5y ago

My biggest beefs with Spring is its use of Hibernate being a solution for late 90's EJB apps not well suited for shorter transaction scopes used today. Sadly most Quarkus references seem to use Hibernate as default. Micronaut seems to be showing more choices, but then still Hibernate comes up more than others. Leaving Spring/Boot and keeping Hibernate isn't much of a change other than perhaps some possibly efficiency (e.g. startup time or infrastructure cost).