The webforJ 25.x cycle covered a lot of ground: new components, a fresh design language, smarter AI tooling, and plenty of polish, and it all wrapped up with the 26.00 release. Rather than a long recap, here's a short video that walks through the highlights.

In my time working with documentation and coding for customers I have built quite the number of demo apps myself, so by now I know what the shortcuts look like. The dataset is always small, with authentication and advanced features "coming soon" or hardcoded in instead of properly implemented. Filtering works fast, because coincidentally there are only five rows to filter. All of that isn't to say those demos are bad, after all they serve their purpose, but I wanted to see how efficiently I could build a demo that doesn't cut corners while still being small and easy to understand.

The webforJ Bookstore is my attempt at that. It's a book inventory manager built on webforJ and Spring Boot with live table filtering, colored genre chips, a data-bound edit drawer, and Spring Security handling who can do what. This post covers the pieces I found most worth writing about.

webforJ 26.00 is here, our first major version since the 25.x series kicked off, and a big one. It brings a top-to-bottom design system refresh, new tricks for the Dialog and TabbedPane components, and a clean break from deprecated APIs, all paired with automated tooling that does most of the upgrade work for you. The highlights are below, and as always the GitHub release overview has the complete picture.

There's something about native mobile apps that's hard to copy on the web: things move. Tap a photo and it expands. Go back and it shrinks to where it came from. The browser's View Transition API has been closing that gap, and webforJ 25.11 brings it to Java with webforJ View Transitions.

AI tools are changing the way people work, and it's easy to get left behind. They can be very powerful, but require some configuration and practice to really unlock their potential. While you're still doing things the way you always have, your peers are excitedly talking about how their autonomous AI agents are building and testing apps, completely transforming what it means to be productive and efficient, and what it means to "code." Maybe you occasionally use an AI as a fancy search engine or research tool, but it's certainly not doing your work for you. You might find yourself wondering: what are they doing differently?

Version 25.12 of webforJ is live! This release brings two new UI components, table enhancements, a built-in translation system, and Kotlin DSL support. See some of the most exciting highlights below, and as always, see the GitHub release overview for a more comprehensive list of changes.

As AI coding tools, assistants, and agents become increasingly powerful, professional engineers and casual vibe coders alike can go from concept to compilation faster than ever before. On top of that, meta-prompting systems like get-shit-done and Auto-Claude automate entire development workflows, so that the AI doesn't just write the code, but verifies it as well.

AI tools certainly accelerate output, and are very impressive at first glance. But what impact are they having on code quality? Can the open source ecosystem withstand the flood of AI-generated PRs? How can developers use AI without sacrificing understanding and quality?

Research into these questions is still emerging, but the current findings suggest that for anything that requires security, maintainability, and performance, it's best not to put too much trust in AI-written code.

This is why we've made a strategic choice at webforJ: AI-assisted development, but human-owned code.

I've been working with webforJ for a while now, mostly on documentation and component demos. But I recently wanted to build something small from scratch to try out a feature I hadn't used yet: installable apps.

The idea is that your web app can be "installed" on a device, kind of like a native app. It gets its own icon on the home screen or in the app launcher, and when you open it, the browser UI is gone. Your app gets its own window.

I built a habit tracker called Streak to test it out. I wanted to see what it takes to make a webforJ app feel like a "real" app instead of a website, and the installable apps feature turned out to be the key piece.

Version 25.11 of webforJ is live! In this release, we've focused on polishing how users see your app, with built-in visual transitions, AI-ready components, and faster ways to prototype and learn about webforJ. See some of the most exciting highlights below, and as always, see the GitHub release overview for a more comprehensive list of changes.

If you're lucky enough to be writing a new web app from scratch, it's easy to see how webforJ could benefit you. webforJ simplifies your deployment and provides a UI framework of components that conforms to web standards and user expectations, all while you enjoy the familiar experience of coding in Java and integrating with the Java ecosystem. But what if you already have a Java desktop app, and you need to deploy it to the web? Do you have to rewrite the whole thing, or can you modernize your legacy Java code into a fully functional web app? Look no further, because webforJ has the answer: deploy your existing Java app to the web quickly with Webswing, and gradually modernize it into a true web app with webforJ.

Data is the lifeblood of business applications, and displaying it properly can make or break someone's experience using your app. In order to visualize data, most developers quickly turn to tables for displaying that data. Here's the problem: just throwing information into rows and columns doesn't always tell the story clearly enough.

When users glance at a table, the idea is that they immediately understand what matters. Is that price change good or bad? Which items need attention? What's trending up versus down? If your users have to pause and think, squint at numbers, or do mental math to understand their data, your interface isn't working hard enough for them. Perhaps your first instinct is to say that tables aren't the answer, but that isn't the case.

This is where renderers come in. In webforJ, cell renderers let you transform raw data into visual, instantly understandable information. Earlier this year, I built a mock cryptocurrency dashboard, which is a perfect example of an app that needs quick, understandable information at a glance, since crypto data is fast-moving, emotionally charged, and needs to be digested within seconds. Green numbers for gains, red for losses, formatted prices, inline charts—all rendered dynamically to tell the story your data is trying to communicate.

The fun part was using renderers to contain all of this information inside a tidy table, and in this post, we'll explore when and how to use these renderers to build tables that don't just display data, but actually communicate with your users.

webforJ version 25.10 introduces some heavy hitting new capabilities for building global, secure, and integrated applications. This release brings internationalization support, enterprise-grade security which includes Spring Security integration, Webswing compatibility for legacy Java Swing apps, and adds to our Login component.