Vaadin Flow vs Hilla: Which framework should you choose?

So, you’ve heard of Vaadin Flow and Hilla? The two open source web frameworks that are both part of Vaadin platform since V24.4. Both frameworks let you build modern web UIs with a rich component library, routing, and a Java backend. You might be wondering how they are different and why we have two frameworks in the first place.

I’ve built applications with both Vaadin Flow and Hilla and what I can say is that while they share a lot of DNA, the developer experience between them is very different. But here’s the thing: neither is strictly “better.”

That’s what this post is about: understanding the differences and helping you pick the approach that fits your skills, team, and goals. 

What to consider when choosing Flow vs. Hilla

Both Vaadin Flow and Hilla are full-stack frameworks—but they solve the full stack in opposite directions.

• Vaadin Flow is server-driven. You write UI logic in Java. The framework handles client-server communication for you, so you don’t need to build REST endpoints or manage a separate frontend project.
• Vaadin Hilla is client-driven. You write UIs in TypeScript using Lit and Vaadin components. The backend is still Java, but your APIs are exposed as type-safe endpoints that the client consumes directly.

The good news is that you cannot go wrong. You can build the same application with both of them, you can solve everything and make it work for you. A lot of the differences boil down to preferences or “what you think you like to do”. And that makes it harder. Which one should you pick then?

Quick comparison: When to choose Flow vs Hilla

Here’s a quick guide to find your end of the rainbow with less work:

And what about the last row here? Well, from a practical point of view, neither Vaadin Flow nor Hilla is server-side rendered; both are SPAs (Single Page Applications). Though top modern crawlers can understand the content, it is optimized for user experience (UX) rather than search engine optimization (SEO). While not always a concern for business web applications, as opposed to websites, metadata can be added separately.

Architectural considerations between Vaadin Flow and Hilla

Vaadin Flow and Hilla mainly differ in communication models and state management. Flow uses server-side communication: the server manages UI state, sending minimal updates to the client. This offers simplified development for Java-proficient teams, automatic data binding, and enhanced security, but can pose scalability challenges due to stateful servers. Hilla employs client-side communication (REST/RPC): the client manages UI logic and state, explicitly requesting data from a stateless server. This provides client-side flexibility, easier backend scalability:

• Flow: Handles all UI states on the server. User actions trigger Java code on the backend. You don’t write APIs.
• Hilla: You explicitly expose server-side services via endpoints. The client (TypeScript) calls these synchronously/asynchronously.

While this sounds profoundly different, the practical runtime implications are not again that huge. In real life what I have noticed:

1. Hilla requests still benefit from session cache on the server. i.e. server state.
2. Flow can push implementation of a component state to the client making it less server heavy.
3. Both effectively have the “single user” perspective or mindset when programming. 
4. Flow implicitly uses "single user caching" for server-side data, whereas Hilla is "shared cache." However, a combination of both is typically required.
5. Both are for SPAs (Single-Page Applications), where the development centers around "view changes" rather than traditional "pages"

Currently reactive UI state management is easier in Hilla, but that should change when we get signals to Vaadin Flow. 

As a generalization: Choose Flow for rapid development with Java expertise and less client-side customization and dynamic generated UI. Choose Hilla for rich designed and interactive UIs, when client-side optimization is important. 

Your daily dose of debugging 

One aspect I want to discuss is developer ergonomics. Bugs happen and the question is how painful are they to track down? This is typically very time consuming.

In Vaadin Flow, everything runs on the server. That means you can debug the entire UI lifecycle directly in your Java IDE, set JVM breakpoints, inspect beans, and see the stack trace in familiar territory. You don’t need to figure out where the frontend ends and backend begins as it’s all one codebase. Debugging with Flow is simpler when everything stays on the JVM.

On the other hand in Vaadin Hilla, the split is clean. Client-side issues live in the browser. Server-side issues you use JVM debug tools and client-side you use the browser devtools. You typically use browser breakpoints to inspect the network payloads and JVM breakpoints on the server. Thanks to the generated TypeScript types, you’re less likely to run into “undefined is not a function” surprises.

Hot deployment and live reload

Another aspect of developer ergonomics is the code-deploy-test cycle. Especially with UI development, you need to see the results quickly. No big differences here, but this is where the Vaadin platform tooling really shines for full stack development.  

You can just edit the code and see the changes deployed immediately. Both Vaadin and Hilla views work very similarly and use similar tooling. On the JVM side the Vaadin uses HotSwapAgent and for frontend code Vite in development mode. These are automatically configured when you use the Vaadin Copilot and Vaadin IDE plugins. 

In a nutshell

Final thoughts

I’m still a Java guy. I like working with Vaadin Flow and in JVM for predictability, and Java code for maintainable architecture and building client-server components for future proofing. However, since the introduction of React integration in Hilla opened a new component ecosystem and made simple one-view and single-component prototypes so easy that I like to do more UX related work that way. 

The DX for daily work is always the most important factor to me. What matters most is how well you use the tool. At the end of the day, choosing between Flow and Hilla isn’t about which one is better. It’s about which one fits your context.

I hope this was useful. Ultimately, I believe that the most effective way to see what works best for you is just to get your hands dirty and try out yourself. Godspeed!