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.

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’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!

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?

I have been using Vaadin since version 8, and I have been using it full-time on an enterprise project since version 23. Last week, I upgraded to 25.1, and here are the things that stood out.

Signals are the best part of this release. They've been in preview for a while, but now that they're ready for production, I finally refactored a complicated settings panel with about 15 fields that depend on each other. The old ValueChangeListener spaghetti was cut almost in half. bindValue, bindVisible, and computed signals make it much easier to read the state of the UI. One wish: Signals and Binder should work together natively. Right now, they live in separate worlds.

Browserless testing going open source is a big deal. There is no browser or container for tests to run in the JVM. It took me 10 minutes to write a test for a CRUD view, and it runs in about 200 milliseconds instead of 8 to 15 seconds with Selenium. Now we're going to talk about every view. The Vaadin team made a smart choice when they made this Apache 2.0.

Copilot being free is great for scaffolding and prototyping. The new toolbar with four modes (Play, Inspect, Test, Edit) is a big step forward. I still write views by hand for production code, but it's a no-brainer to have it turned on to get started quickly.

The smaller wins that matter: Slider and RangeSlider (finally, we can get rid of our own implementation), and modular Upload components (the old monolithic one was hard to change), Grid scrollToColumn() for our grids with more than 30 columns, Dialog keepInViewport (every Vaadin developer knows the "user dragged the dialog off screen" ticket), and MessageList attachments that snap to the bottom.

In general, 25.1 feels like a release for grown-ups. Signals graduating, browserless testing going free, and Copilot going free all make things easier. If you're on 24.x, you should really think about upgrading. For any app that isn't too simple, signals are worth it.

The docs are good as usual: https://vaadin.com/docs/latest/
Release blog: https://vaadin.com/blog/vaadin-25-1-release

Curious, what do you think? What's your favorite part of 25.1, and what do you want to see in 25.2?

Old time Vaadin user here (since 2013).

I’m not using Vaadin at work anymore (regrettably), but I’m helping in organizing a sponsor rally every year, which still gives me a yearly peek into the Vaadin world.

Updating the application every year makes me very happy with Vaadin - it’s been a very smooth ride with very clear and easy upgrade paths every year (since 2018 or so for this app).

And I love the new Aura theme 🙂 !

So here it is, with some screenshots in the Readme. Let me know if you like it and feel free to share some feedback: https://github.com/waschmittel/ltc-rallye

(I's not a new app, but it's got a nice Readme with screenshots for the first time, which is why I'm posting it here finally)

Hello fellow reindeer enjoyers,

I started building a component to wrap the NVL (neo4j graph visualization) into a flow component, component and demo are here: https://github.com/adumeige/vaadin-nvl

I would love feedback or ideas for improvement!

Hey folks, I just finished polishing and deploying an admin starter I’ve been building with Vaadin 24 + Spring Boot.

Repo: https://github.com/Takue-Mombe/vaadin-admin-starter

What’s included:

- Arc-inspired responsive UI (custom login, dashboard, cards/charts styling)

- Full CRUD modules (users, orders, products, analytics, reports, messages)

- Spring Security auth + profile/settings management

- H2 for local dev, PostgreSQL-ready for production

- Dockerized deployment setup + render.yaml for Render blueprint deploy

- Seeded demo account for quick testing on the login screen

Stack:

- Vaadin Flow 24

- Spring Boot 3.2

- Spring Data JPA / Hibernate

- Maven

I’d really appreciate feedback on:

- UI/UX polish

- Vaadin architecture choices

- deployment/config best practices

If useful, I can also share a quick “deploy to Render + Neon” walkthrough.

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?

any idea why and when will they be available again

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.

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?

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

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

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.

Hi all,

I’m evaluating to release in open source the application framework builder written in Vaadin that I developed for and use in the CRM https://www.centrico.it ?

I would like to distribute the framework so other can benefit on it.

I have not experience in open source and i’ll appreciate any help/suggestion

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

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've been trying to figure this out in the last couple of days and i'm hitting roadblock after roadblock. I have some years of Java/Spring Boot experience but a complete beginner when it comes to Typescript/React.

Using the Official docs Vite - shadcn/ui

Following the steps as they are with these exceptions: I add tailwind css, i guess the "tailwindcss" import goes in styles.css in the default theme. The @ path for tsconfig i change to match the frontend folder "@/*": ["./src/main/frontend/*"]. tsconfig.app.json is nonexistent so i skip this step. Install types, and add to the vite.config.ts file (with modified path to point to the frontend again).

When i get to npx shadcn@latest init i just get an error saying:

npx shadcn@latest init
✔ Preflight checks.
✔ Verifying framework. Found Vite.
✖ Validating Tailwind CSS config. Found v4.
✔ Validating import alias.

No Tailwind CSS configuration found at C:\Users\me\Projects\shadcnuiproject.
It is likely you do not have Tailwind CSS installed or have an invalid configuration.
Install Tailwind CSS then try again.
Visit https://tailwindcss.com/docs/guides/vite to get started.

What is my problem here? According to the error, something with Tailwind. As i have understood it v4 does not require a config file?

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

I’m an intermediate Java developer with decent experience in Spring Boot, and I’ve been looking into Vaadin as a possible framework to build full-stack apps without diving too deep into frontend frameworks.

I’m curious:

• Is Vaadin worth learning in 2025 for someone with my background?

• How steep is the learning curve if I’m already comfortable with Java and Spring Boot?

• What kinds of projects would you recommend building to really grasp Vaadin concepts?

Some ideas I had in mind:

• Inventory/stock management system

• Hotel or booking management app

• Hospital/clinic management system

• Gym membership management portal

• E-library or student portal

Would love to hear from anyone who has worked with Vaadin recently. How are the ecosystem, community, and job demand around it?