The in-browser H2 database is very cool, thanks for sharing. I'm a regular user of H2, but have only used it server-side so far.

How much trouble was it to get working? Not sure how doppio handles the absence of raw TCP connections and a standard filesystem in the browser, but if it works in doppio I would think it could work in TeaVM too.

True, but are people turning off ECMAScript/WASM in their browsers to avoid this? As an app developer, I want to know if my app will keep running. In the Java Applet days, at some point the security scares became frequent enough to cause articles like "Turn off Java except on websites where you are actively using it". Once your users have to find and toggle a setting to make your app work, your audience size drops significantly.

I don't see such fears around ECMAScript/WASM. Since the dominant players have a vested interest in users feeling safe leaving those technologies turned on for all websites, they'll keep investing to maintain that safety (and the marketing of that safety).

This is a massive insurance policy for building a TeaVM app -- the foundational web technologies it builds on are receiving incredible investments from industry heavyweights. It's not just security that is maintained, new Web APIs are regularly developed too. Want to use USB from your web app? No need to wait for Oracle to roll out a Java API for it -- browser vendors have made a new API and you can call it from you TeaVM app right away.

Good luck turning those things off in modern Web, unless you plan to have a custom browser.

To me, this is one of the many ingenious things about TeaVM's architecture. By using the preferred code execution mechanisms of browser vendors (WASM and ECMAScript, plus Web APIs) to deliver Java code, it ensures they can't block or shut down this delivery mechanism. They would have to cut off their noses to spite their faces.

Furthermore, since the browser vendors never want browser code to have public security issues, they work hard to find and fix problems in their sandboxes and runtimes. This of course benefits TeaVM apps as well, since they play in those same sandboxes, and gives them a level playing field with other web apps in perpetuity.

Plugin-based applets were only safe as long as Sun had clout and the browser vendors were investing less in security than the Java team.

Really? What stops someone from dropping WASM support?

True, WASM adoption is still low and could feasibly be removed, but TeaVM lets you target both JavaScript and WASM GC backends, so you are future proofed either way.

Vaadin has a restrictive, commercial license.

By contrast, TeaVM is Apache-licensed, available for commercial use without any gotchas, limits, or entanglements.

Here are over a dozen TeaVM-based projects, for inspiration: https://www.frequal.com/TeaVM/TeaVmBasedSites.html

Several use cases where TeaVM shines:

* A developer or team has strong Java skills and wants to develop single-page apps

* A Java desktop project wants to move to the web and has lots of validation logic they don't want to double-maintain in Java and ECMAScript/WASM

* A Java-based game developer wants to make a Canvas-based version of their game for the web (potentially full-screen)

* A Java developer wants a batteries-included framework for web development. TeaVM comes with a minifier, tree-shaker, packager, and more, out of the box, with familiar 'mvn clean install' semantics (And Gradle support too).

For more details on use cases and reasons for picking TeaVM, read chapter 1 of my book here: https://frequal.com/Flavour/book.html

The new release of TeaVM (0.11.0) now supports WebAssembly GC. This increases performance while further decoupling TeaVM apps from ECMAScript.

TeaVM ( https://teavm.org/ ) is an Apache-licensed project, free for use in commercial projects. It is mature and used widely, including in frameworks like Flavour ( https://frequal.com/Flavour/book.html ) and more projects listed here: https://www.frequal.com/TeaVM/TeaVmBasedSites.html

TeaVM compiles Java code to run in the browser, efficiently and quickly. It features short build times, small downloadable files, and a batteries-included toolset (including minification, tree-shaking, and packaging). Previous releases have conquered all similar open-source tools (that support threading) in independent testing: https://renato.athaydes.com/posts/comparing-jvm-alternatives...

whats the status of swing? can we port old applets easily? multi-threading or am i dreaming?

I think Swing is a non-goal of this project. It provides good interop with the DOM and core JS methods, and it makes it easy to create your own interop for JS apis that aren't in the core.

There are at least two GUI toolkits that run on TeaVM: 1. Codename One. Similar to swing, but focused on mobile https://www.codenameone.com 2. SnapKit. Targeted at desktop. Also a light-weight toolkit, like Swing. https://github.com/reportmill/SnapKit

> I think Swing is a non-goal of this project.

It could work though by drawing to canvas.

That's what Avalonia does in C#: https://avaloniaui.net/

Here's a clone of Visual Basic 6 written with Avalonia and compiled to WebAssembly:

https://bandysc.github.io/AvaloniaVisualBasic6/

https://github.com/BAndysc/AvaloniaVisualBasic6

No Swing support at present. There is an issue filed, but it is in need of an implementer: https://github.com/konsoletyper/teavm/issues/406

I made a general guide for migrating from Swing to TeaVM here: https://frequal.com/TeaVM/migration/MigratingFromSwingToTeaV...

For a more specific example, I ported an open-source Java applet and described the process here: https://frequal.com/java/RestoringA19YearOldGameWithTeaVm.ht...

If that's your goal, you should look at CheerpJ, which supports Swing and has the goal of making it so you can easily port applets and other existing apps to the web.

I think TeaVM is more focused on letting you share code with the web instead of porting entire apps.

You can use Codename One whose web port is based on TeaVM. The API is very much like Swing. Albeit more focused on mobile.

+1 for for Codename One. It is the only tool I use when I need a mobile-only app. I have built numerous apps using Codename One, and have released 2 of them in app stores. Great Swing-like API, great examples, great documentation.

If Java is your cup of tea, you might want to try Flavour. I did and now it's the only frontend framework I use. https://flavour.sourceforge.io/

It lets you write your frontend and backend code in the same language, even sharing models and validation logic so refactorings work full stack.

You get strong typing and a rich SPA framework that includes routing, templates, and easy server calls.

There's a book ( https://frequal.com/Flavour/book.html ) and a Java SwingSet-like app with live demos and source code called Tea Sampler ( https://frequal.com/tea-sampler/ ).

How do you think it compares to Vaadin?

It's great to see continuing innovation in the Java space!

One tool I've been using to speed up maven is mvnd, the maven daemon. It's a drop in replacement for mvn with impressive speedups.

https://github.com/apache/maven-mvnd

I'm not sure I like the daemon approach. But the cache extension provided me fantastic gains: https://github.com/apache/maven-build-cache-extension

Mill uses the same daemon design as Gradle and mvnd. You do hit edge cases occasionally, but overall it works great

If you prefer your full-stack development in Java, definitely check out Flavour. It gives you the benefits this article claims to want but without the weakly-typed languages and all of their attendant footguns:

Flavour book: https://frequal.com/Flavour/book.html

Congratulations! In case people are looking for other modern Java books, here's one I'm working for building modern web apps in Java:

https://frequal.com/Flavour/book.html

It describes how to make single-page apps in Java, using the Flavour framework. No plugins, no extensions, and 99.9% pure Java. Plenty of sample code and links to relevant podcast episodes and demos.

Ok, I'll bite: why Subversion in 2024? https://sourceforge.net/p/flavour/trunk/HEAD/tree/

> TeaVMFan

Ah, that explains a lot of the questions I had about "modern webapps in Java." Relevant: https://news.ycombinator.com/item?id=25978053 (TeaVM: Build Fast, Modern Web Apps in Java; Jan 2021)

Although I would, sincerely, enjoy hearing what KotlinJS doesn't do that made you want to roll your own framework?

Flavour supports multiple JVM languages. Plus it is a batteries-included framework, no need to look to extensions to get routing, templates, EL, JAX-RS support, and more.