Spring is still the default Java framework for most enterprise teams, but the gap is narrowing. In a roundup published by bol.com's tech blog, 25 developers and five tech leads weighed in on which Java frameworks are hyped, which are actually delivering in production, and which they have quietly walked away from. Spring came out on top, with Quarkus and Ktor flagged as the alternatives worth watching.
For backend teams running Java workloads on Kubernetes or serverless platforms, the conversation is no longer about whether to leave Spring, but about when the trade-offs start to make sense.
Why Spring still wins the room
Spring is, as bol.com puts it, "probably the most popular" of the bunch, and the numbers back that up. It ranked sixth most loved framework in the Stack Overflow 2020 developer survey. Most Java engineers have touched it, most job ads mention it, and most internal frameworks at large companies sit on top of it.
Within Spring itself, three sub-projects do most of the heavy lifting:
- Spring Boot** strips away the configuration pain of classic Spring and ships sensible defaults out of the box, including starter dependencies and an embedded web server.
- Spring Cloud** bundles patterns for distributed systems: configuration management, service discovery, circuit breakers, and modules for GCP services, Pub/Sub, BigQuery and Cloud SQL.
- Spring Integration** adds lightweight messaging inside and between Spring apps, including channel adapters and publish-subscribe patterns for loosely coupled services.
That ecosystem is hard to leave. Bol.com itself runs an internal framework layered on Spring Boot, which raises switching costs for its own teams.
Where Spring starts to hurt
Spring was designed when Java applications ran on big servers for years at a time. That assumption shows up in two places bol.com's engineers flagged: startup time and memory footprint. For long-lived monoliths, it barely registers. For containers that spin up and down frequently, or for serverless functions billed by the millisecond, it becomes a real constraint.
Quarkus** is built for exactly that case. It is an open-source stack tailored for GraalVM and HotSpot, designed for fast boot times and low memory use. Reviewers noted better memory consumption, smoother garbage collection and higher request throughput than Spring in containerised workloads. The trade-off is thinner documentation and a smaller community.
Ktor** plays a different game. It is a lightweight, asynchronous framework built in Kotlin, aimed at connected systems and microservices where non-blocking I/O matters more than the Spring ecosystem does. It operates roughly 60% faster than Spring in raw benchmarks and uses about half the memory, though those numbers shift depending on workload.
Our analysis
For most teams reading this, the honest answer is still Spring Boot. It is boring in the best sense: it works, you can hire for it, and the migration cost is high. The case for Quarkus only gets interesting once you are running serious Kubernetes workloads, paying real money for idle JVM memory, or chasing cold-start budgets on serverless. The case for Ktor only gets interesting once Kotlin is already your default and your services are small and async-heavy.
Who wins if alternatives keep gaining traction? Platform teams under cost pressure, and shops already standardised on GraalVM native images. Who faces friction? Anyone who has built deep internal tooling on Spring's bean lifecycle, because compile-time dependency models are a different mental model, not just a different config file.
The bigger signal here is that "Java" no longer means one thing at runtime. JVM, native image, Kotlin, serverless—each combination now has a tuned framework. Pick by workload, not by habit.
Decision checklist: Spring vs Quarkus vs Ktor
| Check this first | Then prefer |
|---|---|
| Existing Spring codebase, large team | Spring Boot |
| Kotlin already in use, async services | Ktor |
| Container cost or cold start is a measured problem | Quarkus |
| Need Spring Cloud or Spring Integration | Spring |
| New microservice, no legacy constraints | Ktor |
| GraalVM native image on the roadmap | Quarkus |
One-service rule:** Do not migrate the whole fleet on a hunch. Profile one representative service, measure the actual problem, then decide. Document the rule that comes out of it.
What to watch next
Watch three things. First, Quarkus's extensions catalogue and community depth, since that is still its main weak spot. Second, Spring's own native image support through Spring Boot 3 and GraalVM, which is closing the performance gap from the other direction. Third, whether Ktor adoption inside Kotlin shops stays a niche or starts bleeding into JVM-first teams.
Bottom line: switch on a measured cost or latency problem, not on hype. One service as the canary.
Key takeaways
- Spring is still the safe default for most Java teams, especially inside large enterprises.
- Spring Boot, Spring Cloud and Spring Integration cover most typical backend needs.
- Quarkus is worth a serious look if container cost or cold start is a real, measured problem.
- Ktor makes sense mainly for new Kotlin microservices with async I/O requirements.
- Migrate one service first, write down the rule, then decide whether the rest of the fleet follows.
Frequently asked questions
Is Spring still the best Java framework in 2025?
For most teams, yes. Spring Boot remains the default, and Spring Cloud and Spring Integration cover most distributed-systems needs. Alternatives only pay off when you have a specific cost or latency problem to solve.
What does Quarkus actually do better than Spring?
Quarkus is tuned for containers and GraalVM native images, with faster startup, lower memory use and smoother behaviour under autoscaling. The trade-off is a smaller community and fewer extensions than Spring.
When should a team pick Ktor over Spring?
When the service is being written in Kotlin, the workload is asynchronous, and you do not need the full Spring ecosystem. For anything that depends on Spring Cloud or Spring Integration, stay on Spring.
Do we need to rewrite everything to leave Spring?
No. Most teams migrate one cost-sensitive service first, measure it for a quarter, then decide whether to expand the move.
Where can I read the original ranking?
The framework breakdown was published on the bol.com tech lab blog as part of a six-part series on hyped, happening and retired technologies.