A lot of what I understand about webforJ, I picked up by building things while writing the documentation. Explaining a feature is one thing. Building something small that actually uses it is where I find out whether I really understood what I was about to explain to everyone else.

That's how it went with custom events. I was writing the events documentation, reached the section on a component firing its own event, and wanted to build one myself before I explained it. I try to build around real scenarios, an actual form, an actual list, something close to what you'd ship, and building it confirmed what the pattern is actually good for: one component announcing and another reacting, all in plain Java without touching JavaScript.

A little while after moving back to the US from working in Germany I was tasked with a colleague of mine to learn some Spring. Bryan and I were in the exact same boat of being totally new to anything more than Java basics, and one of the first tasks we bumped into together was this: take a form on the screen, and wire it up to a Java object that had, of all things, another Java object nested inside of it.

Sounds simple, and it no doubt is to those who are used to Spring and how it works. For us, it was not.

We were told to work with our colleague in Bulgaria to get help, and while he was certainly a Spring expert, the time different meant that we ended up spending days on it. We wrote getter chains, we wrote wrapper DTOs, and we eventually got something working that neither of us really understood. Of course, these days I'd just ask Claude, but he and I hadn't yet been acquainted back then.

If you'd asked me at the time what the "right" way to bind a nested object was, I would have been painfully clueless.

Fast forward to now, and webforJ has this feature baked right in. Past Matthew and past Bryan would have been genuinely thrilled.

webforJ 26.01 is live! The headline is a new frontend bundler: a Bun-powered build step wired into the Maven and Gradle build you already run, letting a Java view pull in npm packages and web components without a separate frontend project or a Node toolchain. Alongside it, this release reworks live reload, adds a new Upload component, brings browser APIs for geolocation, page visibility, and app icon badges, and gives AppNav pinning and search. See the highlights below, and as always, the GitHub release overview has the complete picture.

Recently, I was browsing articles on CSS Tricks and came across Reading Position Indicator by Pankaj Parashar. I've seen this type of indicator in articles, blogs, and in lengthy terms and conditions that I've definitely read through thoroughly. I wanted to try recreating a reading position indicator using webforJ, and see if I could build it in less than 100 lines of code.

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.