It’s no secret: the soon-to-be-released Vaadin 25 doesn’t ship a huge amount of new features. We’ll return to that in upcoming minor releases. But alongside achieving compatibility with things like Spring Boot 4 and Jakarta EE 11, we’ve put Vaadin 25 on a diet. It’s smaller, more modular, and faster.
Less dependencies means smaller artifacts. Fewer dependencies means fewer CVE headaches. Fewer dependencies means faster applications. And fewer dependencies means lower memory footprint. Software libraries enable us to build better apps faster and modern tooling makes them effortless to use. But in a framework, every dependency must be well-justified. Some of our older justifications have become weaker over time.
As you may have noticed, Vaadin 25 now requires a modern JDK 21, with 25 being the latest LTS and our recommendation. We know some users will still be stuck on Java 17 (or even older), but we felt it was finally time to rip off the band-aid.
The updated JDK provides several improvements that allow us to replace previously bundled libraries with core JDK features.
In line with our renewed focus on Java developers, we’ve also improved Vaadin’s modularization so that Hilla and its dependencies are now pulled in only when needed. Combined with similar slimming-down efforts in Spring Boot 4, the results are surprisingly visible.
I ran a few tests using a basic Spring Boot–based Vaadin application, built with 25.0.0-beta9 and Spring Boot 4.0.0 (vs 24.9.6 and 3.5.6). I inspected artifact size, embedded dependencies, deployment time and development server startup time. Even though I had my hands dirty helping in the cleanup process, I was still positively surprised by the numbers.
A simple production-bundled Vaadin app now has 30% fewer transitive dependencies by default. In terms of artifact size, that’s a 22 MB reduction (from 55 MB down to 33 MB). Deploying the app to a low-end Raspberry Pi Zero 2 server (which I often use for hardcore scalability testing) is about 27% faster than with V24.9 measured by uploading the JAR over Wi-Fi and starting the Spring Boot app. I didn’t check the server’s memory consumption yet, but I’d expect the baseline footprint to be at least a bit smaller.
There’s also a noticeable win even if you don’t particularly care about server resources or deployment times (and with 2025’s server prices and CI pipelines, many of us don’t). The development-mode server on my workstation now starts over 50% faster (1.506 seconds), down from more than 3 seconds. That’s a real DX improvement, even if you already have a well-tuned live-reload setup.
As mentioned earlier, there are benefits beyond performance when removing unnecessary transitive dependencies. I compared the dependency trees of a simple Spring Boot + Vaadin app with earlier versions, and the difference looks pretty impressive.
I love utilizing libraries using modern dependency management systems, but only if they are in good use. Otherwise, less is more.