If you maintain JSF or PrimeFaces screens and are planning a JSF to Spring Boot migration, webforJ is a direct fit, and a JSF alternative that stays in Java. It is a full-stack Java framework: you build each screen as a Java component tree, route to it with an annotation, bind it to a bean, and validate with the same Jakarta constraints you already put on your model.

A migration is mostly a translation exercise. Most JSF concepts have a direct counterpart, and most of them get smaller. This post maps the concepts one by one and then converts a real form, so you can judge the effort on your own views before committing to anything.

When a team picks a framework for a business app, the first screen is never the hard part. The hard part is everything that comes after it: navigation, a login, forms that validate, a table that holds real data, a second language, a test suite. A complete Java web app platform answers all of that before you ask. webforJ, the full-stack Java framework, covers it. It is a single framework, in a single language, that ships project setup, routing, a component library, data binding, security, Spring Boot integration, theming, translation, installable apps, and testing.

Because webforJ is a full-stack Java framework, the screens, the rules around them and the services behind them live in one Java codebase and one Maven build, with Spring Boot integration when you have it.

craftforJ is the visual UI designer for Java that ships with webforJ, the full-stack Java framework. It opens on top of your running app, shows the component tree your Java code built, lets you change properties and see the result at once, and writes the changes you keep back into the Java file that created each component.

Because the designer works on the real app, there is no export step and no generated code to reconcile with your own. The source stays the source. This post walks through how that works, from enabling it to writing a change into a view.

For most Java teams the best Spring Boot frontend is webforJ, the full-stack Java framework. You write the whole app, screens included, in Java, and it runs inside the same Spring Boot app as your services and gets its beans through constructor injection. There is no second language, no second build, and no HTTP contract between your screens and your data.

The alternatives are real and each fits some teams. Thymeleaf suits server-rendered pages with little interactivity, and a React or Angular single-page app suits teams that already have frontend specialists. This post compares them on build, skills, security, data access, and the cost of one feature, so you can choose a frontend framework for Spring Boot on evidence.

Not every Java web app runs on Spring Boot, and adding a framework just to put one screen inside an AI chat would be the biggest change in the project. The good news is that you don't have to.

You can build an MCP app in plain Java without Spring Boot. With webforJ, one servlet initializer assembles the MCP server, a routed view becomes the UI the AI opens, and the person clicks through the same live components they'd see in a browser. The code in this post comes from a working plain servlet app built on webforJ 26.02.

Your team has a ZK app that works. Screens are written in ZUL, the logic sits in composers or view models, and a change to one form means opening more than one file. If you are searching for a ZK framework alternative that keeps the server side model but drops the markup layer, webforJ, the full-stack Java framework, is built for that. Every screen is a Java class, with no ZUL and no XML, and you can move over one screen at a time.

In webforJ you get real-time UI updates in Java by changing components from the server and letting the framework carry the change to the browser. For work that runs outside the UI thread, you wrap the change in Environment.runLater(). For recurring refreshes you use Interval, and for typing you use Debouncer. You write no WebSocket or server-sent events code.

This post builds two small pieces: a progress panel fed by a background job, and a dashboard number that refreshes itself. Along the way it covers the one rule that decides whether any of this works, which is which thread may update a component.

If you've been wondering whether a Java design system is something your team has to build on top of the framework, I have good news. webforJ ships one called DWC: a set of CSS custom properties for color, typography, spacing, borders and shadows, three built-in themes, palettes generated from a seed color, and Shadow Parts for the places tokens don't reach. Override a few variables and the whole app takes on your brand.

A developer asks: "How do I control which users see which views?" In an app built with webforJ, the first instinct might be to call setVisible(false) on a navigation component based on the current user's role, or to conditionally add layout elements depending on permissions. It's direct and it works for what it does: but what it does is different from what the question was asking.

Controlling visibility and restricting access are different operations. Treating them as equivalent is how unintended access surfaces in production.

A Java CRUD web app in webforJ is one Spring Data repository and one view class. A Table backed by SpringDataRepository lists and sorts the entities, a BindingContext with Jakarta validation drives the create and edit form, and a ConfirmDialog guards the delete. The whole screen is Java, so there is no REST layer to write, no JavaScript to wire up, and no template language to learn.

This tutorial builds that screen for a Customer entity. By the end you have a list with sorting, search, and paging, a form that validates before it saves, and a delete that asks first. It's the shape of a Spring Boot CRUD UI you can reuse for any entity.

Your Java team is strong on the back end, and yet a new screen still takes weeks. The code is rarely the slow part. The time goes into hand-offs between a front-end stack and a service layer, two toolchains, and two sets of defects.

Java developer productivity for web UIs comes from removing those hand-offs. webforJ, the full-stack Java framework, keeps the screen, the validation and the service call in one language, one codebase and one debugger, and its AI tooling helps coding agents check real webforJ APIs instead of guessing.

Java for front end development works today, and webforJ makes it practical because it covers the whole app, screens included, in Java. You write views, layouts, forms, and event handlers in Java, the browser renders them, and you do not write a line of JavaScript or maintain a separate front end project. The same developers who own the back end own the screens.