# data[].attributes.headline
Bootstrap and GWT Transpiler — Just Flowers

# data[].attributes.subject
Bootstrap and GWT Transpiler — Just Flowers

# data[].attributes.attachment_link.title
Bootstrap and GWT Transpiler — Just Flowers

# data[].attributes.attachment_link.description
This is a brief story of my experience utilizing #Bootstrap and #GWT transpiler to convert #Java to #JavaScript for building a simple…

# data[].attributes.attachment_link.description
GWT 2.12 Released: A New Chapter for Java Web Apps

# data[].attributes.headline
GWT Transpiler Performance on the MacBook Pro M4 Max

# data[].attributes.subject
GWT Transpiler Performance on the MacBook Pro M4 Max

# data[].attributes.attachment_link.title
GWT Transpiler Performance on the MacBook Pro M4 Max

# data[].attributes.attachment_link.description
Evaluating the Speed of the M4 Max MacBook Pro

# data[].attributes.attachment_link.description
Share your videos with friends, family, and the world

# data[].attributes.headline
10 Best JavaScript Frameworks to Use in 2024

# data[].attributes.subject
10 Best JavaScript Frameworks to Use in 2024

# data[].attributes.attachment_link.readable_text
© JavaScript Oracle - heh not only Java is Oracle's trademark but also JavaScript

JavaScript is often criticized, a sentiment that has prevailed since its inception in 1995 when Brendan Eich, an engineer at Netscape Communications Corporation, created it in just 10 days during May of that year.

Due to its perceived shortcomings, developers have sought alternatives, leading to the creation of various languages and tools like Java, Closure tooling (developed by...

# data[].attributes.attachment_link.title
10 Best JavaScript Frameworks to Use in 2024

# data[].attributes.attachment_link.description
JavaScript is often criticized, a sentiment that has prevailed since its inception in 1995 when Brendan Eich, an engineer at Netscape Communications Corporation, created it in just 10 days during May...

# data[].attributes.body
A comprehensive article about GWT Boot (DominoUI DominoREST) and Spring Boot (REST, Service, Data, JPA)

# data[].attributes.attachment_link.description
Learn how to create a high-quality web application using Java on both the server and client side, utilizing web browsers

# data[].attributes.attachment_link.title
WebAssembly for the Java Geek - JVM Advent

# data[].attributes.attachment_link.description
When many Java developers hear the word WebAssembly, the first thing they think is "browser technology". The second thing: "it's the JVM all over again". After all, for a Java developer, in-browser apps are prehistory.

# data[].attributes.attachment_link.description
WebFX is a JavaFX to JavaScript transpiler powered by GWT. You write your Web application in JavaFX and GWT will transpile it in pure JS.

# data[].attributes.body
Navigate 2022

# data[].attributes.attachment_link.title
Web Micro Frontends - Gestern heute or never? - Dr. Lofi Dewanto

# data[].attributes.body
Microfrontends: Yesterday, Today or Never: Historical View and Future Trends

# data[].attributes.attachment_link.title
Web Micro Frontends: Gestern Heute or Never? - DEVK Navigate 2022

# data[].attributes.attachment_link.description
Web Micro-Frontends - Gestern Heute or Never Dr. B. Lofi Dewanto https://bit.ly/NavigateMicroFrontend2022

# data[].attributes.body
Every Thursday live with Collins...

# data[].attributes.attachment_link.description
To enable teams to write large maintainable web applications in Java. We offer support subscriptions to continue the development of GWT and its ecosystem, and can be contracted to help at any point in your application lifecycle.

# data[].attributes.attachment_link.title
GitHub - TDesjardins/gwt-knowledge: Collection of GWT knowledge and resources

# data[].attributes.attachment_link.description
Collection of GWT knowledge and resources. Contribute to TDesjardins/gwt-knowledge development by creating an account on GitHub.

# data[].attributes.body
Why is Web browser for today apps development very important?

# data[].attributes.attachment_link.title
Web Browser as a Platform - DEVK Navigate 2021

# data[].attributes.attachment_link.description
Web Browser as a Platform Dr. B. Lofi Dewanto https://bit.ly/DEVKNavigate2021

# data[].attributes.headline
Deploy GWT / J2CL Web Apps on Azure Static Web Apps Service

# data[].attributes.subject
Deploy GWT / J2CL Web Apps on Azure Static Web Apps Service

# data[].attributes.body
In this short story I’ll show you how to deploy GWT / J2CL web apps on Microsoft Azure Static Web Apps Service.

# data[].attributes.attachment_link.readable_text
In this short story I'll show you how to deploy GWT / J2CL web apps on Microsoft Azure Static Web Apps Service. There are some advantages if you implement your web apps with Full CSR (Client Side Rendering) so that the web apps just run on your web browser and embrace the client computing power. The cost of cloud computing is one of it. In this case the cloud provider just has to deliver the static files without doing much processing on their side.

If you want to see why you should embrace the power of web browser you could take a look at my talk:

GWT / J2CL is a Java to JavaScript transpiler, so in the runtime the web apps are pure HTML, CSS and JavaScript. Java is only available at the development time so that Java developers can use everything well known like Maven / Gradle, IntelliJ / Eclipse / NetBeans / Visual Studio Code and other tools and frameworks.

In my story list you can find different kind of GWT / J2CL articles, from beginner to expert. You could also take a look at the GWT Padlet for all up-to-date information about GWT / J2CL.

After you implement your web app with GWT / J2CL you would definitely deploy it somewhere so that your customers could use it. There are a lot of cloud providers today like AWS, Azure, Google Cloud, Heroku, etc. Today I'll show you how to deploy the apps on Microsoft Azure Static Web Apps Service. This is interesting because GWT apps are just HTML, CSS and JavaScript, so the service just delivers the files once to web browser and that's it. If you need some server-side functionalities you could use Azure Functions. Below is the architecture of Azure Static Web Apps.

Azure Static Web Apps Service (source: Microsoft Azure)

For the deployment I just create a simple GWT web app with Domino UI from DominoKit.

GitHub Repo for the demo: https://github.com/lofidewanto/gwt-azure-static-webapp

To deploy the static web apps this Quickstart Documentation helps a lot. You need to have a GitHub and Azure account to be able to deploy the web apps. Many of us owns already a GitHub account, so this shouldn't be a problem. To get an Azure account you need to have a credit card (at least in Germany) and this is not so easy. Heroku doesn't ask for a credit card for a free service. For a personal project Azure Static Web Apps Service should be free of charge: Azure Static Web App Plans.

So how is the process to deploy to Azure Static Web Apps? Actually one only needs to follow the Quickstart Documentation above. The problem I encountered was that all the examples are for JavaScript or TypeScript based frameworks like Vue.js. Angular or React, nothing for Java or GWT.

Starting to deploy Java / GWT on Azure Static Web Apps Service

After getting some helps from Bruno Borges and Anthony Chu I manage to make the GWT web app deployed. The main problem was to add Maven build step into the GitHub Actions. For this purpose I need to do following:

Add a step to build the GWT web app with Maven

Change app_location to the /target/gwt-azure-static-webapp-1.0.0-SNAPSHOT/calculator which is the result directory of the transpiled Java files. This is the directory where we can find the HTML, CSS and JavaScript files.

Change skip_app_build to true. This makes the build process for JavaScript won't be executed.

That's it!

GitHub Action Workflow file for the demo: https://github.com/lofidewanto/gwt-azure-static-webapp/blob/main/.github/workflows/azure-static-web-apps-lively-pebble-036bda903.yml

The whole steps of the GitHub action can be shown as a list.

You can also take a look at the Azure Management Console to manage the deployed web app.

Summary and Next Step...

The advantages using GWT / J2CL is that the web apps will run completely on the web browser and this means that the cloud provider just simply needs to deliver the files without much processing. Azure Static Web Apps Service offers such a functionality. On the same time Java developers can still work with their well known tools and frameworks thanks to GWT / J2CL transpiler.

The combination of GitHub and Azure feels very nice. Using GitHub Actions is also very straight forward. This is my first time using it, so it can't be so hard. I'm using Visual Studio Code for Java to develop the simple GWT example and add the Azure Static Web Apps plugin to my VSC. They work pretty good together.

Visual Studio Code for Java with Azure Static Web Apps

The next step would be to test the Azure Functions to add some server-side functionalities to the client-side GWT web app. In this case I'm curious since Azure Functions does not support Java yet?
For now: have fun running GWT / J2CL web apps on Azure Static Web Apps Service!

# data[].attributes.attachment_link.title
Deploy GWT / J2CL Web Apps on Azure Static Web Apps Service

# data[].attributes.attachment_link.description
In this short story I'll show you how to deploy GWT / J2CL web apps on Microsoft Azure Static Web Apps Service. There are some advantages if you implement your web apps with Full CSR (Client Side Rendering) so that the web apps just run on your web browser and embrace the client computing power.

# data[].attributes.headline
GWT Boot Starters — Bootstrap a Simple GWT Web App

# data[].attributes.subject
GWT Boot Starters — Bootstrap a Simple GWT Web App

# data[].attributes.body
In this short article I’ll show you how GWT Boot Starters can help us to build our GWT web apps easier and faster.

# data[].attributes.attachment_link.readable_text
Just create a simple Maven Project. Add the parent project and the starter dependencies. The list of the starter dependencies can be found here. To be able to compile to JavaScript you need to add gwt-maven-plugin and add your GWT module name.

Create a GWT module descriptor at src/main directory. In this file you describe the EntryPoint class which is similar to Java Main class and method. Module rename-to="basic" means that the JavaScript will be compiled to the script basic.nocache.js. This module inherits everything from the Starter module. The list of the starter modules can be found here. This JavaScript can be imported in the host HTML file on the next step.

In this HTML file, located at hello/public, your generated JavaScript will run. This JavaScript can access the HTML file. In this example the generated JavaScript will access the div with id="helloButton".

The EntryPoint is the first class which will be executed ("Main method in Java app"). In this example it will exchange the "helloButton" with a Button.

package hello.client; import com.google.gwt.core.client.*;public class YourEntryPoint implements EntryPoint {
import com.google.gwt.user.client.ui.*;
 @Override
 public void onModuleLoad() {
 Button button = new Button("Click me");
 button.addClickHandler(clickEvent -> {
 Window.alert("Hello World!");
 });
 RootPanel.get("helloButton").add(button);
 }
}

In gwt-boot-sample-basic you can take a look at the basic example in GWT.

Now you are ready to start your GWT basic sample app for the first time.

The application gwt-boot-sample-basic uses integrated Jetty server from GWT to deliver the HTML host file. This can be done with other Servlet apps as well.

First generate the GWT Module Descriptor and then run the GWT Dev Mode in SuperDev mode to be able to compile the Java code to JavaScript code on reload in the web browser. In Maven you can run following command:

mvn gwt:generate-module gwt:devmode

You can just generate the module once and after that just run:

mvn gwt:devmode

GWT Development Mode UI After Running the Maven Command

Now you can copy&paste the "Copy to Clipboard" result of the GWT Development Mode UI above. Run it on:

http://localhost:8888/basic

Just reload your web app and GWT SuperDev mode will transpile your Java code to JavaScript on the fly. That's it, now you can develop your web app with GWT incrementally and fast!

You can debug the Java code on the browser with the help of source maps. In this example we use Google Chrome.

GWT Debugging With Chrome

In this short article we can see how GWT Boot Starters help to build GWT web apps faster. With the help of Maven we can easily bootstrap the development of GWT web apps just in few steps. With GWT Boot Starters we make the dependencies hell out of our project, just what Spring Boot Starters do to Spring Boot projects.

At the moment GWT Boot Starters don't support automatic creation of web apps with a web app like Spring Initializr but a GWT Initializr which based on the GWT Boot Starters would be the next important step.

In the mean time, enjoy working with GWT and check out some information about GWT Boot and GWT Boot Starters:

# data[].attributes.attachment_link.title
GWT Boot Starters - Bootstrap a Simple GWT Web App

# data[].attributes.attachment_link.description
Today 3rd. April 2021 I released the GWT Boot Starters 1.0.0 to Maven Central which is the first final version of GWT Boot Starters. In this short article I'll show you how GWT Boot Starters can help...

# data[].attributes.body
Why do we have to think a Web browser is a platform today?

# data[].attributes.attachment_link.description
Web Browser as a Platform Dr. Lofi Dewanto https://lofidewanto.blogspot.de

# data[].attributes.body
Extensible, testable and maintainable Java Web browser app with the Design Patterns from the server-side Java

# data[].attributes.attachment_link.readable_text
In the article "Using IndexedDB in Web Browser - All in Java" Mrs. Gwitany and Dr. Jackl told us how we could use Java with Elemental2 to build a simple prototype based on WebAPIs for IndexedDB. This time they'll show us how to build the already shown code to be testable and maintainable with all the Design Patterns we already know from our server-side experiences with Java.

In the server-side Java world we use following patterns all the time, so we want to use them in the Web browser apps as well:

Dependency Injection: we inject dependent object into a main object so that we could easily mock the injected object to be able to test the main object in a simple unit test. This is very useful especially if the dependent object uses e.g. database which can't be booted very quickly.

Service and Repository Pattern: we build services and those services access data repositories to be able to call the database operations.

Rich Domain Model: we don't want to build anemic domain model which contents only data, instead we also want to have some logics in it which is called rich domain model.

Builder Pattern: we build our object step-by-step using correct sequence of actions to be able to manage the creation of that object.

Mock Test: as mentioned before it is very important to be able to mock the behavior of dependent objects so that you don't need to use real database for your unit test.

Lesson 1: to build maintainable and extensible Web browser app you need to use the known design patterns you already learned from the server-side Java.

To show how we could use the patterns Mrs. Gwitany has created a small example indexeddb-elemental2-dagger2-example based on IndexedDB which we have seen in the last article. Following libraries and frameworks are used in the example:

Dependency Injection: Dagger2 is designed to be flexible and uses fully static, compile-time generator for Java, Kotlin and Android.

Service and Repository Pattern: no special framework for Service and for Repository Pattern we use a generic Repository Pattern which is designed from this class: Repository.java

Rich Domain Model: no special framework, we just have a calculated property getCalculatedPriceWithAmount on our Product.java class

Builder Pattern: some possibilities are using Project Lombok, AutoValue and Immutables framework. This time we just build the Builder Pattern manually, but next time we would try to use Immutables for this pattern.

Mock Test: for this purpose we use JUnit 5 and Mockito (see pom.xml)

So, let's deep dive into the example project!

Before we are looking into the project in detail let's see the structure of the Maven project on Eclipse STS 4 below.

The structure of the Maven project indexeddb-elemental2-dagger2-example

The project based on Maven and Mrs. Gwitany uses GWT Boot to simplify the pom.xml. GWT Boot Starter dependencies is basically a simple Starter dependencies collection for GWT just like Spring Boot Starter dependencies. The idea is taken from Spring Boot Starters. Here is the important part of the pom.xml which is based on GWT Boot Starter dependencies:

Mrs. Gwitany uses two Starter dependencies:

gwt-boot-starter-dagger2: dependencies to Dagger2. All GWT dependencies are included as transitive dependencies.

gwt-boot-starter-elemento-core: dependencies to Elemento. This library makes working with Elemental2 a lot more easier.

Other dependencies like elemental2-indexeddb can be added independently. Also don't forget to add the needed modules to the GWT Module Definition: module.gwt.xml.

GWT Boot uses GWT Maven Plugin and it should be configured like below:

With this pom.xml you are ready to go. More information how to setup a Maven project with GWT Boot please see GWT Boot Samples.

Lesson 2: use GWT Boot Starter modules to make your pom.xml easier to manage. No need to copy&paste the dependencies with the matching versions.

In GWT your app starts with the loading the code in Entry Point. So this is comparable with the Java Main Method. In this Entry Point we just simply initialize the Dagger2 framework with the root view / UI component ProductComposite.

Which Entry Point should be called, has to be defined in the GWT Module Definition file: module.gwt.xml.

If you know Spring Boot with its Dependency Injection (DI) annotations then it is easy to use Dagger2. This table below shows the similarity between Spring Boot and Dagger2 DI annotations.

Following Modules and Components should be implemented by the user of Dagger2:

AppModule: in this module we don't define any object creations because we use @Singleton on each class to be managed by Dagger2.

AppComponent: in this component we define the entry point for the class ProductComposite. The class ProductComposite is the root component view / UI of the Product domain.

After running mvn compile Dagger2 will generate some Java files to manage the dependency injection for you. Dagger2 uses code generator to create the factories and this is also the big difference with Spring Boot which mostly uses dynamic proxies and reflections. In the world of JavaScript we don't have Reflection APIs, therefore code generator is here the solution.

How could we use the DI framework afterwards? Just as simple as this example below. The class ProductService uses constructor injection to inject two other classes ProductIdbRepository and ProductRandomCreatorwhich can be used later in the method createProduct.

For the Repository Pattern we could define a general interface like Repository.

ProductIdbRepository implements the interface for the IndexedDB operations which consists the Product entity. The implementation of IndexedDB is quite straight forward. In the example Mrs. Gwitany only implemented the persist method. The rest is open for you to implement. ProductRandomCreatoris the class where we create some products since we don't have any possibility to create products from the user interface.

Both classes will be injected into ProductServicein its constructor like we have seen above.

Following class diagram shows us the structure of the Product domain model.

As we have seen above the Product is the entity in the domain model. Mrs. Gwitany made the the Product entity a rich one since it also calculates the price with the given amount in the method called getCalculatedPriceWithAmount. She also creates a Builder Pattern to be able to instantiate the product nicely. So here is how we could create the Product entity with the Builder Pattern:

Product product =new Product.Builder(key,
 "Lofi " + key).setType(type).setAmount(10)
 .setPrice(price)
 .build();

Following is the code of the Product entity in which the Builder pattern is also implemented.

Lesson 3: Dependency Injection,Service, Repository, Entity and Builder can be used also on Web browser with Java and GWT / J2CL. Please remember, we have Design Patterns because we've learned that they help us to structure our app so that it will be better maintainable and extensible.

After we have the domain model we just need the view / UI. For this purpose Mrs. Gwitany created the class ProductComposite. It needs the the ProductService, so it is injected into the ProductComposite. The renderView method build the HTML DOM tree with the help of Elemento library. The UI is very simple so that we can concentrate on the basics. The event handler onProductCreated will be call every time when the user clicks the button. It has some "presentation logic" which controls the creation of input field or just a simple logging on console.

Mrs. Gwitany and Dr. Jackl will handle the UI development in detail later in another article, because GWT / J2CL offers a lot of UI frameworks, in amount almost comparable with the JavaScript and old Java world.

Last but not least, actually this a very important part which Mrs. Gwitany and Dr. Jackl told me, within Java you can use your well known test frameworks like JUnit and Mockito. In these two unit test classes you can find some interesting tests:

How does the Web app looks like? Just go to the directory of the Maven project indexeddb-elemental2-dagger2-example and run following command:

mvn gwt:generate-module gwt:devmode

You'll see following Swing app and you can copy the Web browser address or just push the button to launch the default browser on your system.

Following Web app can be tested afterwards. You can also take a look at the IndexDB viewer on the Application tab of Google Chrome.

Note 1: the Web browser app tested only with Chrome and Firefox. In Firefox you could not use private mode to run IndexedDB.
Note 2: the app works with Java 8 or Java 11 since GWT 2.9 supports Java 11 but don't forget that the result of your app is always a JavaScript app.

In this article Mrs. Gwitany and Dr. Jackl have shown us how to build a testable and maintainable Web browser app based on Java. You can use all the design patterns you have learned from the server-side Java in your client-side Web browser Java app. In the era of Cloud Computing it is worth it to be brave to move your business logics from server-side to client-side. With the load on the client-side you will save computing costs from your cloud vendor. PWA (Progressive Web Apps) and Web browser apps with Java are simple and thanks to GWT and J2CL (Java2JavaScript transpiler) manageable and extensible just like their counterpart on the server-side. They are ready for production today.

In the next article Mrs. Gwitany and Dr. Jackl will show us how to use some pretty UI frameworks with all those fancy design like Material Design and Bootstrap. Also how to access the server-side Spring Boot REST APIs to be able to show how to reuse codes for client and server. Until then enjoy reading and don't forget to play with GWT and J2CL!

# data[].attributes.attachment_link.title
Using IndexedDB on Web Browser with Well Known Design Patterns

# data[].attributes.attachment_link.description
In the article "Using IndexedDB in Web Browser - All in Java " Mrs. Gwitany and Dr. Jackl told us how we could use Java with Elemental2 to build a simple prototype based on WebAPIs for IndexedDB.

# data[].attributes.body
GWT Boot Awesome Library List (Gwit a LiLi) - Collection of JavaScript Libraries with JsInterop Interfaces and Others.

# data[].attributes.attachment_link.readable_text
GWT Boot Awesome Library List (Gwit a LiLi) - Collection of JavaScript Libraries with JsInterop Interfaces and Others.

If you want to add your libraries and frameworks just make a Pull Request or create an Issue.

💖 means that the current library is supported by the author of that library.

If you want to add the 💖 to your libraries or frameworks you can do this in two ways:

Create a Pull Request to add the 💖 at the end of your libraries or frameworks line.

Create an Issue to tell us that you supports your current libraries or frameworks.

mvp4g2 - (JsInterop) 💖

nalu - (JsInterop) 💖

router-fu - A framework agnostic, state producing router (JsInterop) 💖

arez - Fast, easy state management library (JsInterop) 💖

gwt-pushstate - HTML5 push state library

gwtmockito - Test Mockito for GWT 💖

gwt-symbolmap - SymbolMap Support Library 💖

grim - Assert unexpected symbols are eliminated from output 💖

vecmath - A vector math library optimized for GWT/J2CL (JsInterop) 💖

gwt-bigmath - A big math library (JsInterop) 💖

gwt-cache-filter - A servlet filter that adds the appropriate http caching headers to GWT generated files based on .cache. and .nocache. naming patterns

jsinterop-generator - Generator to generate JsInterop files from Closure Extern files💖

webtack - Generator to generate JsInterop files from Web APIs specification WebIDL💖

typescript2java - Generator to generate JsInterop files from TypeScript

# data[].attributes.attachment_link.description
Collection of JavaScript Libraries with JsInterop Interfaces and Others - GWT Awesome Library List (Gwit a LiLi) - gwtboot/gwt-boot-awesome-lili

# data[].attributes.headline
Java vs. TypeScript from Java Point of View

# data[].attributes.subject
Java vs. TypeScript from Java Point of View

# data[].attributes.body
I would like to know, what are the obstacles for you as Java developers not using Java as programming language for writing Web browser apps. Web browser apps are client-side and not server-side Web apps.

# data[].attributes.attachment_link.readable_text
I would like to know, what are the obstacles for you as Java developers not using Java as programming language for writing Web browser apps. Web browser apps are client-side and not server-side Web apps. For running Web browser apps you mostly don't need a Web server, you just need HTML, CSS and JavaScript files.

I'm doing Web browser programming using Java with GWT / J2CL and surely it is not perfect because the Web browser APIs feel very JavaScript but I have following advantages:

1. We use Java as the language

2. We have the best ecosystem like libraries, frameworks, build system and IDEs.

3. We know best design patterns to make our apps maintainable like Dependency Injection, Mock Testing and many other just take a look at: http://bit.ly/DesignPatternsJava

4. ... and if you use Java on the server-side with Spring Framework or JavaEE you have one language through the whole stack. So, you could reuse Validation APIs, Business Rules, Business Model, etc. from server to client.

In the mean time I have written following articles in this domain:

... and also I created a collection of GWT / J2CL information as Padlet: https://bit.ly/GWTIntroPadlet

I know that for "Hello World" or trivial Web browser apps I don't need Java with transpiler. In this case I just write a simple JavaScript. But in our daily jobs we don't write "Hello World" apps and the maintenance of those apps is very important, therefore we use language like Java for its strongly typed and the things I've shown you above. This is also the reason why we see TypeScript everywhere today. VueJS 3 is completely written in TypeScript.
Anders Hejlsberg creator of TypeScript said in an interview:

Developers by then had started to build huge JavaScript apps for the browser and were struggling to write them in JavaScript, a language he says lacked key features like modules, classes, and, importantly, a type system for creating order through rules in a program.

The interview was very interesting, definitely a must read: http://bit.ly/AndersHTypeScriptInterview

Also my question goes to the use of TypeScript. You also use a transpiler in TypeScript so actually it is just similar to Java with GWT / J2CL. Why would you use TypeScript as a Java developer?

I know that for JavaScript developers TypeScript is much "nearer" in comparison to Java. Here is the definition of TypeScript:

TypeScript = JavaScript + Static Types + Transpiler + Tooling

But for Java developers? I don't think that TypeScript has advantages over Java. Therefore my conclusion is:

If you are coming from Java use Java on Web browser with GWT / J2CL transpiler.

If you are coming from JavaScript use TypeScript on Web browser.

# data[].attributes.attachment_link.title
Why Don't You Use Java for Programming the Client-Side Web Apps on Web Browser?

# data[].attributes.attachment_link.description
I would like to know, what are the obstacles for you as Java developers not using Java as programming language for writing Web browser apps. Web browser apps are client-side and not server-side Web apps. For running Web browser apps you mostly don't need a Web server, you just need HTML, CSS and JavaScript files.

# data[].attributes.headline
Impressions on Modern Java Web Browser Development with GWT

# data[].attributes.subject
Impressions on Modern Java Web Browser Development with GWT

# data[].attributes.body
We had a chance to use GWT in our internal Hackathon and here are our impressions and feedbacks for GWT / J2CL / Java development on the Web Browser.

# data[].attributes.attachment_link.readable_text
We had a chance to use GWT in our internal Hackathon and here are our impressions and feedbacks for GWT / J2CL / Java development on the Web Browser.

The Task: build a simple UI frontend web app which just shows other web apps contents (micro frontends with HTML, JS). So it is just like building a portal ( main frontend UI) with some portlets ( micro frontends). If you don't know what it is check out my article: From Portlets to OpenSocial Gadgets to Progressive Web Apps. We chose Material Design for the UI design.

The Team: we were four Java developers, one developer knows how GWT works and has done some stuffs in "old-style" GWT, one has also done small amount of GWT but very few, one has never done GWT but knows JavaScript and me who has some experiences in GWT.

Portal (Main Frontend UI) and Portlets (Micro Frontends)

Frameworks and libraries are developer's best friend therefore it is important that they serve developers best way to write best apps. If you are building frameworks and libraries your customers are the developers. So it is clear that the "developers" need to like your product to make your product successful.

Here are our experiences using GWT to solve our task.

(1) GWT Boot is very nice and make the development of GWT web apps very easy to start. But all of the modules are still SNAPSHOT and exist only in the Sonatype SNAPSHOT repository. A lot of other modern GWT modules are also still in SNAPSHOT. If you work behind the firewall in an enterprise environment and you only could access Maven Central RELEASE repository you won't be able to use it. At the end we need to put all the libs one by one manually without GWT Boot. Luckily we have all those GWT, DominoUI releases built by JResearch on Maven Central. We also found a bug in the dependencies of Elemento, since it was released in Maven Central but has a dependency to a SNAPSHOT version in gwt-safehtml.

(2) The Elemental2 lib is quite "raw" for Java developers as I expected in my article: Using IndexedDB in Web Browser - All in Java with Mrs. Gwitany and Dr. Jackl. It feels "too JavaScript" instead of Java. Also the programming model "asynchronous" needs getting used to. If you have worked with Swing or SWT you are maybe a bit familiar with it.

(3) It is difficult for the beginners to see the difference between Elemental2, and APIs. When to use what APIs for the task. Generally Document Object Model (DOM) is a new world for Java developers, so the entry is quite steep. One thing as Java developer you need to know is the difference between Node and Element in DOM. This video ist a very nice explanation for that topic: http://bit.ly/NodeVsElementHTML

(4) DominoUI makes it easy to build the first user interface, just with one line!

Layout.create("App title").show();

... and you get...

Standard Layout in DominoUI - Just One Liner (see: https://demo.dominokit.org/layout/app-layout)

Default DominoUI layout has, Navigation bar - 1, 2, 3, left panel - 4, center panel - 5, hidden footer - 6 and hidden right panel.

(5) After this we need to inject Cards from other portlets and these are our steps:

We need to access to each portlets (micro frontends) using Fetch API (modern) or XMLHttpRequest (old) from the Web browser. This article is a good explanation of Fetch API.

After we get the content from the portlet, we need to inject it to the "Card" within our "Div" in the portal. For this purpose we need to understand the DOM first.

In this case we also need to take care of CORS problem because the portlets are installed on different locations than the portal web app.

(6) One thing we need to change is the color scheme of DominoUI but it seems we cannot find how to change it easily. Contacting the developers of DominoUI in Gitter was very easy: https://gitter.im/DominoKit/domino and we got the answer very fast. There are some workaround on how to create a new color scheme but there will be some new annotations to build new color schemes easily.

# data[].attributes.attachment_link.title
Impressions on Modern Java Web Browser Development with GWT

# data[].attributes.attachment_link.description
We had a chance to use GWT in our internal Hackathon and here are our impressions and feedbacks for GWT / J2CL / Java development on the Web Browser. The Task: build a simple UI frontend web app which just shows other web apps contents (micro frontends with HTML, JS).

# data[].attributes.body
In this video you can see how to integrate JS libs with JsInterop, so you can use it in your webapp GWT Material

# data[].attributes.attachment_link.title
How To Create Your Custom Widget + JSInterop #9

# data[].attributes.attachment_link.description
This will teach you how to create your custom widget and incorporate JSInterop to build complex widgets. Some guidelines on JSNI - JSInterop (Feel free to ed...

# data[].attributes.body
In this article you learn how to use Elemental2 to access your Web Browser APIs

# data[].attributes.attachment_link.readable_text
Following simple logic should be implemented with IndexedDB:

1. The web app will create an IndexedDB database when a user open the web app for the first time. If there is no database / datastore available it will create a new database and insert some values.

2. If we open the web app for the next time and the database is already there, the web app will just insert some values. That's all.

As we have learned from the article "Learn Once Use Everywhere: Using JavaScript APIs in Java for Web Browser" we need JsInterop classes which bridge the access from Java to the IndexedDB API (use case 2). Surely we can build the JsInterop classes manually by ourself but we don't have to. Elemental2 library from Google is here to help. Elemental2 library is a thin bridge and it contains a collection of JsInterop classes to access available Web APIs. We can use these classes directly in our Java web app. So what are the steps to use Elemental2 library? Here you are...

First Step: you need to add the needed Maven dependencies, in this case the IndexedDB Elemental2 library, to your pom.xml.

Lesson 2: before you create JsInterop classes manually take a look at Elemental2 library, for most Web APIs there are already the JsInterop classes created for you.

Second Step: The documentation of Elemental2 library for IndexedDB is very rare, so you need to use the MDN documentation for IndexedDB. The documentation is great and comes with some examples. For the IndexDB topic there are also some good documentations and articles:

With above docs and articles you are ready to implement IndexedDB functions with Elemental2.

Lesson 3: search for articles and documentations about the topic first. Most of the articles are for JavaScript but don't panic, you will understand what you have to do in Java since it is very similar. Remember: the programming model in JavaScript is mostly based on events, promises, asynchronous programming model. The Elemental2 APIs will look very similar to the JavaScript APIs.

Third Step: The first problem I encounter was to check, whether IndexedDB is available on the web browser with following JavaScript code:

if ('indexedDB' in window) {
 console.log('This browser doesn\'t support IndexedDB');
 return;
}

After asking to the GWT Gitter Chat (this is definitely the place to ask for GWT / J2CL / Elemental2 topics) I got following solutions in Java:

After getting the solution for the first obstacle, the rest is easy as things are working just the same as in the JavaScript solution. Very interesting is the asynchronous programming model in JavaScript which is not usual for Java developers. Here is the code for checking the database / datastore when it is not there yet, so you need to create it first.
JavaScript:
openDBRequest.onupgradeneeded =function(event) {
 // Create object store from db or event.target.result
};
Java with Lambda:
openDBRequest.onupgradeneeded =event -> {
 // Create object store from db or event.target.result
 return null;
};

As you can see the code is quite similar. The return "null" in Java is not nice but it is needed because the Elemental2 libraries are generated from Closure libraries (more on the generation topic later).

# data[].attributes.attachment_link.title
Using IndexedDB in Web Browser - All in Java with Mrs. Gwitany and Dr. Jackl

# data[].attributes.attachment_link.description
This story isn't about Java Applet or Java WebStart, this story is a pure JavaScript story presented by Mrs. Gwitany and Dr. Jackl, generally known as GWT and J2CL. In the world of web browser...

# data[].attributes.body
In this article you can find a short intro to JsInterop "native" for GWT / J2CL

# data[].attributes.attachment_link.readable_text
First of all we need to have a JavaScript app or APIs which we want to use in our Java app. For this simple example I would use a JavaScript Calculator which is implemented in the file as a JavaScript function:

The Calculator has just two values x and y. It also has a function sum to calculate the sum of x + y. The next step is how we can bridge this Calculator function into our Java world? It's quite easy, we just write a JsInterop class Calculator.java to map it to our Java world. We use isNative = true to say to our transpiler that the implementation of this class is in the JavaScript world:

In the class above you don't see any implementations of the Calculator since they reside in the JavaScript function. That's it.

But wait, how can we use this Java class Calculator in our Java web app? For this purpose I extend the HTML file just like following steps:

1. I add the result of the transpiled JavaScript file: calculator.nocache.js to the HTML file

2. In the component Button event we can use the CalculatorService and call the calculatePrice method.

So the Calculator class can be used directly within the CalculatorService class in Java and at the end the CalculatorService class can be called from the JavaScript component Button within onclick event. For this purpose we need to build CalculatorService and this class should be callable from JavaScript which represents the use case 1 above. Here is the implementation of CalculatorService class which uses the Calculator class:

That's all we need.

# data[].attributes.attachment_link.title
Learn Once Use Everywhere: JavaScript in Java for Web Browser

# data[].attributes.attachment_link.description
First of all we need to have a JavaScript app or APIs which we want to use in our Java app. For this simple example I would use a JavaScript Calculator which is implemented in the file as a JavaScript function: The Calculator has just two values x and y.

# data[].attributes.body
New videos for GWT / J2CL stuffs from the Community Meeting

# data[].attributes.attachment_link.description
Our mission is to enable teams to write large maintainable web applications in Java. We offer support subscriptions to continue the development of GWT and it...

# data[].attributes.body
Playing the Game Online, have fun!

# data[].attributes.body
This is a great example of using GWT / J2CL to port the game Quake II to web browser. Here is a blog article about this subject.

# data[].attributes.attachment_link.readable_text
Dimitrii Tikhomirov has just announced a port of our Quake II GWT demo from 2010 to J2CL.

This seems to be the perfect opportunity to finally post a blog entry I have been sitting on for quite while now - and to provide some background and history of the port.

The original April 2010 demo

How it all started

The idea to port Quake II to WebGL and GWT was born at a Google internal GWT summit in 2009, where I was presenting a GWT based WebGL emulation of the Android Maps for Mobile 3D navigation rendering Engine. I don't remember who brought up the idea, but somebody mentioned Jake (the Java port of Quake II) - and we were immediately thrilled to figure out if it might actually be possible to pull this off.

We knew that this undertaking wouldn't be feasible without significant code changes, as many Java libraries just weren't available in the GWT JRE emulation. Some APIs just weren't supported because of memory concerns and others - such blocking network IO - were just impossible to emulate in GWT in its existing form.

One option would have been to hack the code and just replace anything in Java that isn't available with JSNI. But that's not the route we took. If we would have changed the code to no longer compile with regular Java, we'd have lost a valuable testing platform that allowed us to check whether we had introduced a bug by converting threaded code to asynchronous callbacks - or in our new graphics routines that map to WebGL. So we decided to go with emulations as far as possible - and to do the conversion from threaded code and blocking IO to async in a way that would still be compatible with regular Java.

For the GL part, one of the problems was that Quake II was still using gl_begin / gl_end style calls, building up rendering data in a piecemeal approach, which in modern GL has long been replaced with handing over bulk data in one go. This meant that we weren't able to use too much of the emulation I had built for Google Maps for Mobile. A full emulation also would need to include texture mapping, which in turn required image loading - which at this point we still needed to be convert to async somehow. So in order to gauge feasibility, I went ahead and implemented a simple Canvas2d baed emulation that would just render wireframe images. I can't describe how happy I was when I saw the first recognizable Quake II scene rendered with green lines on a black background. It looked a bit like the "Quake on an oscilloscope" demo (which came out later IIRC). I must admit that I am still a bit sad that I haven't properly preserved the corresponding rendering code.

Our first prototype looked a bit like this

Unfortunately, at this point, the frame rate was something in the order of magnitude of 1 FPS, but we managed to improve it quite a bit before the April release.

GWT Debugging and Code Sharing

Still up to today, one of my biggest issues with GWT / J2CL is that System.out.println() doesn't go to the console without a significant hack. I am aware that some people like to make fun of "printf debugging", but if you want to compare traces for several platforms, chances are that parallel tracing with a "real" debugger may get painful - it's just too easy to step over the significant part of the code.

Also, it's more easy to confirm that the modified source is actually executed and you are not looking at a stale browser cache. Now some people might suggest to use a proper logging framework instead of printf, but if debug printing is easily distinguishable from logging, it's also much more easy to remove, avoiding excessive log spam left in the code. For instance, at Google we have automated checks preventing code with print statements from getting checked in.

One thing I found quite irritating in some GWT libraries was that they provided a replacement for some system feature that couldn't be super-sourced for one reason or another - but then the replacement wouldn't have a matching JRE implementation, so even if the corresponding functionality was available in both, GWT and standard Java, the user was left with bridging this gap in some form or another.

In terms of Java code sharing, there are generally three major options

1. Emulate (super-source) a Java API in GWT

2. Add a shared abstraction layer with GWT and JRE specific implementations (possible more for Android or J2Objc)

3. Emulate a GWT/JS API in "regular" Java

My favorite is option 1, but it's not always possible. Anything related to blocking IO typically can't be emulated in GWT.

I think option 2 is considered the clean default by most people working with shared code, but it has some significant disadvantages:

It adds an extra layer on all platforms, including the corresponding performance and code size hits

The corresponding glue code has to be implemented everywhere

At least some people will know one of the underlying APIs. Why add more mental burden for everyone?

So if option 1 doesn't work, I'd recommend to seriously consider using option 2: Make the Web API available on all platforms. This should be even more simple in the age of Jsinterop, where annotations can be used on Java implementations of a web API to just point to the corresponding JS classes, methods and properties.

What happened after the April 2010 Demo?

The last time I checked (for the LibGDX port), some of the code developed for this demo, in particular the Java NIO Buffer emulation and the GL emulation, still lived on (to some extend) in the PlayN and LibGDX Java game libraries.

The main problem why we couldn't publicly launch a working web app (opposed to just the source) was that the Quake II source was open source, but the levels still are not. The typical way to work around this issue is to let the user provide a corresponding "wad" file, which is conveniently extractable from the shareware version that is still available on the web.

After finding a JS zip decompressor, I actually managed to add a download dialog to the WebApp and to launch it on AppSpot.

The game resource download dialog

My next goal was to port the Game to the LibGDX cross-platform game library, as PlayN was never really intended for 3D games - and some of the hacks we needed seemed to be an odd fit / maintenance burden for PlayN. In the same go, I wanted to check if it the code could work on Android, too. Unfortunately, the GL emulation fork in LibGDX is quite outdated. Resource management in LibGDX was built without the web in mind, and the way web support was added later proved to be quite incompatible with what we did for Quake. I got a prototype working (replacing the File API deprecated at that time with IndexedDB IIRC), but I kind of gave up when the Android built-in zip decode wasn't able to uncompress the shareware game executable.

Unfortunately, I have never back-ported all my LibGDX changes that were necessary to get the game running, so the LibGDX version currently compiles only with my outdated LibGDX fork.

What I really should have done

Instead of trying to shoe-horn the port into PlayN or LibGDX, where it doesn't really fit well, I should have pulled out the re-usable parts, in particular the java.nio emulation and the WebGL / OpenGL wrapper.

Fortunately, Dimitrii has done this for the NIO part now.

Links

Comments

Twitter discussion: https://twitter.com/dukoid/status/1277338090907095040

# data[].attributes.attachment_link.description
Dimitrii Tikhomirov has just announced a port of our Quake II GWT demo from 2010 to J2CL. This seems to be the perfect opportunity to finally post a blog entry I have been sitting on for quite while now - and to provide some background and history of the port.

# data[].attributes.body
An Opinionated Java ReactJS Binding UI Framework

# data[].attributes.attachment_link.title
React4j · An opinionated java react binding

# data[].attributes.body
A very good presentation about Model View Presenter (MVP) and EventBus. This pattern is generally applicable for old and modern  GWT apps.

# data[].attributes.attachment_link.title
Google I/O 2013 - Demystifying MVP and EventBus in GWT

# data[].attributes.body
Presentation about modern GWT / J2CL as an introduction

# data[].attributes.attachment_link.description
Modern GWT An Introduction Dr. Lofi Dewanto https://lofidewanto.blogspot.de

# data[].attributes.body
Open Source project J2CL on GitHub

# data[].attributes.attachment_link.readable_text
Seamless Java in JavaScript applications that tightly optimizes with Closure Compiler

J2CL is a powerful, simple and lightweight transpiler from Java to Closure style JavaScript.

Get the best out of Java and JavaScript. You no longer need to choose between the two or lock into a specific framework or a language. Choose the right language at the right place and hire the best talent for the job.

Get it correct the first time. The robust run-time type checking based on the strong Java type system combined with the advanced cross language type checks catches your mistakes early on.

Provides massive code reuse. J2CL closely follows the Java language semantics. This reduces surprises, enables reuse across different platforms and brings most popular Java libraries into your toolkit including Guava, Dagger and AutoValue.

Modern, fresh and blazing fast. Powered by Bazel, J2CL provides a fast and modern development experience that will make you smile and keep you productive.

Road tested and trusted. J2CL is the underlying technology of the most advanced GSuite apps developed by Google including GMail, Inbox, Docs, Slides and Calendar.

J2CL is production ready and actively used by many of Google's products, but the process of adapting workflows and tooling for the open-source version is not yet finalized and breaking changes will most likely be introduced.

We are actively working on adapting more pieces including Junit4 emulation and faster pruning for an even better development experience.

Last, the workflow is not yet supported in Windows. You can contribute to make this a reality. Coordinate and follow the progress of this effort here. For developers that want to use Windows as their platform we recommend installing under WSL (Windows Subsystem for Linux).

Stay tuned!

In early 2015, Google GWT team made a difficult but necessary decision to work on a new alternative product to enable Java for the Web.

It was mostly due to changing trends in the web ecosystem and our new internal customers who were looking at Java on the Web not as an isolated ecosystem but an integral part of their larger stack. It required a completely new vision to create tools from the ground up, that are tightly integrated with the rest of the ecosystem. A modern architecture, that is reliable, fast and provides a quick iteration cycle.

There was no practical way to achieve those goals completely incrementally out of GWT. We started from scratch using everything we learned from working on GWT over the years. In the meantime, we kept GWT steering committee members in the loop and gave contributors very early access so they could decide to build the next version of GWT on J2CL.

The strategy has now evolved GWT3 to an SDK focused on libraries and enterprise tooling which was one of the strongest points of GWT all along.

We think that such separation of concerns is crucial part of the success of the both projects and will provide the best results for the open source community.

Read how to contribute to J2CL.

Please refer to the license file.

J2CL is not an official Google product and is currently in 'alpha' release for developer preview.

# data[].attributes.attachment_link.description
Java to Closure JavaScript transpiler. Contribute to google/j2cl development by creating an account on GitHub.

# data[].attributes.body
GWT project generator for Nalu

# data[].attributes.body
All tweets for GWT

# data[].attributes.attachment_link.readable_text
We've detected that JavaScript is disabled in this browser. Please enable JavaScript or switch to a supported browser to continue using twitter.com. You can see a list of supported browsers in our Help Center.
Help Center

# data[].attributes.attachment_link.title
Dr. Jawa on Twitter: "This tweet is dedicated to all #GWT #J2CL #UI #UX User Interface #frameworks / Twitter"

# data[].attributes.attachment_link.description
This tweet is dedicated to all #GWT #J2CL #UI #UX User Interface #frameworks

# data[].attributes.attachment_link.embed_code
This tweet is dedicated to all #GWT #J2CL #UI #UX User Interface #frameworks
— Dr. Jawa (@lofidewanto) December 5, 2019

# data[].attributes.body
The main site of GWT is old and a lot of things are not up-to-date anymore - Deprecated

# data[].attributes.attachment_link.readable_text
GWT is used by many products at Google, including Google AdWords and Google Wallet. It's open source, completely free, and used by thousands of enthusiastic developers around the world.

Next

GWT is the official open source project for GWT releases 2.5 and onwards.

This site houses links to the documentation, source code repository, issues list and information related to GWT roadmap and release.

It is intended for developers interested in contributing to GWT, and for keeping people informed on new and upcoming changes to GWT, GWT related events and other news.

Next

# data[].attributes.attachment_link.description
GWT is used by many products at Google, including Google AdWords and Google Wallet. It's open source, completely free, and used by thousands of enthusiastic developers around the world. Next GWT is the official open source project for GWT releases 2.5 and onwards.

# data[].attributes.body
Modern Bootstrap and Material Design GWT UI framework

# data[].attributes.body
Bootstrap3 based GWT UI framework

# data[].attributes.attachment_link.readable_text
GWTBootstrap3 is a j2cl/gwt3 wrapper for Twitter Bootstrap, which helps you develop responsive, mobile first HTML, CSS, and JS projects on the web using Java and Google Web Toolkit (GWT).

Add GWTBootstrap3 to your project

You can easily add GWTBootstrap3 to your project by including the library as a Maven dependency.

Current Snapshot

1.1-SNAPSHOT

Snapshot Demo - GWTBootstrap3 v1.0-SNAPSHOT Demo. (Updated after every commit)

# data[].attributes.attachment_link.description
GWTBootstrap3 is a j2cl/gwt3 wrapper for Twitter Bootstrap, which helps you develop responsive, mobile first HTML, CSS, and JS projects on the web using Java and Google Web Toolkit (GWT). You can easily add GWTBootstrap3 to your project by including the library as a Maven dependency. 1.1-SNAPSHOT Snapshot Demo - GWTBootstrap3 v1.0-SNAPSHOT Demo.

# data[].attributes.body
Definitely worth to take a look!

# data[].attributes.attachment_link.readable_text
Curated list of GWT related news, links, blogs and libraries. GWT Framework is a development toolkit for building and optimizing complex browser-based applications. Support us: Suggest a new link. ("+" icon)

# data[].attributes.attachment_link.description
Curated list of GWT related news, links, blogs and libraries. GWT Framework is a development toolkit for building and optimizing complex browser-based applications. Support us: Suggest a new link. ("+" icon)

# data[].attributes.body
This framework is not yet compatible with GWT 3 or J2CL - still not using Elemental2 -
but still very good

# data[].attributes.body
JsInterop very simple example

# data[].attributes.attachment_link.readable_text
This example uses GWT Boot as Starter Parent: https://github.com/gwtboot/gwt-boot-samples

Take a look at this article to see the whole story: http://bit.ly/WebJavaStory

To build the example:

mvn clean package

To run the example:

First: run the GWT Dev Mode:

mvn gwt:generate-module gwt:devmode

Second: open your browser and go to following address:

http://127.0.0.1:8888/calculator/

GWT Dev Mode supports automatic transpiling. You just need to update your Java code in your IDE and reload your web browser. Your Java code will be automatically transpiled and your webapp stays uptodate without restarting the web server. If you change the index.html you need to push the restart button on the Swing GUI.

# data[].attributes.attachment_link.description
This example uses GWT Boot as Starter Parent: https://github.com/gwtboot/gwt-boot-samples Take a look at this article to see the whole story: http://bit.ly/WebJavaStory To build the example: mvn clean package To run the example: First: run the GWT Dev Mode: mvn gwt:generate-module gwt:devmode Second: open your browser and go to following address: http://127.0.0.1:8888/calculator/ GWT Dev Mode supports automatic transpiling.

# data[].attributes.body
Simple examples using GWT Boot

# data[].attributes.attachment_link.readable_text
Here you can find some samples on how you can use the GWT Boot Starters in your project. This quickstart document is based on following sample project: gwt-boot-sample-basic. If you are looking for GWT Boot Starter for Spring Boot check this out: gwt-boot-sample-basic-with-spring-boot

You can use IntelliJ or Eclipse / STS. To be able to use Java APT correctly please take a look on how to configure Java APT with Maven in each development environment.

Step 1 - Create a Maven Project

Just create a simple Maven Project. Add the parent project and the starter dependencies. To be able to compile to JavaScript you need to add gwt-maven-plugin and add your GWT module name.

Add Sonatype Snapshots repository by extending or creating <repositories> section since the gwtboot-modules are not released yet, so the example needs to access the SNAPSHOT version of gwtboot-modules.

Step 2 - Create a GWT Module Descriptor module.gwt.xml

Create a GWT module descriptor at src/main directory. In this file you describe the EntryPoint class which is similar to Java Main class and method. Module rename-to="basic" means that the JavaScript will be compiled to the script basic.nocache.js. This module inherits everything from the Starter module. This JavaScript can be imported in the host HTML file on the next step.

Step 3 - Create a Host HTML File where your JavaScript can run

In this HTML file, located at hello/public, your generated JavaScript will run. This JavaScript can access the HTML file. In this example the generated JavaScript will access the div with id="helloButton".

Step 4 - Create your Java Entry Point Main Class

The EntryPoint is the first class which will be executed. In this example it will exchange the "helloButton" with a Button.

In gwt-boot-sample-basic you can take a look at the basic example in GWT.

Now you are ready to start your GWT basic sample app for the first time.

The application gwt-boot-sample-basic uses integrated Jetty server from GWT to deliver the HTML host file. This can be done with other Servlet app as well.

Step 1 - Run GWT DevMode to automatically compile the code

First generate the GWT Module Descriptor and then run the GWT Dev Mode in SuperDev mode to be able to compile the Java code to JavaScript code on reload in the web browser. In Maven you can run following command:

mvn gwt:generate-module gwt:devmode

You can just generate the module once and after that just run:

Step 2 - Run the App in your Browser

Run it on:

Just reload your web app and GWT SuperDev mode will transpile your Java code to JavaScript on the fly. That's it, now you can develop your web app with GWT incrementally and fast! Enjoy!

# data[].attributes.attachment_link.description
Here you can find some samples on how you can use the GWT Boot Starters in your project. This quickstart document is based on following sample project: gwt-boot-sample-basic. If you are looking for GWT Boot Starter for Spring Boot check this out: gwt-boot-sample-basic-with-spring-boot You can use IntelliJ or Eclipse / STS.

# data[].attributes.body
Routing framework for GWT / J2CL

# data[].attributes.attachment_link.readable_text
Nalu is a tiny framework that helps you to create GWT based applications quite easily. Using the HTML 5 history for routing and navigation, Nalu supports the browser's back-, forward-, and reload-button by default and without any need to implement anything.

Nalu supports:

Route based navigation

HTML links and programmatically routing thanks to a router

Browser's back- forward- and reload-button (In case the hasHistory-attribute of the Application-annotation is set to true)

An optional loader that will be executed at application start to load data from the server

Client side context, router and event bus which will be automatically injected in every controller, filter, loader and handler (Handlers have only access to the context and the event bus)

Filters to intercept routing.

Separation of views into a controller and a component with framework sided instantiation.

A controller life-cycle using start-, mayStop- and stop- similar to GWT Activities.

Controller based handler manager, that will remove all handlers from the event bus in case the controller is stopped to prevent memory leaks (handler registrations must be added to the manager).

UiBinder (nalu-plugin-gwt)

Composites to support smaller units

Controller & component caching

Component creation inside a controller to support GWT replacement rules and static factory methods

Multi Shell Support

(nearly) Every widget lib (tested with: GWT, GXT, Domino-UI, Elemento, Elemental2, GWT-Material)

Maven multi module projects to separate an application in smaller parts (module feature)

Tracking user routing (in case a tracker is added)

Nalu uses a hash to navigate. Starting with version 1.1.0 Nalu supports the use of hash less URLs. Everything explained here will also work without hash. In case of working with a hash less URL, you need to implement something on the server to handle a reload.

Example hash:

#[shell]/[route]/:[parameter_1]/:[parameter_2]

where

shell: the shell to be used to display the route

route: navigation end point (a controller)

parameter_x: parameters of the route

The following flow shows the steps, once a routing is initiated. The flow will end with appending the new component to the DOM.

To connect a component to a route, just create a controller class which extend AbstractComponentController and add the controller annotation @Controller.

To navigate to a new route use inside a controller:

The router is injected in the controller. To route to a new component call the route method and add at least the new route. In case the route has parameters, just add them as additional parameters. ( Important note: parameters are always Strings!)

To use Nalu add the following dependencies to your pom:

Depending on the widget set your project is using, add one of the following plugins:

If the project uses a widget set based on Elemental2, Elemento or Domino-UI, use the Nalu-Plugin-Elemental2 by adding the following lines to your pom:

For Elemento there's a dedicated plugin which supports org.jboss.gwt.elemento.core.IsElement<E> as widget type:

The nalu-plugin-elemento can also be used with Domino-ui.
(These plugins are ready to use with J2CL / GWT 3)
If your project uses a widget set based on GWT 2.8.2 or newer, use the Nalu-Plugin-GWT by adding the following lines to your pom:
(This plugin will not work with J2CL / GWT 3)
See the wiki for more information about Nalu and how to use it.

More useful information about Nalu and how to use it, can be found inside the Wiki.

With the next version of GWT (GWT 3) and the new J2CL transpiler, there will be major changes in the GWT development. For example: JSNI and generators, besides other things, will be gone. To be prepared for the future things like JSNI, generators or any other dependency to GWT has to be removed and must be avoided.

Nalu uses only the already migrated gwt-events from org.gwtproject. (As long as gwt-events is not on Maven Central the sources of gwt-events will be part of Nalu. See #9 Replace gwt-event source files with gwt-event from Maven Central)

Nalu has no dependency to gwt-user nor Nalu's dependencies! Nalu does not use JSNI, generators or anything else from GWT (except the nalu-plugin-gwt).

Nalu is ready to use with J2CL / GWT 3 as long as you do not use the nalu-plugin-gwt!

Please use the Nalu Gitter room.

Here you will find many examples that show Nalu in action: https://github.com/nalukit/nalu-examples.

To speed up creating a Nalu project, the Nalu Boot Starter Project Generator (which is also based on Nalu) can be used to create a Nalu based project with a few clicks. The project generator will generate a Maven project, which can be imported to your preferred IDE. The project is ready to use.

Just run mvn clean install and mvn gwt:devmode to start the project.

More information about the generator and the source code can be found here: Nalu Project Generator.

In case you find a bug, please open an issue or post it inside the Nalu Gitter room.

# data[].attributes.attachment_link.description
Nalu is a tiny framework that helps you to create GWT based applications quite easily. Using the HTML 5 history for routing and navigation, Nalu supports the browser's back-, forward-, and reload-button by default and without any need to implement anything.

# data[].attributes.body
PatternFly based UI framework with GWT / J2CL

# data[].attributes.body
VueJS based GWT UI framework

# data[].attributes.attachment_link.readable_text
Easy to use

Components based architecture, with automatic data binding.

Safe

Expressions in your template and components bindings are type checked at compile time.

Fast

Write pure Java controllers and let GWT optimize everything for you!

Vue.js Compatible

Use existing Vue.js components in your app.

Interoperable

Vue GWT Components can be exported as Web Components and used in other web apps.

Friendly Licence

Like Vue.js, Vue GWT is released under MIT licence, use it however you like.

Who made this?

Vue GWT is developed by the awesome people at

# data[].attributes.attachment_link.description
Components based architecture, with automatic data binding. Expressions in your template and components bindings are type checked at compile time. Write pure Java controllers and let GWT optimize everything for you! Use existing Vue.js components in your app. Vue GWT Components can be exported as Web Components and used in other web apps.

# data[].attributes.body
Modern GWT / J2CL UI framework

# data[].attributes.attachment_link.description
Java based lightweight UI library that in addition to performance and functionality brings elegance to enterprise web applications.

# data[].attributes.body
Collection of nice GWT and JavaScript articles

# data[].attributes.attachment_link.description
Tutorials and discussions about JVM languages to-Javascript tools and frameworks ( GWT, Vaadin, Scala.js, ClojureScript, Kotlin to Javascript...)

# data[].attributes.body
... still alive 😃

# data[].attributes.attachment_link.description
The official GWT (formerly Google Web Toolkit) developer discussion group. GWT lets you build AJAX apps in the Java programming language.

# data[].attributes.body
... and here all the topics about J2CL

# data[].attributes.body
You can find all the current discussions on GWT just right here...

# data[].attributes.body
Short intro for GWT / J2CL in German language

# data[].attributes.attachment_link.readable_text
JavaScript ist aus der Webentwicklung nicht mehr wegzudenken. Dabei kann man Webprojekte auch gut mit Java umsetzen.

2019. Die Welt der Webbrowser-Programmierung beziehungsweise Webentwicklung ist von JavaScript und TypeScript besetzt. Die gesamte Webentwicklung? Nein, ein von unbeugsamen Open-Source-Java-Entwicklern bevölkertes Dorf hört nicht auf, dem Eindringling Widerstand zu leisten und zwar mit einem Java-zu-JavaScript-Transpiler namens GWT und J2CL (Java to Closure Transpiler).

Geschichte der Webframeworks

Der Vorteil einer statisch typisierten Programmiersprache ist das frühzeitige Erkennen bestimmter Fehler zur Kompilierzeit. Sie spart somit Entwicklern die spätere Fehlersuche zur Laufzeit. Java-Entwickler, die schon Anfang 2000 entwickelt haben, kennen die clientseitigen Benutzeroberflächen-Entwicklungen mit Swing oder SWT. Frameworks wie WebWork, Struts/JSP, Enhydra/XMLC, Tapestry, Echo und Spring MVC implementieren mit etwas HTML, CSS und JavaScript serverseitige Benutzeroberflächen im Webbrowser. Es gab unterschiedliche Ansätze und viele konkurrierende Frameworks für die Webentwicklung in Java.

Spätestens im Jahr 2005 ist die Anforderung an Webanwendung für die Benutzerinteraktionen gestiegen. Damals fiel der Begriff AJAX zum ersten Mal. JavaScript hat plötzlich an größerer Bedeutung gewonnen und ist seitdem nicht mehr wegzudenken. Heute stellen Webbrowser die Plattform beziehungsweise das Betriebssystem des Web dar und JavaScript ist de-facto dessen Muttersprache.

Abbildung 1 fasst die Geschichte der Webframeworks und den Übergang von reiner Java-Webentwicklung zu JavaScript-basierten Frameworks wie Angular, Vue.js und React zusammen.

Führt für Java-Entwickler im Jahr 2019 für die Webentwicklung kein Weg an JavaScript oder Derivaten wie TypeScript vorbei? Ein Wechsel der Programmiersprache erfordert stets Aufwand:

Kommen zusätzliche oder neue Frameworks in Frage?

Benötigt man eine neue IDE? Was ist mit Code-Formattern?

Muss man ein neues Build-Tool einsetzen? Funktioniert CI/CD weiterhin wie gewohnt oder sind neue Umgebungen notwendig?

Braucht es ein neues Artefakten-Repository?

Zum Glück gibt es einige Java-Ansätze, die einen kompletten Wechsel überflüssig machen. Der Artikel stellt beispielhaft den Einsatz von GWT und J2CL vor. Als Projekt dient ein einfacher Prototyp eines Taschenrechners in Java. Das Ergebnis erhält anschließend eine Übersetzung in JavaScript und eine Integration in einer eigenen JavaScript-App innerhalb eines Webbrowsers. Es sollen bekannte Java-Tools und -Frameworks wie VS Code for Java, Maven und JUnit zum Einsatz kommen. Für die Übersetzung von Java zu JavaScript ist der Transpiler GWT in Version 2.8.2 Voraussetzung.

Das vollständige Beispiel findet sich im GitHub-Repository des Autors.

# data[].attributes.attachment_link.description
JavaScript ist aus der Webentwicklung nicht mehr wegzudenken. Dabei kann man Webprojekte auch gut mit Java umsetzen. 2019. Die Welt der Webbrowser-Programmierung beziehungsweise Webentwicklung ist von JavaScript und TypeScript besetzt. Die gesamte Webentwicklung? Nein, ein von unbeugsamen Open-Source-Java-Entwicklern bevölkertes Dorf hört nicht auf, dem Eindringling Widerstand zu leisten und zwar mit einem Java-zu-JavaScript-Transpiler namens GWT und J2CL (Java to Closure Transpiler).

# data[].attributes.body
Very complete introduction to GWT / J2CL / Web Platform

# data[].attributes.attachment_link.readable_text
GWT is a powerful tool, but sometimes this power might get perceived as complexity.
Long unnecessary explanation here, if you just want to start with GWT jump to the guide itself.
I think this complexity can be divided into two causes; 1. big projects are complex, and when you try to explain how to solve a complex situation, then the explanation itself is complex. 2. GWT has a huge ecosystem, and there are various solutions for each problem. This force you to take complex decisions.

But, how did we get there?

GWT borns at 2006, the evolution of the web ecosystem have been amazing since then, even inside GWT itself there have been a lot of changes, alternatives, and third parties have created amazing solutions to manage big client-side web APPs.

From 2006 to 2012 GWT was actually called "Google Web Toolkit", and it was an all-in-one solution. But since June 2012, Google handed control to the steering committee and rename the project as "GWT". Since then, GWT has been evolving into a more open tool and most of the architectural solutions embedded into GWT itself, have been overcome by third-party alternatives. Nowadays, the number of solutions is enormous, and at this point, GWT is really just the core, and it is not biased in how you should organize your code. So, GWT is no longer a web toolkit, no longer client-side framework, it is just a transpiler with a giant ecosystem around it.

For example, nowadays if you want to choose a client architectural pattern, you must choose between gwt-activities, gwtp, errai, react4j, vue-gwt, nalu, and more! or if you are looking for a transport layer you should choose between gwt-rpc, request-factory, resty-gwt, gwtp-rest-dispatch, autorest, and more!

All this complexity (only justified for big projects with experienced java teams) and all these alternative architectural solutions (which is actually a good thing) make it a bit confusing to start with GWT.

Said all this, when should I use GWT? I think that you only should use GWT in a company project if you meet these two points.

1. you have a senior Java team that already know Java and Web development (HTML5, CSS3, ES6). To develop with GWT you must know browsers, you don't need to be a JavaScript expert, but you need to know a lot around the web world (MDN is your friend).

2. you must want to share Java logic, libs, and tools that you are already using in Java (servers or Android) with the client-side or even iOS with J2ObjC). This is the whole point with GWT, sharing code between platforms. This is useful and it solves a logic-duplication, e.g. whenever you edit a field, you frequently validate with some rules, but then this is sent to the server and should be validated again. This simple but extremely common use case is beautifully solved with GWT. You write your validator code, and you use it exactly the same validation code on all platforms, giving you the responsiveness in the client side and also the security of the server side (cross-platform example).

If you already have various years of experience with GWT you can use it for a lot of things, even small APPs. But to justify the entry effort, you should satisfy those two points. But, eh! before a company project, you can just learn it for fun, and hope you are here for that!

To make this guide easier, I'm going to focus on the client side. Also, I'll make some personal decisions which I think are common and future-proof. But remember, GWT is much more than I'll explain here!. This is what I have chosen:

1. create a micro client-only APP, so no transport and no view components. Frequently guides start with a client-server app, it is much more complex and when you start with GWT you tend to confuse/mix the client and server sides as just one unique magic virtual machine. Although everything is java, and you can run the same java code in the client or in the server, both are independent runtime environments and this concept should be clear.

Also, if you create a client only APP the guide gets much smaller, and you can play with it easier. Even more, I strongly encourage to find micro-games or micro-apps written in JS or TypeScript and migrate it to GWT. This is a pretty good exercise to get used to GWT (this is, for example, a snake game I migrated from a JS project rxsnake-gwt).

2. it is managed with Maven, no IDE or plugin required, just java+maven. I'll use IntelliJ IDEA. We are not going to use any plugin, IntelliJ Ultimate has GWT support, Eclipse has a super nice plugin, but I personally prefer not to depend on any of that. Also, the problem with those plugins is that the project configuration (classpath mostly) is not easy to keep it exactly the same in the terminal or CI Vs the IDE plugin. So with this solution, Maven solution, you will be able to run, test and package your GWT in the same way in all those environments. IMO Maven is currently the easier strategy to compile GWT.

3. java 8, GWT already support Java 11, but it will be easier to make it work with Java 8 (which is still the most used version), so to keep it simple, please use JDK 8.

1. Maven basic archetype 💩

First, we create a minimal maven project. You might follow this guide or execute this command if you have maven already installed.

› mvn archetype:generate \ -DarchetypeRepository=https://repo.maven.apache.org/maven2 \ -DarchetypeGroupId=org.apache.maven.archetypes \ -DarchetypeArtifactId=maven-archetype-quickstart \ -DarchetypeVersion=1.4 -DinteractiveMode=false \ -DgroupId=me -DartifactId=hello-app -Dversion=HEAD-SNAPSHOT

I hope you know something about maven. But, if not, note that you can compile, test and package your app using mvn verify. Run it now! 😉

You can now open the created project in IntelliJ, just click open and go to the folder. IntelliJ detect maven automatically, and it will use the maven configurations to configure your project. I have reformated and removed comments, and also change the target/source java version to 1.8. Whenever you change something IntelliJ will ask you to "import changes", click it to update the project configuration. This is how it should look like:

Try again the mvn verify but this time use the IntelliJ maven menu. If you have various JDK installed, IntelliJ might be using the last one. In that case, and if you find any problem, configure JDK 8 for your project.

I start this way because I want to remark that the GWT project uses the whole Java ecosystem, and it uses similar patterns but applied to front-end development.

2. GWTify it 🌈

First, modify the pom.xml to add the GWT dependencies and the GWT Maven plugin that will add some useful goals to compile and run GWT. Add this to the dependencies section:

<dependency> <groupId>com.google.gwt</groupId> <artifactId>gwt-user</artifactId> <version>2.8.2</version> </dependency> <dependency> <groupId>com.google.gwt</groupId> <artifactId>gwt-dev</artifactId> <version>2.8.2</version> </dependency>

Those are the minimal GWT dependencies. The gwt-user contains client side java utilities, for example the EntryPoint interface that is used in GWT as an static void main(args) equivalent (more on that later). And gwt-dev contains the compiler and other development tools requeriments.

Then, you need to configure the GWT plugin and define the project as a gwt-app. Add this to the build section:

<plugins> <plugin> <groupId>net.ltgt.gwt.maven</groupId> <artifactId>gwt-maven-plugin</artifactId> <version>1.0-rc-10</version> <extensions>true</extensions> <configuration> <moduleName>me.App</moduleName> <skipModule>true</skipModule> </configuration> </plugin> </plugins>

And this at the beginning, after the artifactId and the version elements:

This will extend maven adding the GWT specific executions to the maven lifecycle. So for example, after adding this if you run again the mvn package you will notice that there are various new steps, the most important one is the one that runs the GWT compiler including our project source code and outputs the final JS. Note that this doesn't work right now, because we haven't updated the java source code! There are 2 configs, the moduleName points to the main gwt.xml file (explained later) and skipModule is used to avoid a nice but a bit "magically" utility from this plugin that will generate the gwt.xml file for you, for now, I prefer to create it manually in the next step, so I just set the plugin to not generate this file for me.

Update IntelliJ project so the dependencies get downloaded and added to the project classpath.

Now, we will update the current App class that runs in the JVM to make it run on the client side. Make App implements com.google.gwt.core.client.EntryPoint, remove the static main method and implement the onModuleLoad with the equivalent code. Simple, right? It is almost the same, main for the JVM and onModuleLoad for GWT. Your class content should be:

I think the code is self-explanatory, but... yep, getBodyElement returns the body of the web page so we can add the Hello World! and see it in our page.

Just one more thing about the App class, move it inside client package (probably your IDE has already complained about that if you have copy&pasted the previous code). This makes it a bit easier. Note that GWT apps are all about sharing code, so you probably end up with a server, shared and client packages in your project. And although this is a minimal client only example, we will follow this convention, so move it to the client package (warn: if you are using IntelliJ it can change the pom.xml <moduleName> from me.App to me.client.App after moving the App.java to the client package, but it should be me.App so check it out, sometimes IntelliJ is too smart).

Next, create the gwt.xml file called App.gwt.xml (create it in the me package, NOT in the client). This name should match the package and name that we have configured in the gwt-maven-plugin moduleName configuration. Create the file with this content:

This file is called a GWT module file. It is required so the GWT compiler knows which sources should be compiled, i.e. GWT does NOT compile everything that is in the classpath, it only compiles the sources indicated in the source tag. It is commented because the module adds those 2 lines implicitly. The source path="client" indicates that all java classes inside the package {module-package}.client will be included, and this is why we have moved App inside the client package. The inherits module is a dependency, this module depends on the gwt.user.User module and User source will depend on other modules recursively. The second line entry-point specify an entry point. So when the GWT final compilation is loaded in the web page, those entry points will be called. This is the onModuleLoad that we have created in the App class. This is the equivalent to the Main-Class manifest property for a jar file.

Finally, create an index.html file in me.public package with this content:

The first 2 lines is a "strong" recomendation. Title just optional, and the unique actual interesting line is the script. This will bootstrap the GWT transpiled code, and after some steps, it will end up calling your onModuleLoad entry point! yeah! As you can see, the name of the file is {moduleName}.nocache.js. The nocache is just an easy convention in GWT, the compiler generates various files, and some of them contain .nocache. and others contains .cache.. Files with .nocache. should NEVER be cached and .cache. can be cached FOREVER. This makes trivial to add filters to the server to add cache headers, this is called GWT perfect caching™.

Note, this public/index.html is a utility that is configured in the GWT module file, but similar to the <source path="client"/> convention, all modules contain an implicit <public path="public"/> line. And, GWT compiler will copy everything from all modules public paths to the final compiler output. BUT, my recommendation is that you try to add as less as possible to public folders. GWT has a lot of option to add managed-resources in your project, the public folder is just a drop-in that GWT copy blindly. I don't want to lose you here with explanations, but, believe me, if you add too many things into a public folder, it might be considered a code-smell. At that point, ask for help (at the end of this post I'll explain where is the best place to ask for help).

3. Package, Run and Debug 🔥

GWT transpiles code to JS and to see the result you will need to open it in your browser. But first, you need to compile and package the project. Run:

This will generate the required files and put it in the project target folder. Then, after success, open the result, in mac, you can use open target/hello-app-HEAD-SNAPSHOT/me.App/index.html in the terminal. Otherwise, open that file in your browser or drag the file into the browser window. You should see Hello World! in your browser.

What is happening here? The index.html in me.App folder is the one that we have written previously in the public package. So this is not actually generated by GWT, it is blindly copied from our public resources. This file points to me.App.nocache.js that are placed in the same folder by the GWT compiler. This file is the GWT bootstrapper. It is responsible for choosing the final client permutation. It is called permutation because GWT define a special type of compile property that can be used to choose between different "implementations", and it can use it to generate a specific final compilation results for all possible combination of all those properties, each of this combinations is called a permutation (ex. chrome+es is a permutation for the browser chrome and language Spanish).

If you are able to see the Hello World! that means that all those steps have happened successfully. I suggest to open the dev tools console in your browser and check the network panel, you can see that the browser load the nocache file, and then it loads a weird {hash}.cache.js file which is the actual permutation. You can try out another browser to see that this permutation file is different because by default GWT will generate a specific permutation per-browser. This is configurable, but I'll omit it in this guide. Between version, the unique file that should be checked is the nocache, because if something change, it will point to new hashed files (this is why cache files can be cached forever).

This is nice, but this is not so nice if you need to debug or re-load with small changes. During development, you will use a special GWT feature called codeserver. The codeserver is a server that will compile and serve the code on the fly. You can run the codeserver using mvn gwt:codeserver, but we are going to use in this case the goal mvn gwt:devmode. Ok, sorry, this is a bit confusing, but this will run 2 servers, the codeserver and another jetty just to open the index.html. I don't want to explain this, because it is a bit confusing and requires a long explanation. But for now, just keep in mind that what we really want and what we are using is the codeserver, and we use devmode only to be able to open the index.html (all this will make more sense in a future tutorial about the server side). So, please run mvn gwt:devmode. In IntelliJ, you can simply double-click in the gwt:devmode goal in the maven panel, super handy!

If you inspect the log carefully you can see both servers, the codeserver at port 9876 and the second jetty server at 8888. Start with the codeserver. Open it in your browser. For now only check that in the second point, where there is a list of modules, you see your me.App module. Hope you see it! Then, open the other server at port 8888 (both can be opened like localhost:9876 or localhost:8888 in any browser). When you open the jetty server, you will see your module directory, click on me.App/ to open that folder. This will end up opening our index.html, then it will fetch the me.App.nocache.js file but this time (and this is a bit of devmode magic) it will use a special nocache.js file that will detect the permutation and also it will communicate with the codeserver, compile the code on the fly and sent the permutation plus source codes to your browser. During a few seconds, you should notice a "Compiling me.App" dialog that will disappear on success. You can change the hello world message, e.g. remove the world part, and reload the page. This will fire the compilation again. This is the standard development lifecycle, edit and reload.

Now, I will ask you to move to chrome. You can do this in any browser, but easier to explain with one specific browser. Go to the devtools and open the Sources tab. Now find a resource (shortcut ctr+p or cmd+p) and write App to find our entry point class. You should see the Java file in the browser, this is because the codeserver generate JS source maps automatically, and chrome resolve that mapped Java sources and shows it in the devtools. Click on the RootPanel.getBodyElement line number to add a breakpoint, it should turn blue indicating an active breakpoint. Then, reload the page. If you have done it correctly, the debugger should stop in that line, you should be seeing something like this:

This is all you need to debug GWT code. But, note that you can write a lot of code in pure Java, this code, especially if you avoid the UI final layer, is trivial to run in JVM or to test using JUnit. GWT is all about sharing, and about using Java tooling, so if you are developing tools like for example a spatial-index, it is much easier and faster to test, run and debug it using plain Java. And then use it on the client side.

4. Spice it up 🌮

And this is where the personal touch gets crazy. Now I'm going to explain how to add 2 libs, a "pure" JS lib (Elemental2), and a "pure" Java lib (RxJava). I have chosen both libraries on purpose as opposite extreme cases. Using the "pure" JS libraries you should see how you can access native JS code in GWT and how easy and lightweight it is. And using the "pure" Java lib you'll see that in GWT you can use classic pure Java libraries in the browser. But, we are not going to depends directly on those 2 libs, instead we will use this dependency graph:

Elemental2 is a Google library that exposes the whole Browser API in Java. The unique minor problem with this library is that in some cases the API is not javaish enough, specifically, events and element creation requires casts which is not common in the Java world. So, although we will use this library behind scenes, we are going to depend directly on a super small RedHat library called Elemento that add those missing parts. This library is a handcrafted API for elements and events, a beautiful library that gives us the power of JS with the type-safety of Java.

RxGWT is a set of utilities to use RxJava in GWT, i.e. same as RxAndroid but for GWT. RxGWT depends on RxJava GWT, a thin GWT adapter library over RxJava. Yep, ok, you cannot depend directly on RxJava, but if you go to the repo you will see that there are just a few minor changes and configurations to make it work in GWT, almost 98% of the actual RxJava source-code is the same.
Remember my recommendation; the idea with those 2 libraries is that you get able to find JS+RxJS projects and migrate to Java+RxJava with GWT using your Java knowledge! This is an awesome way to gets used to GWT and there are a lot of fun micro reactive projects that can be improved!
To add this dependencies update the pom.xml with:

We have added a special dependency of type pom and scope import called BOM. This is a utility dependency that asserts that all dependencies defined in the BOM will be of the version specified in the BOM itself. This is useful because we can end up with various gwt-xxx libs with various versions and this might be a problem, so this BOM assert that all GWT core dependencies are at the same version.

We have added 3 new explicit dependencies, elemento-core, rxgwt and rxjava-gwt.

And finally, we have added the rxjava-gwt-repo. If you go back to the BOM you will see that we are using version 2.8.2-rx1. This is required to compile the project in a reasonable time. This version is a custom version with zero source code change compared to the official GWT 2.8.2 version but with the internal Eclipse ECJ compiler updated. This fixes a bug that makes it super slow to compile RxJava, so until next GWT gets released, if you want to use RxJava you will need to use that version. GWT HEAD-SNAPSHOT already contains the fix BTW!

Then, go to your App.gwt.xml module file and add this 2 dependencies:

If you still have the gwt:devmode running you will need to restart. There are new maven dependencies, and as those dependencies should be added to the classpath, you will get forced to restart it. It is just a few seconds, so no problem. Stop it and run mvn gwt:devmode again. Open localhost:8888 and go to app.App and check that you still see the Hello World! in you browser.

Now, update the content of App.java with:

Cool, this is much less verbose. Elements is an elemento utility, it contains all those user-friendly type-safe element APIs. Most of the types of the Elements methods return builders which are wrappers around the actual elemental2 type. You can extract the elemental2 type calling get(). At that point, you are accessing to the browser API almost directly. GWT will transpile the Java source-code to JS but a line of code like this DomGlobal.document.body.background = "red"; will gets translated to document.bod.background = 'red';, almost the same. TIP: Navigating through the elemental2 source code is a good strategy to learn how to map native API in Java GWT.

Now we are going to apply RxJava, update the content of App.java to:

Oh! the hello world message has been removed 😅! We have added a span and an event listener for mousemove events in the page document. This is a pretty simple code, but with lots of nice things! Elements.span() is an elemento builder, see how easy is to set the style and to get the element using its fluent API. HTMLElement is an elemental2 type, which is almost like using the browser API directly. RxElemento.fromEvent is a RxGWT utility that combines the elemento type-safe events with RxJava. This is the actual type Observable<MouseEvent> returned by fromEvent, i.e. it is an Observable of the concrete event type. This observable will add a new event listener on each subscription and will remove it on unsubscribe. The last line is the actual subscription that will update the el span element with the mouse client coordinates.

In this micro example, we are mixing a pure Java lib to subscribe and compose events with a browser-native API. It's so simple that does not surprise, but this is pretty awesome and powerful if you think about it 🤯! Actually, if you are an android developer and you have a lot of experience with UI, MVP, Dagger, RxJava and all those fancy things to manage your UI state? Then this should be your starting point to start applying all this knowledge to create web-based UI applications!

Just joking, no conclusion at all, only some notes of where you should go from here. Hope you like it. GWT is a super powerful transpiler. We have not even talked about how it is able to manage resources (JS, CSS, HTML, translations, images, and more) and embed it all into one single JS file. It is huge, but even ignoring all those extra utilities, just as a "simple" transpiler, it is more than enough to be useful for all those Java experts that want to write browser code.

If you like this intro, I'll try to make some client-server tutorial. I really think that client only APPs is the best starting point, but yep, people love the idea of writing the client and server in the same language and probably almost everyone using GWT is using it with this goal in mind. But, of course, this tutorial will be a pretty biased one too 😬.

There is a project to start with GWT using a spring boot approach. I personally prefer a manual approach as explained in this guide because the spring boot approach adds many dependencies and make you feel a bit like you have loose control. But if you like it, then you will love this project gwt-boot-samples and it is even easier to start with. Anyway, this project has various modern popular solutions, so even if you don't use the dependencies itself, you can get inspired and configure it manually.

Finally, my recommendation about asking for help:

stackoverflow gwt - pretty obvious, but yep, the best place to standard problems

gitter gwt - gitter chat, this is pretty active, if you have no idea or have a quick question this is the best place

groups gwt here there are a lot of old questions, also there are various specific groups for contributors, steering committee, various classic GWT libs, and more

Those 3 places should be enough. But, if you want to find more things, maybe some surprise, then go to awesome gwt where there are an infinite list of useful GWT resources, tutorial, libs, videos, blogs, and more!

# data[].attributes.attachment_link.description
GWT is a powerful tool, but sometimes this power might get perceived as complexity. Long unnecessary explanation here, if you just want to start with GWT jump to the guide itself. I think this complexity can be divided into two causes; 1.

# data[].attributes.body
In this article you can find a short intro for modern GWT / J2CL

# data[].attributes.attachment_link.readable_text
As a long time Pascal and Java programmer I love the idea of compile time check from those languages. It saves me a lot of work in the runtime later. For sometime I enjoy writing apps in Java, client-side with Swing or SWT and server-side with Enhydra XMLC, Struts, Spring Framework, some HTML, CSS and JavaScript for web browsers. But as we all know the requirements are changing everyday. AJAX came in the year 2005 to play a big role and today web browsers - with JavaScript as its native language - are becoming the new platform.

# data[].attributes.attachment_link.description
As a long time Pascal and Java programmer I love the idea of compile time check from those languages. It saves me a lot of work in the runtime later. For sometime I enjoy writing apps in Java, client-side with Swing or SWT and server-side with Enhydra XMLC, Struts, Spring Framework, some HTML, CSS and JavaScript for web browsers.