Java full stack objections and how webforJ answers them

Suggest building the whole app in Java and someone on the team will push back. It adds latency, it shuts you out of the JavaScript ecosystem, it won't feel like a real app.

Those are fair questions about full stack Java, where one Java codebase covers the UI, the routing, and the data. With webforJ each one has a concrete answer, and a few turn out to be habits you can avoid rather than limits of the model.

See full stack Java running

The webforJ CRUD app on GitHub is a small full stack example: a searchable table of music artists, an add and edit dialog with bound, validated fields, and a Spring Boot backend, all in Java. You only need Java and Maven to run it.

Is full stack Java a good idea?

For internal tools, admin panels, dashboards and line-of-business apps, yes. Your team already knows Java and Spring, and webforJ lets that knowledge cover the screen as well. A view is a Java class, a button is new Button("Save"), and a click handler is a lambda. There is no second language, no second build and no JSON contract to keep in sync between a frontend and a backend you also own.

webforJ runs the UI on the server and sends the browser only what it needs. Spring integration means your beans, repositories and configuration work as they do in any Spring Boot app, and your views can @Autowired them.

The sections below take the objections one at a time. Where an objection is partly right, we say so.

Objection: every click is a network trip

This is the most common worry about server-side UI, and the most misunderstood. webforJ splits client and server traffic into three kinds, described in the client/server interaction guide:

1. Server to client calls such as setText(). The server sends them without waiting for an answer, and webforJ batches them.
2. Client to server events such as a button click. The client sends them without waiting, and the event object carries its data with it.
3. Round trips, where the server asks the browser a question and waits, as Label.getText() does.

The first two are cheap. The third is the one that hurts, and it's the one you control. Reading a value from the component forces a round trip, while reading the same value from the event doesn't:

private void comboBoxSelect(ListSelectEvent ev){
  //Gets value from the event
  int selected = ev.getSelectedIndex();
}

Calling getSelectedIndex() on the ComboBox itself instead would stop the app until the browser answered. That difference is the whole story behind most "server-side UIs are slow" experiences, and it's a habit you can learn in an afternoon.

For typing, you don't want a request per keystroke. The Debouncer waits until the user pauses:

Debouncer debounce = new Debouncer(0.3f);

textField.onModify(e -> {
  debounce.run(() -> search(textField.getText()));
});

Startup is light too. A webforJ app loads about 2.5 kB of gzipped JavaScript to bootstrap the session, then pulls further chunks on demand. The code for a Button reaches the browser once, when your app creates its first one.

Java frontend without JavaScript

The objection here is that you give up a huge ecosystem. In practice you keep it, and you reach it from Java.

The Element class wraps any HTML tag or custom web component, and the @JavaScript annotation loads the script that defines it. From Java you set its attributes, listen to its events and call its methods, as the Element docs show. When you need to reach the page directly, executeJsVoidAsync runs a script without blocking the server thread.

For packages from npm, the frontend bundler is available since 26.01. A class names the frontend it needs with an annotation, and the build plugin installs the packages and compiles React, Svelte or Lit sources, plus SCSS. It manages Bun for you, so there is no Node toolchain to install on your machine or your build server.

So the real pros and cons look like this. You write your logic in Java and skip the JavaScript framework layer for most of a typical business screen. For the remaining widget that only exists as a JavaScript library, you wrap it once and use it from Java everywhere after.

Server-side UI drawbacks, stated plainly

Two costs deserve honesty.

The first is the round-trip rule in the preceding section. A server-side UI rewards the habit of taking data from events and not from components. If you write code that queries the browser in a loop, you will feel it. The client/server guide shows the pattern and the fix.

The second is that the server holds your UI state. That's a design choice with a benefit, since the logic never ships to the browser, and a cost you plan for like any stateful tier. We make no claims about your capacity numbers, because those depend on your app and your hardware. Load-test your own screens, as you would any Spring Boot service.

Objection: it won't feel like a real app

A browser tab that looks like a tab is a real limit for some products. For many business apps, the question is whether users can open it from their home screen, and whether it can remember them.

webforJ covers both. Annotate the app with @AppProfile and it generates a Web App Manifest with name, icons and screenshots, so supported platforms offer to install it. The installable apps guide lists the metadata, and the installable apps post walks through it. Preferences and session data persist in the browser through LocalStorage, SessionStorage and CookieStorage, documented under web storage.

Animated route changes need no JavaScript either, as the view transitions post shows.

Is server-side logic harder to secure?

For most teams the opposite holds. Because rendering happens on the server, access rules can run before a view exists. Route security lets you mark a view with @AnonymousAccess or a role requirement and have the framework enforce it before any component renders. It works with Spring Security or with plain Java implementations of the core interfaces.

Which objections are real

Worry	Verdict	What decides it
Latency on every click	Mostly a habit problem	Read values from events, debounce typing
No JavaScript ecosystem	Not a limit	Element, @JavaScript, the bundler
Doesn't feel like an app	Depends on the product	@AppProfile, web storage
Server holds state	Real, plan for it	Test your own screens under load
Two teams, two stacks	Gone	One Java codebase with Spring

If your product is a consumer site with heavy offline needs or a game, pick another tool. If it's a business app your Java team will maintain for years, webforJ is the strongest fit we know how to build.

Try it on a real screen

Generate a project at startforJ, or follow getting started, and build one form with a table behind it. The app basics page walks through the Application and view classes in a few minutes. Measure the result before you decide.

Frequently asked questions

Is full stack Java a good idea for new projects?

Yes, when your team is mostly Java developers and the product is a business app. You keep one language, one build and one set of tests, and Spring services plug straight into your views.

Does server-side UI make webforJ slower than a JavaScript frontend?

Not by default. Server-to-client calls are batched, events carry their data, and the app bootstraps with about 2.5 kB of gzipped JavaScript. The slow case is code that reads values from components in the middle of an event handler, and the client/server guide shows how to avoid it.