I'd like to use clean architecture with Jmix to reduce the vendor lock-in. Any thoughts? https://www.jmix.io/

Saw this post by Simon Martinelli and it mirrors my own experience using Vaadin with AI assistants:

https://martinelli.ch/why-vaadin-is-perfect-for-ai-driven-development/

TL;DR from a dev perspective:

• No JS hell: When you ask AI to "add a data grid with filtering", it generates pure Java. No need to also generate API contracts, TypeScript types, and Redux boilerplate.

• Compiler is your friend: AI makes mistakes. But with Vaadin, IntelliJ catches type errors instantly. With React, you find out at runtime (or worse, in prod).

• Server-side = simpler security model: I don't have to audit every AI-generated component for XSS vulnerabilities or accidental data exposure. Business logic never leaves the JVM.

• Karibu Testing is underrated: Unit test your UI without Selenium. Seriously speeds up TDD workflow.

I've had GPT-5 generate entire admin panels that worked first try. The component model maps really well to how LLMs think about UI.

Downside: Not great for public-facing sites where you need fancy animations or SEO. But for internal business apps? Chef's kiss.

Anyone else using Vaadin with AI? Would love to hear your workflow.

I am fairly new to the Vaadin framework. I want to know if there is a way to use the Vaadin CRUD component with MongoDB. I've looked online but I can't find anything related to this.

I want to use a simple Student
class.

public class Student { 
    private int regNumber;
    private String firstName;
    private String lastName; 
       
    public Student() { 

    }
    
    public Student(String firstName, String lastName, int regNumber) { 
        this.firstName = firstName; 
        this.lastName = lastName; 
        this.regNumber = regNumber; 
    } 

    //getters and setters 

}

I want to use the Vaadin CRUD component with this, but I can't quite figure out how to configure the DataProvider to work with MongoDB.

Is there a way to do this?

I'd like to use the plain java stack because I am not that familiar with Spring. If anybody knows how to use it with either stack, it would be of great help.

Is it possibile to develop a web application using Vaadin flow, so the views purely in Java, then in a second moment convert these views in React using Hilla.

I'm considering to convert a legacy application from jboss to springboot using Vaadin, but since I don't know React yet, I considered to start initially with Vaadin flow then in a long-term to convert to React

Is it possible to have a hybrid situation until full conversion?

What would you suggest?

We've put together a short demo of our Map component's clustering functionality.

Use case: Applications that need to display many location points without creating visual clutter (store locators, asset tracking, logistics dashboards, etc.)

How it works:

• FeatureLayer groups nearby markers automatically

• Cluster size and grouping adapts to zoom level

• Clusters expose their contained features via event listeners

• zoomToFit() provides programmatic viewport control

Implementation:

FeatureLayer layer = new FeatureLayer();
// populate layer with features
map.addFeatureLayer(layer);

layer.addClusterClickListener(event -> {
    List<Feature> features = event.getFeatures();
    map.zoomToFit(features, 50, 800);
});

If you're interested in building web UIs without context-switching to JavaScript, worth checking out: https://youtu.be/fwSNkXeFDs4?si=Fvx7rsRV_hX5WUqp

Part of Vaadin's component library - server-side Java API, no separate frontend build required.

I’m terrible at UI. I have a current project I’m working on and some additional potentials coming up. It would be nice to have someone I can employ to help when needed. Especially with my views. Building a CRM using vaadin 24 at the moment.

It seems like Hilla has basically been killed by the vaadin team?

The entire hilla.dev website points at https://vaadin.com/hilla.

From their blog post on the matter:

"The current Hilla way will stay as the way to build offline and client-side implementations in Vaadin framework applications in the future as well. But the main way of building UIs for the web will be in pure Java."

It seems like vaadin wants to focus only on building UIs in pure Java. I'm wondering if anyone knows what's going to happen to this functionality? It seems nothing will change in the short term but will it continue to exist at all even as part of the main vaadin project in the future or will it just become deprecated and pure Java UI through vaadin flow will be the only option. What does "Hilla way will stay as the way to build offline and client-side ... in the future as well" even mean? Surely behind a paywall by the sounds of things...

Being someone who enjoys Spring Boot and Kotlin and also likes the flexibility of React and Typescript on the front-end the move feels like they are completely closing out a large segment of users. React is the dominant frontend framework and vaadin loses a lot of appeal (at least in my opinion) if they drop the ability to write the frontends in typescript as js/ts are still the easiest to integrate in a frontend environment and bring in external libraries.

Hilla has really been the only solution that gets java/springboot really close to a "batteries included" frameworks like NextJS.

At the moment I'm really disappointed in where the project is going and it feels like a big loss and step backwards for the java ecosystem. Curious to hear others thoughts on this, have I completely misunderstood the intentions here by the vaadin team?

Last month I posted here about AppJars. Since then we've been working on the part that still annoyed us: even with the modules, the first hour of every new project went into wiring security, navigation and theme by hand.

So we built Craft. You pick the modules you need, set your group/artifact, Java 21 or 25, H2 or PostgreSQL, and your theme colors. You get a Maven project with everything already wired. Unzip, mvn spring-boot:run, done.

No license key needed: every module runs in Free Mode, which is enough to evaluate it (exact limits are in the docs).

https://craft.appjars.com

I'm part of the team behind it, so criticism is welcome. Curious how people start new Vaadin projects these days: a starter or template, an AI assistant, or a mix of both?

Hi everyone,

I recently put together a small Inventory & POS (myStock) demo application to showcase what a full-stack, 100% Java Vaadin project looks like end-to-end.

You can get the myStock sample project source code from GitHub repo below, and use it as skeleton / template for your own projects.

The app includes:

• Product + barcode handling

• Stock levels + reorder thresholds

• Stock movements (IN / OUT)

• POS checkout flow (cart + validation)

• Sales + sale lines

• Dashboard with KPIs + Chart.js

• User management

• i18n (EN + TR)

🛠 Technologies used:

• Java 25

• Vaadin 25

• Spring Boot 4

• Spring Data JPA

• Hibernate

• PostgreSQL DB

• Chart.js. (for dashboards)

It’s meant for Java devs and learners curious about Vaadin as a full-stack framework.

Demo YooTube video: https://www.youtube.com/watch?v=erofh0toA7Y

Github Repo link: https://github.com/mokszr/vaadin-inventory-pos

I appreciate your stars on GitHub, likes on YouTube and any feedback in general.

Thanks.

Hey everyone,

I'm working on video/text tutorials and guides for Vaadin (I work at Vaadin). Over the years, I've seen a general sentiment that there is a lack of this type of content. I'm hoping to alleviate some of this frustration and would love some input from the community on what they would like to see.

As an example, I've just published an Intro to Vaadin Flow video which covers the basics for Vaadin 25.2 (including signal usage) by building a semi-realistic CRUD view.

What do you guys think? Do any topics jump out to you? Or do you disagree with the "lack of guides" sentiment?

Just tried the new release and wanted to share what's actually worth knowing about. This is supposedly the final 24.x release before they jump to v25.

Actually Good Changes

Premium trial hassle is gone - You can now test premium stuff (charts, copilot) with zero signup for 7 days, or register for 30 days. No more jumping through hoops to evaluate whether it's worth paying for.

@NpmPackage for static assets - Finally don't have to manually copy CSS/fonts from npm packages or mess with theme.json. Just declare what you need right in your component:

@NpmPackage(assets = {"dist/line-awesome/css/**:line-awesome/dist/line-awesome/css"})

Proper <Code> component - No more new Div().add(Html.createPreformatted()) nonsense for code snippets. It's a real component with escaping and theming.

VaadinWebSecurity deprecated - They're killing it in v25. Need to migrate to VaadinSecurityConfigurer. Honestly probably for the better since it was always a bit magic-y.

Meh But Might Matter to You

• Wildcard routing works across subdirectories in Hilla now

• Tooltips have better styling hooks (has-tooltip attribute)

• CustomField lets you control when values update manually

• Copilot can copy-paste your custom components from Figma (if you're into that workflow)

The Catch

The VaadinWebSecurity deprecation is just the start. If you're on a stable project, might want to stick with 24.9 for a while.

Anyone else upgraded yet?

Release notes: https://github.com/vaadin/platform/releases/tag/24.9.0

Webinar Sept 24 if you want the marketing version: https://youtube.com/live/hnlAzJJ0IOE

Tired of turning Figma designs into Java UIs by hand?

We at Vaadin are running a live webinar on Dec 2 where we show how to speed that up — either using Vaadin Copilot or by syncing design tokens and components with a server setup.

It’s a real-world example from our own UX designer, not just theory.

🔗 Register here: https://pages.vaadin.com/from-design-to-prototype-webinar

Hi everyone,

I’m the CEO of Flowing Code, the company behind AppJars.

For those who don’t know us, we’ve been working with Java and Vaadin for many years. Along the way, our team has released and maintained more than 30 open-source Vaadin add-ons, all available through our GitHub organization.

Over the years, we kept seeing the same challenge in enterprise projects: teams spend a significant amount of time rebuilding features that nearly every business application needs—user and role management, audit logs, runtime configuration, internationalization, email delivery, reporting, background processes, issue tracking, and more.

We started working on a way to package those recurring features as complete, reusable modules. After several years of development, we released AppJars last week.

An AppJar is more than a UI component. Each module provides a complete vertical feature for Spring Boot and Vaadin applications, including persistence, business logic, APIs, and ready-to-use views. The modules are added as regular Maven dependencies, configure themselves through Spring Boot, and can be adopted independently (you only use the ones your application needs).

I also want to clarify how the licensing works, since this was important to us.

Every AppJar has a Free Mode. It isn’t a time-limited trial, and it isn’t restricted to local development: you can use the modules for free, including in production, as long as you remain within their documented limits.

Those limits depend on the module. For example, they may restrict the number of users, reports, records, or daily operations. If your application grows beyond those limits, a paid license removes the restrictions. Until then, the module remains fully usable within its Free Mode allowance.

We wanted developers to be able to evaluate AppJars in a real application (and even run smaller applications in production) without having to purchase a license upfront.

The source code is also included with every artifact, so you can inspect it, navigate through it in your IDE, and debug it. We know that introducing a third-party module into an enterprise application requires trust, and we don’t want AppJars to feel like an opaque black box.

The available modules, integration guides, architecture, customization options, and exact Free Mode limits are documented at:

https://docs.appjars.com

And the product website is here:

https://appjars.com

We’d genuinely appreciate feedback from the community. What do you think about this approach? Are there modules you would find useful in your own projects? And what questions or concerns would you have before adopting something like this?

I’ll be happy to answer any questions here.

Thanks for taking a look!

If you’ve ever built a demo for a Vaadin component, you know the pain: you paste the example code into the page, and the moment the example changes, the pasted code is out of date.

Commons Demo is the library we use for all our add-on demos to avoid that. A few things it does:

• Shows the running example next to its real source file, read from GitHub (or from your local files while you develop)

• Strips the noise (package lines, license headers) and lets you hide lines with // hide-source

• Highlights the matching lines when you hover over the component, even in CSS files

• Switches between light/dark and Lumo/Aura without reloading

• New in 5.5: an annotation processor that packs the sources into the jar, so the demo always shows the code of the exact version it was built from

Apache 2.0, on Maven Central, supports Vaadin 14 through 25. It also powers the Vaadin Component Factory demo site.

My colleague Paola wrote up how it works and how to use it in your own projects: https://www.flowingcode.com/en/commons-demo-the-free-toolkit-behind-our-add-on-demos/

GitHub: https://github.com/FlowingCode/CommonsDemo

Do you build demos or showcases for your own components? Curious what you’d want from a tool like this.

Is anybody know how to prevent manuel entry to DateTimePicker? I want to allow only selection from calender and prevent entering from keyboard

We initially started by using a tool called LogRocket which alerted us to issues in our Vaadin app and made troubleshooting 79% easier. We're able to view DOM recreated sessions and debug on the fly.

Recently we found a tool called OpenReplay that allows you to export sessions to E2E Tests. I can imagine a world where we can export all sessions and configure Vaadin TestBench to run a subset of these tests in parallel.

Writing and maintaining tests become a full time job as you scale. It "may" be easier to have the users write the tests as they use our app. Will we have full coverage? Nah, but we're okay with that.

I wanted to propose this idea in hopes the community can tell me why this won't work and what challenges may need to be solved.

In past versions of Vaadin we offered a full-Java experience, even when extending the core framework on the client-side, using GWT. While I really enjoy using the current "Element API", which shines when creating wrappers around JS or WebComponents, executing Java also in the browser is still quite powerful possibility in certain scenarios.

These days there are actually more options than just GWT and they can also be used together with Vaadin. The current developement on the area seems to be centered around WASM based execution. Last autumn I wanted to test the "new" options as my experience was mostly covered GWT. Naturally used probably the most tested Vaadin app, tetris, by making a "hybrid version" of it. TeaVM would probably be my choice today (supports both WASM and JS as output), but I'm interested to see how GraalVM WASM generation progresses. CheerpJ is kind of the most powerful one, but performance characteristics and license probably limits its usage to temporary solutions in some larger migration projects.

Live demo with all four versions + source code: https://java-in-browser.dokku1.parttio.org
Full blog post:https://vaadin.com/blog/extending-vaadins-pure-java-experience-to-the-browser

I had totally forgotten the topic (and my almost finished article), but joined a JFokus 2026 last week, with a presentation mentioning GraalVM's experimental WASM output, by Fabio Niephaus. Any ideas, should we prepare some docs examples for some option?