WebFX Documentation

There are already great solutions to run Swing or JavaFX applications in the browser without plugins by actually running them on a server. And these solutions don’t have the limitations WebFX currently has. However, a standard self-contained JS packaging is a much more simple, scalable and reliable execution model. This is precisely the benefit of WebFX, and probably the main reason why you would prefer it over the other existing solutions.

In addition to the web platform, a WebFX application can also run on desktops & mobiles. WebFX will invoke the standard Java toolchain to produce desktop executables (embedding an optimized JRE), and the Gluon toolchains to produce native executables for the desktop and mobiles.

Some alternative technologies or JVM languages allow you to do the same but only for the application logic, because they don’t offer a cross-platform UI toolkit. With WebFX, you can do a full cross-platform development of your entire application from a single-source codebase.

Writing your whole stack in Java is a big advantage, keeping your environment simple and homogenous from a single Java IDE. This prevents you from having to master other complex ecosystems such as JavaScript or TypeScript, and also allows you to share common code between your backend and frontend using the Java module system - a great advantage compared to heterogeneous systems.

Despite the big size of OpenJFX, WebFX can produce lightweight web apps, as demonstrated by the demos and the website:

* compressed JS size transiting over the network, without eventual images or other resources

The secret? Three things:

WebFX is not an additional UI toolkit to learn - it’s an emulation of the well-known and well-documented JavaFX API. All the powerful JavaFX features that you know and love are available for your web app. You will feel right at home with WebFX!

You don’t need to run regular GWT compilations like you would do with a traditional GWT development, because you can already run and debug your WebFX application directly in your Java IDE with the OpenJFX runtime. You typically transpile your app only at the end of a development cycle to check the web version, after you have finished developing a feature using the standard JavaFX development model.

WebFX is an open source initiative released under Apache 2.0 license.

This is achieved by running the Maven package goal under the webfx-cli directory:

This generates an executable fat jar in the target folder that we can execute with java:

The webfx.sh and webfx.bat script files (located under the webfx-cli directory) are simply executing the same fat jar. We will use them in the next step.

To easily invoke the CLI from a terminal, we need to create a permanent webfx alias. This is done with the following commands (to run under the webfx-cli directory):

Now you should be able to invoke the CLI from the terminal:

You can check for update at anytime by running:

If a new version is available, it will download it and build it for you.

Let’s create our first WebFX application. We need to create the repository directory and ask the CLI to initialize it, passing it the groupId, artifactId and version of our application.

The init command creates only 2 files: webfx.xml and pom.xml. Note that if this is the first time you have used the CLI, it will download some other files through Maven to retrieve essential information about the available WebFX modules.

When we create an application, we pass the fully qualified name of the JavaFX class we want to create, and the prefix to use for the application modules:

This command created the following modules:

The JavaFX class is located in the first module. Normally its start() method is empty at this stage, but because we specified the --helloWorld option, it has been populated with this simple template:

The following command will do a simple build of your application (without generating any final executable):

To generate the executables for the different platforms, you need to pass some extra build options. You can have the list in the build help:

Some builds require the installation of third-party software, as shown in the following table:

* these tools are optional, they are used to create installers (.msi or .exe)

We will now cover each target platform in detail.

Open the webfx-example directory from your Java IDE. It should recognize the directory as a Maven project, and import it.

Create an application configuration as follows:

The way to boot GWT and OpenJFX applications is different, but WebFX offers a cross-platform way to do it. For this reason, the main class of a WebFX application is always dev.webfx.platform.boot.ApplicationBooter. It will find your JavaFX application because it has been automatically declared as a Java service by the CLI.

If you run this configuration, it will build and run your WebFX application in your IDE using the OpenJFX runtime. This is the configuration that you will use to develop and debug your application.

As opposed to the OpenJFX version where the IDE can use its own Java build system, the GWT version can only be built through Maven. One way to build it is to open a terminal window in your IDE, and to type webfx build --gwt.

Another way is to trigger the build manually through the IDE Maven window.

It can be a good idea to create a configuration by selecting Modify Run Configuration in the context menu of that package goal, and press OK in the window below. You can then easily run this configuration to trigger the GWT build.

Once built, you can ask your IDE to open the generated html file in a browser.

Let’s do a first little change by replacing the Text with a Button. At first sight, it looks an insignificant change, but actually it’s not, because this involves a new dependency to the javafx-controls module (our application was only using the javafx-graphics module so far). To take advantage of the CLI, let’s enter the fully qualified Button class name like this:

The IDE doesn’t recognize this class yet, but let’s ask the CLI to update the build chain from the terminal window:

The CLI should make all necessary changes in the pom.xml, module-info.java, and module.gwt.xml files. After a few seconds, your IDE should automatically detect and consider these changes. Then it should recognize the Button class, and allow you to import it.

Finally, let’s add a simple code to react to the button:

You can first check the code is working as expected with the OpenJFX runtime by running the OpenJFX configuration. And then build and run the GWT version using one of the methods already explained.

Our application looks a bit sad? Maybe you can try this little code that adds a bit of colors, animation and effect?

Some more creative ideas pop up in your mind? Now is the time to play with WebFX!