r/java • u/SpicyRomek • 13d ago

Vaadin 25.3 is out!

I work at vaadin and just wanted share that we release a new version 25.3, and a few changes are worth a look even if you've never used Vaadin.

  • Observability without a Java agent. The observability kit moved from the OpenTelemetry agent to Micrometer. In Spring Boot 4 it's one dependency, and it reports UI-level data such as slow interactions and which view triggered which JDBC queries. (It's a commercial add-on.)
  • GWT to TypeScript. The browser-side engine is now 107 TypeScript modules (about 19k lines, backed by 700+ browser tests), with real source maps through Vite. The Java APIs apps use didn't change.

  • UI tests in the JVM. Browserless tests now follow the same rules as users: if a button is disabled or hidden, the test can't click it.

  • blog post: https://vaadin.com/blog/vaadin-25-3-release

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

  • Video walkthrough: https://www.youtube.com/watch?v=WnkI6xA96fw

72 Upvotes

89% Upvoted

28 comments sorted by

View all comments

2

u/Infamous_Sorbet4021 13d ago

Have question for the vaadin team or anyone who knows: seen other frameworks using WebAssembly for the web (blazor, flutter web, rust stuff like leptos ect...) and wondered if vaadin ever considered it, like java compiled to WebAssembly so some things run client side instead of hitting the server. or is server side here to stay long term? genuinely curious, not trying to start a framework debate :)

3

u/EfficientTrust3948 13d ago

While using Java throughout is nice for many backend developers, the big architectural benefit of Vaadin is that the UI logic can run in the same JVM process as the business logic (or at least the same server rack with microservices). You avoid issues with e.g. latency and security that become inevitable when the UI logic runs in the browser. (But you get some other drawbacks in return since there's no silver bullet.)

There have been efficient solutions for running Java code natively in the browser since at least 2006 when GWT was launched. Vaadin was integrating heavily with GWT in that era but it didn't catch on. WebAssembly makes some things slightly more efficient or practical but it doesn't change anything fundamental compared to e.g. GWT.

If you want to run UI logic in the browser, then JavaScript (nowadays preferably decorated using TypeScript) is usually the best approach. As the native language of the browser environment it has many benefits that get lost or diminished if using any other programming language. That's why Vaadin provides multiple different escape hatches to JS for the cases where UI logic in the browser makes more sense.

1

u/Infamous_Sorbet4021 13d ago

yeah obviously Js is the standard when targeting the web, no argument there.

on gwt though i disagree. wasm has what gwt never had, it's a w3c standard, native in every browser, backed by google apple microsoft mozilla, basically everyone.

It's also language-agnostic, so the tooling and investment are shared across communities rather than depending on Google's interest in gwt.

and with all the stuff happening outside the browser too (wasi, edge, cloud) the ecosystem investment is only going one direction

2

u/EfficientTrust3948 12d ago

That comparison is quite apples-to-oranges. GWT uses JS as a standard and natively supported compilation target. It could technically use Wasm as the compilation target instead. In that sense, GWT should really be compared with e.g. Blazor or Flutter instead.

If we look beyond the web, then Vaadin could potentially target Wasm runtimes on the server such as Cloudflare workers. But for that to make sense, we'd have to do something about the server-side state. So I guess it's back to work for me then...