When to Use Vaadin

Business applications. Vaadin includes the UI components that the forms and workflows of business applications need, such as grids, form fields, date pickers, dialogs, and layouts. You don’t need a UI component library of your own. The UI components are designed for WCAG 2.1 level AA, and Flow views and React views use the same ones. A grid fetches only the rows that the user scrolls to from an application service, and leaves filtering and sorting to the database, as described in Add a Paginated Grid. A form validates its input in Java, as described in Form Validation. When every user logs in, the number of users has a known upper limit, so you can size the servers in advance.

No API between the UI and the services. A click listener in a Flow view calls your application services directly, in the same thread, as ordinary Java code. The application therefore has no API whose only client is its own user interface, and nothing of the kind to design, version, document, and secure. With the UI components, layouts, and default theme, a Java developer can build a complete Flow view without writing HTML, CSS, or JavaScript, and without assembling a separate frontend stack.

Access control on the server. In a Flow view, the browser displays the UI components and sends user events to the server. Business rules, validation, and access decisions run in Java on the server, where the user can’t change them. With security enabled, Flow views are denied until an annotation grants access, and Flow ignores events from UI components that are hidden or disabled. The services behind the views still need protection of their own, as described in Protect Services.

Long-term maintenance. Because Flow views are Java, the compiler and your IDE’s refactoring tools cover the UI code as well. When a change to an entity or a service breaks a view, it shows up at compile time rather than in production. Vaadin releases new versions on a published schedule, and a minor version deprecates features without removing them, so upgrading to it is usually a version bump. Licensing, Support & Maintenance describes the release and maintenance model. These properties matter most in applications that are maintained for many years.

AI coding agents. An AI coding agent that works on Flow views uses one language and one compiler from the UI to the data access. There’s no API contract between a frontend and a backend for it to keep in sync, and the compiler reports many of its mistakes before the code runs. Browserless tests run as plain JUnit tests without a browser, so the agent can run them after every change. See Agentic Development.

Java teams. A team of Java developers can build and maintain the whole application, including the user interface, without learning a JavaScript framework and its toolchain. The team doesn’t need to split into frontend and backend teams. Vaadin recommends giving the team’s skills as much weight as the type of application when you decide.

Migration from Swing and older Vaadin versions. A Flow view is a tree of UI components with listeners, written in Java, which is similar to a Swing user interface. A Swing team’s skills carry over, and so can the domain logic and services behind the old user interface. Applications built with older Vaadin versions already use the server-side model, although the API has changed since. Vaadin Version Comparison lists the differences, and the Tools section includes tools for modernizing older applications.

The following costs apply to Flow views. How a Vaadin Application Works explains each of them in detail.

Server memory per user and per tab. The server keeps the UI of every open browser tab in memory, for as long as the tab stays open. How many users a server can handle depends on its memory, and on what your views hold. See How Far It Scales.

A round trip per interaction that runs Java code. Clicks with server-side listeners, navigation between views, and loading more rows into a grid all wait for the network. On a local network, the delay is hard to notice. On a slow mobile or intercontinental connection, it adds to every such interaction. See Which Interactions Need the Server.

A dependency on the connection. While the connection is down, a Flow view can’t run any Java code, and it can’t work offline. See When the Connection Is Lost.

Stateful deployment. Load balancers need sticky sessions, so that each user’s requests reach the server that holds their UI. When a server stops — because it crashed, the cluster scaled down, or you deployed a new version — its users lose anything they hadn’t saved, unless you replicate the sessions. See What This Means for Deployment.

Less direct control over the rendered HTML. You build a Flow view from UI components in Java, not from markup. You can style the UI components, use HTML elements from Java, and wrap web components and React components of your own. You don’t write the markup of a view by hand, though.

React views avoid the first three costs, because they keep their state in the browser and contact the server only to call a service. In exchange, the application gets a TypeScript frontend, which takes different skills to build, and services that the browser can call. Vaadin generates type-safe TypeScript clients for those services, so you don’t design a REST API. The services are reachable from the browser, though, so they become the security boundary. How React Views Differ compares the two kinds of views.

A Vaadin application scales out like other Java web applications, by adding servers behind a load balancer. Unlike a stateless application, it needs planning for its state: the memory that each user costs, sticky sessions, and what happens to the sessions on a server that stops.

Memory determines how many users each server can handle. According to Vaadin Scalability, the session state of a concurrent user ranges from 50 to 1000 KB, depending on how much business data the session holds. In the example in Measure Memory per Session, a session with one tab, showing a form and a lazily loaded grid, took about 290 KB. When the grid held all of its items in memory, each tab took about four times as much. The figure for your application depends on what your views hold. To keep it small, keep large data sets out of the session, for example by using a paginated grid.

Vaadin recommends another tool, at least for part of the application, when one of the following is among its main requirements. An application can use Vaadin for the parts that users log in to, and other tools for the rest.

Large volumes of anonymous traffic. A Flow view keeps a UI in server memory for every visitor, and an open tab keeps it alive, so memory grows with the number of concurrent visitors. React views keep no UI state on the server, so they suit a public part of a business application, such as a landing page or a sign-up form. Vaadin recommends building and scaling a high-traffic public site, especially one with sudden spikes, separately from the business application.

Search engine ranking. Vaadin builds both Flow and React views in the browser with JavaScript, and doesn’t render pages to HTML on the server for search engines. A Flow view also keeps a UI on the server for every visitor, crawlers included. Keep content pages on a content management system or a static site, and link from them to the Vaadin application.

Mobile-first or offline-first use. Vaadin’s layouts adapt to the screen size in the browser. However, every interaction that runs Java code adds the latency of the mobile network, and a Flow view stops working when the connection drops. React views can keep working offline, but you write the code that stores data in the browser and synchronizes it with the server, as described in Client-Side Data Caching. If most of the application has to work offline, most of it ends up as React views, and the benefits of writing the UI in Java no longer apply.

A highly custom user interface. Vaadin is designed for applications whose views follow one consistent design. The default theme styles the UI components without any CSS of your own, and you can style them further, for example to match a brand. When a designer specifies each screen in detail, and the user interface is the product, a hand-written frontend gives more control. React views give that control within a view, and can still use Vaadin’s UI components.

Immediate response to every keystroke or pointer movement. Some views, such as a drawing canvas or a real-time editor, can’t wait for a round trip per interaction. Implement them as React views. See Choosing Flow or React Views.

A separate frontend or a public API. Some organizations want a separate frontend team with a framework of its own, or need a public API for mobile applications and partners anyway. For them, the benefits of a single team and of having no API mostly don’t apply. React views give you a React frontend with type-safe calls to Java services, but they’re part of the Vaadin application, and you build and deploy them with it. Their services serve the application’s own views. A public API for other clients is something you design separately.

The costs described on this page depend on your views, your users, and your network. Vaadin recommends measuring them rather than relying on general figures:

Before you decide how to deploy, read How a Vaadin Application Works. To see which of the features you’d use are free, read Licensing, Support & Maintenance.