A decision guide to Java for front end development

Java for front end development works today, and webforJ is the framework that makes it practical. 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.

This guide is for Java teams deciding how to build a browser UI. It covers what "front end in Java" means, which approaches exist, and how to choose.

Can Java do frontend?

Yes. Modern browsers run JavaScript, not Java, so the real question is where your UI code lives. There are three honest answers.

1. Your UI code runs in the browser as JavaScript or TypeScript. Java stays on the server as a data API.
2. Your UI code is Java, compiled or translated to something the browser runs. This was the path of toolkits like GWT.
3. Your UI code is Java and runs on the server, and the browser acts as a display and input device. This is how webforJ works.

The third model is the one that removes the front end as a separate discipline. You never design a REST contract for your own screens, never duplicate validation in two languages, and never keep two build pipelines in sync.

How webforJ handles the browser

A webforJ app runs on the server. When it calls a method like setText(), the framework sends that instruction to the browser, batching operations so the client does not wait on each one. When the user clicks a button, the event travels back to the server and reaches your Java listener.

At launch the browser loads a small bootstrap, about 2.5 kB gzip of JavaScript. After that it downloads chunks on demand. The code for a Button arrives the first time your app creates one. You get the client and server model without writing the glue.

For the full picture of this model, read server-side UI framework for Java.

What a view looks like

Here is a complete routed view. It is a plain Java class with a route, a text field, a button, and a result line.

GreetingView.java

@Route("greeting")
public class GreetingView extends Composite<FlexLayout> {
  private final FlexLayout self = getBoundComponent();
  private final TextField name = new TextField("Your name");
  private final Paragraph message = new Paragraph();
  private final Button greet = new Button("Greet", ButtonTheme.PRIMARY);

  public GreetingView() {
    self.setDirection(FlexDirection.COLUMN).setSpacing("12px");
    self.add(name, greet, message);
    greet.onClick(e -> message.setText("Hello, " + name.getValue() + "!"));
  }
}

Navigating to /greeting renders the view. There is no template file, no component tree in a second language, and no endpoint behind the button. The click handler is a Java lambda and the state lives in Java fields.

Composite wraps a bound component, here a FlexLayout, so you can package a view or a reusable piece of UI as one class. Routing maps a class to a URL.

Java UI framework without JavaScript

"Without JavaScript" is a design goal of webforJ, and it covers the things teams usually reach for JavaScript to do:

• Layout and components. The component set covers layouts, forms, tables, dialogs, navigation and more, all as Java classes. See the component overview.
• Events. Click, selection and input events are Java listeners. See events.
• Styling. You style components with CSS, themes and design tokens. See styling.
• Routing and navigation. Annotations on view classes, not a client router.

When you do need something outside the component set, you have two escape hatches. The Element class wraps any HTML tag or custom web component, and you can run JavaScript from Java for the rare cases that call for it. Web components in Java shows the first one in detail.

Java front end options compared

This is the decision most Java teams face when they search for Java frontend frameworks in 2026.

Approach	Where UI code lives	What you maintain	Fits when
Java API plus React or Angular	JavaScript or TypeScript in the browser	Two codebases, an API contract, two toolchains	You already have a dedicated front end team
Server-rendered templates	HTML templates plus some JavaScript	Templates, controllers, scripts for interactivity	Mostly static pages with light interaction
Desktop toolkits (Swing, JavaFX)	Java, on the user's machine	Installers and desktop distribution	Desktop-only users
webforJ	Java, on the server	One Java codebase	Your team is Java and the product is a business web app

If your developers are Java developers and the product is a business app such as an admin panel, a data-heavy tool or an internal portal, the last row removes the most work.

When webforJ is the right call

Pick webforJ when:

• The team knows Java and wants to ship screens without hiring for a second stack.
• The app is a business app: forms, grids, dashboards, workflows.
• You want the UI and the domain logic to share types, validation and security rules.
• You already run Spring Boot and want the UI in the same project.

Pick a JavaScript framework when your product is a design-heavy consumer site that a front end team owns end to end. That is a different job, and a Java UI framework is not what it needs.

Why one language matters

Most of the cost of a split stack is not writing the first screen. It is the coordination after it. A field is renamed, and the API, the client types, and the form all change. A validation rule is tightened on the server, and the browser copy drifts.

When the UI is Java, a rename is a refactor your IDE completes. Your compiler checks the screens. Your existing tests, tools and code review habits apply to every layer. For Spring teams, your UI does not need a REST API because the view calls your services directly.

Try it

Generate a project with startforJ, run it, and paste in the preceding view. If you prefer the command line, the getting started guide walks through the Maven archetypes.

Frequently asked questions

Can Java do front end development?

Yes. With webforJ you write the user interface in Java: components, layouts, forms, and event handlers. The framework handles the browser side, so you do not write JavaScript for typical business UI.

What are the Java frontend frameworks to consider in 2026?

The main approaches are a Java back end with a JavaScript front end, server-rendered templates, desktop toolkits such as Swing and JavaFX, and a Java-only web UI framework like webforJ. For business web apps built by Java teams, webforJ gives you one language and one codebase.

Can I build a Java UI without JavaScript?

Yes. Components, layouts, events, routing and styling are all available from Java in webforJ. For the occasional special case you can wrap a custom element with Element or run JavaScript from Java.

Does webforJ work with Spring Boot?

Yes. webforJ has a Spring integration, so your views can live in a Spring Boot project and use your Spring services directly.

Do I need to know HTML and CSS?

You do not write HTML templates. Basic CSS helps when you customize a theme, and the styling system gives you design tokens and component parts to do it cleanly.