Why Don’t You Use Java for Programming the Client-Side Web Apps on Web Browser?

907 views
Skip to first unread message

lofid...@gmail.com

unread,
Sep 24, 2020, 3:02:18 PM9/24/20
to GWT Users
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. 
I would like to know from you... Java developers...

Thanks, Lofi


Andrea Stocchero

unread,
Sep 28, 2020, 6:00:10 AM9/28/20
to GWT Users
First of all, let me say I'm a Java developer and I'm using GWT since years.

Having started developing java since 1996 (with java 1.0.2), I have seen many technologies and frameworks to help a java developer can use to build a UI on web browser (like applets, servlets, jsp, jsf, webstart).
I have met GWT many years ago and it was for me the right answer to my questions to develop by a single programming language both client and server sides.
And I'm still using.

Nevertheless there are some pain points that it's important do not under-estimate.

1. Java developer has to have some skills HTML, CSS and Javascript as well.
2. Usage of JSinterop to map a javascript code is not trivial even if it's complex. It's time consuming (time that you don't have to spend using Javascript).
3. GWT widgets should be modernized (even if there are other frameworks like Domino and GWT Materials but adding complexity).
4. Java code must be well designed in order to be efficient. Javascript (for its nature) allows you to develop very fast (time means cost).

In my opinion there are other reasons why Java developers during last years preferred to learn javascript for UI, like the unclear GWT future and roadmap, but maybe less important.

Rodolfo M. Raya

unread,
Sep 28, 2020, 6:36:03 AM9/28/20
to google-we...@googlegroups.com
Hello Lofi,

Java + GWT + GXT + Eclipse was my main toolkit for over a decade. When Sencha went crazy with the price of license renewals, I started looking for alternatives.

Today my toolkit has changed to Java for backend/server side, TypeScript for client side and Visual Studio Code for code development. Communication between Java server and TypeScript UI is handled via REST interface.

Now I'm free to choose any UI style I like, my code has simplified a lot and there is a clearer separation between server and client code. There are no license costs and I don't have to deal with GWT and GXT, except for an old project I still have to maintain.

The switch to JavaScript/TypeScript gave me a huge advantage: now I can use ElectronJS to create cross-platform desktop apps that are actually web apps running on a local Java server.

I don't regret moving away from GWT + GXT. Actually, I'm quite happy with the refreshed coding experience.

Regards,
Rodolfo M. Raya


--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-tool...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/b099f262-5a83-4a1e-83d8-5cc6ef336e53n%40googlegroups.com.


lofid...@gmail.com

unread,
Sep 28, 2020, 11:33:08 AM9/28/20
to GWT Users
Hi stockiNail,

first of all thanks a lot for the feedback...

1 and 2. JsInterop: yes the mapping Java / JS  is not trivial, you need to know both worlds. Therefore I think the idea like DefinitelyTyped is not bad. They put everything for TypeScript types centralized, so everybody can make it better everyday... We need to have JsInterops files for every JS frameworks and they should be generated like using JsInterop Generator or Webtack Generator... So if someone doesn't have the capability of JS, she/he could just use the JsInterop files.

lofid...@gmail.com

unread,
Sep 28, 2020, 11:46:16 AM9/28/20
to GWT Users
Hi Rodolfo,

thanks a lot for the feedbacks!

TypeScript is not bad. After all it's coming from Anders Helsjberg creator of Turbo Pascal, Delphi, VisualJ++, C#. He is a great language designer... 😉

But actually you could use GWT to build an Electron app as you don't need to have a Java server for the transpiled code... or did you have something extra?
@Frankhossfeld told me that he has done Electron app with GWT, very easy 😉 Maybe he could elaborate here...

I never use GXT but I've used GWTBootstrap3 (Open-Source) and actually it was very easy to use, quite the same with using the integrated GWT widgets. Today Dmitrii has migrated GWTBootstrap3 to Elemental2 (https://github.com/treblereel/gwtbootstrap3). And the cool thing is that for the app devs, it doesn't change anything. You could use the same components and nothing has changed, only deep in the framework itself it uses Elemental2 instead the older technology... Maybe @Dmitrii could elaborate this...  

Thanks,
Lofi

Rodolfo M. Raya

unread,
Sep 28, 2020, 12:02:03 PM9/28/20
to google-we...@googlegroups.com
Hi Lofi,

I once used GWT + Electron + Materialize running with Jetty. That worked, but after getting rid of GWT the code was much cleaner. 

Class com.sun.net.httpserver.HttpServer is more than enough for running a Java server with REST interface on the desktop. 

Another advantage of moving away from GWT is that I don't need to work with JSInterop and things that require annotations in the Java code. Creating a REST servlet in plain Java is quite straightforward.

Regards,
Rodolfo





--

lofid...@gmail.com

unread,
Sep 28, 2020, 4:55:11 PM9/28/20
to GWT Users
I'm not sure whether I follow you... what is the difference using Java / GWT + REST and TypeScript + REST... The server part is the same. The web browser part is also the same. The difference is only the language and ecosystem you use on the web browser...

Thanks,
Lofi

Rodolfo M. Raya

unread,
Sep 28, 2020, 5:20:23 PM9/28/20
to google-we...@googlegroups.com
If the server part is a Java servlet that handles REST calls, there is no need for GWT at all. No need to deal with JSInterop and no need to deal with annotations, that's cleaner code!

If you have a server that exposes a REST API, you can write the client in anything. JavaScript is great in the browser and TypeScript improves the coding experience while sharing direct use of JavaScript libraries.

Running a Java client in the browser implies extra steps and complications. First and foremost, you can't mix Java and JavaScript libraries without wasting a lot of time with compatibility layers. That is, at least for me, the greatest advantage of using JavaScript in the browser. 

The number of libraries available for JavaScript outnumbers by orders of magnitude the available libraries you can use with Java in the browser. 

Java is a very useful language, but it's not the best one for writing code that runs in a web browser.

Regards,
Rodolfo





lofid...@gmail.com

unread,
Sep 28, 2020, 6:08:36 PM9/28/20
to GWT Users
OK, now I understand you 😉

Yes, we always have to separate the Client and the Server part. This is also GWT best practice.

But if you are using JavaScript on browser you lose the advantages like:
  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.
I've built this sample project: https://github.com/gwtboot/domino-rest-enum-date to show some reuse for Client and Server and I plan to write more articles on this topic: Dependency Injection, Mocking Test, Validation API, Business Rules - all from Server to Client.

This type of reuse cannot be done if you are using JavaScript / TypeScript on the web browser...

Thanks,
Lofi

Rodolfo M. Raya

unread,
Sep 28, 2020, 7:06:29 PM9/28/20
to google-we...@googlegroups.com
Hello Lofi,

Some loose comments:

- Another great advantage I enjoy is that I don't need Maven. Can you rewrite your example _without_ depending on Maven? And without using a library that relies on annotations?

- VisualStudio code is great for Java and JavaScript. You can also use Eclipse with Java and JavaScript, but it is not as fast.

- Design patterns are language independent. You can use them with Java, TypeScript, C++ or whatever you like.

- Although there tons of libraries you can use on the server side, Java has limited options as a client in a browser. For example, in one of my projects I need to display a PDF in the browser and manipulate its text content depending on certain user actions; there aren't Java libraries that can work in the browser and are good enough for the task.

Regards,
Rodolfo


lofid...@gmail.com

unread,
Sep 29, 2020, 3:40:22 AM9/29/20
to GWT Users
Actually I don't see any Java apps should work without Maven:
  • Why won't you use Maven? At the end everyone has to manage dependencies / versions and today you need such a tool like Maven.
Yes, design patterns are language independent.

Did you use pdf.js? And this is actually a very important part of GWT / J2CL development. In such a case we should always offer an Open Source lib for JsInterop, just like DefinitelyTyped in TypeScript... I found a GWT project for pdf.js but it still using JSNI: https://github.com/pandurangpatil/gwt-pdfjs

I think, I'll open a GitHub project for the list of libraries for GWT, similar to DefinitelyTyped but only a link list...

As you said, if everyone support implementing JsInterop files for JavaScript libs it will be very easy for Java developers to use them and they don't need to write the JsInterop files for x times...

Thanks,
Lofi

Andrea Stocchero

unread,
Sep 29, 2020, 3:57:24 AM9/29/20
to GWT Users

Lofi,

https://github.com/pepstock-org/Charba is not using Maven and it's using Ivy.

Also I'm not using it for my applications. I had to use it for the Charba J2CL showcase where I'm leveraging on J2CL maven plugin.

lofid...@gmail.com

unread,
Sep 29, 2020, 4:56:26 AM9/29/20
to GWT Users
Ahh, I mean not only "Maven" just a build tool like Maven, Gradle, Buildr, Bazel, Ivy or whatever... 😉👍

The main thing we need to manage the dependencies and versions.

Just putting those Jar files in your project and only depends on IDE dependent plugins won't help in mid term, IMHO.

Rodolfo M. Raya

unread,
Sep 29, 2020, 5:30:22 AM9/29/20
to google-we...@googlegroups.com
Hi,

I don't want a tool to manage dependencies for me because that means I may lose clients concerned with security.

I wrote a web app used by a couple of large banks. Each new release must pass extensive security tests before deploying. Code must be reviewed using SonarQube, dependencies must pass OWASP dependency checks and the test server must pass an OWASP ZAP (Zed Attack Proxy) attack.

If Maven or some other tool decides to update one of the selected jars used by my project, it can introduce a version marked as a high security risk. That's something I can't allow.

Maven can simplify dependency management, but it is a terrible security risk. 

FWIW, I use Apache ANT for building. It is "old" but works without changing project dependencies.

Regards,
Rodolfo


Jens

unread,
Sep 29, 2020, 5:37:03 AM9/29/20
to GWT Users

If Maven or some other tool decides to update one of the selected jars used by my project, it can introduce a version marked as a high security risk. That's something I can't allow.

You define a specific library version in your dependency management tool. There are also tools for Maven/Gradle that verify dependency signatures against a list of trusted signatures defined manually in the build script. That way you can make sure your download from Maven central / jcenter is the one you expect to download.

Here an example of using Gradle with signature verification: https://docs.gradle.org/current/userguide/dependency_verification.html

-- J.

Andrea Stocchero

unread,
Sep 29, 2020, 5:41:16 AM9/29/20
to google-we...@googlegroups.com
Sorry Lofi,



You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/7pltfe1w3pI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/887eea2e-3d0a-465e-94c6-e855e0e80e2bn%40googlegroups.com.

Andrea Stocchero

unread,
Sep 29, 2020, 5:41:57 AM9/29/20
to GWT Users
Sorry Lofi, I misunderstood you.

Fully agree with you!

Thomas Broyer

unread,
Sep 29, 2020, 7:45:56 AM9/29/20
to GWT Users


On Tuesday, September 29, 2020 at 12:08:36 AM UTC+2, lofid...@gmail.com wrote:
OK, now I understand you 😉

Yes, we always have to separate the Client and the Server part. This is also GWT best practice.

But if you are using JavaScript on browser you lose the advantages like:
  1. We use Java as the language

Is Java objectively the best language out there to be used as an argument that way?
 
  1. We have the best ecosystem like libraries, frameworks, build system and IDEs.

Please define in which way they're "the best".
In terms of dependency management, NPM and Yarn are probably better than Maven (but not Gradle, which looks unrivaled on that point).
In terms of build systems, I hope you're not trying to compare anything to Maven; but I also wonder how you're going to do things like PostCSS, Imagemin, SVGO, etc. do with a J2Cl toolchain. GWT does some of those (not all), but the JS frontend ecosystem is the clear winner on that point.
VS Code, and probably (I never used them for non-JVM projects) IntelliJ IDEA / WebStorm, and I suppose Visual Studio too, are absolutely great IDEs too for JS and/or TypeScript (and Go, and probably many others).
  1. 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

Wow, how condescending!
BTW, as already pointed by Rodolfo, design patterns are language independent. The "GoF" Design Patterns book has all its examples in C++ and Smalltalk, not Java; and that link you give lists exactly those patterns from the book.
I do miss Dependency Injection from time to time in JS devs, but if you really want/need it, there are ways to do it (React Context for example); and Angular does DI: https://angular.io/guide/architecture-services#dependency-injection-di
Mocking is overrated, but far from impossible in JS, including for network access: https://mswjs.io/ and even though I personally rarely do automated testing of frontend devs (and that's true of GWT too), the JS ecosystem has some quite good libraries as well (testing in a browser environment with GWT is quite "outdated" in comparison: HtmlUnit or the defunct SeleniumRC, or manually launching your browser; fortunately we're doing better with J2Cl by leveraging Selenium/WebDriver).
 
  1. … 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.

If you do need to share code, then J2Cl is for you; but that doesn't mean using Java for the whole client-side app. That's actually exactly what J2Cl was built for, in replacement for GWT inside Google: leveraging Closure for web development while being able to share code with the backend through J2Cl (and mobile native apps, through J2ObjC for iOS).

Back to your original question: 
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.

First, I don't consider myself as a "Java developer"; I'm a developer, and I'm proficient in Java (but also JavaScript and Kotlin, somewhat less in Go or Python, and I could probably still do good things in PHP if you forced me to use it).
Now let me return the question: what are the obstacles for you to use JS or TS (possibly mixed with Java through J2Cl) for frontend development?

I'm not saying you shouldn't use Java (we wouldn't be there otherwise), I'm questioning why you wouldn't use something else.
By describing yourself as a Java developer (and praising the Java language and ecosystem like you do), it looks like maybe it could be because you don't know anything else, treating Java like your golden hammer (https://en.wikipedia.org/wiki/Law_of_the_instrument)

My personal take on it is: it depends. It depends on the project (what it does, whether you need to leverage some existing Java or JS library, its size, whether you need to share code with the server and/or native mobile apps, etc.), and of course the project team and its skills.

lofid...@gmail.com

unread,
Sep 29, 2020, 10:02:43 AM9/29/20
to GWT Users
Hi Rodolfo,

thanks for the insight.

Yes, I think SonarCube is standard tool for the quality of the code today.

We are using Maven with Sonatype Nexus and use BlackDuck (https://www.blackducksoftware.com) for checking all the dependencies... Sonatype also offers Sonatype Nexus Vulnerability Scanner and Nexus Auditor for similar purpose. 

Such tools also analyze the compliance for the OSS licenses.

So you can still use Maven and it's secure.

Rodolfo M. Raya

unread,
Sep 29, 2020, 10:20:39 AM9/29/20
to google-we...@googlegroups.com
I can't choose which security scanner to use. That's already defined by clients. 

Maven is not an option. 

Regards,
Rodolfo

lofid...@gmail.com

unread,
Sep 29, 2020, 11:11:23 AM9/29/20
to GWT Users
Hi Thomas,

thanks for the feedback.

This is my point of view as a Java developer 😉I did some Polyglot projects and have written my summary here from 2011: 
In the beginning I was a fan of "use the right language for the right problem" but at the end I saw the problem in maintenance and as we all know, maintenance is the hardest part of software development. Building from scratch is always easy and fun. This presentation from Netflix is also very interesting: https://youtu.be/W3HkCF0jBZA - Key message: Polyglot is expensive. As I wrote my summary in 2011 I always thought that all the problems in maintenance is because my projects were always mid-size and such a problem would not exist in Google, FB, Netflix... but the presentation from Netflix from 2018 told me something different 😁

I know and IMHO I think TypeScript is a very good language + transpiler + tooling. But today I'm very careful to introduce new programming language, new tooling, frameworks and ecosystem. If I cannot see the clear advantages I won't do it. Just because you could write the code in more compact or functional way, it won't give you the advantages you hope.

So, to come back to the discussion, yes my opinion is biased but I hope I'm not dogmatic, this should not happen in our domain or elsewhere since I hope that we could always learn new things and adapt the good things and learn from the bad things 😉

BTW. I find it also interesting that Angular offers DI and it looks really like all the patterns we had in GWT... and I found Mocking is very important, I see a lot of developers cannot "localized" the problem to fix bugs faster. In today environment with Microservices it is a very important work to make everything in "small" part / "make everything running locally" so you could enclose the problem and fix it.

Thanks,
Lofi

lofid...@gmail.com

unread,
Sep 29, 2020, 12:52:29 PM9/29/20
to GWT Users
One thing to the Mocking framework: https://mswjs.io it looks indeed very interesting. 

In GWT I used to implement the mock implementation in "development time" and remove it in "production time" by using GWT options for different "sourcepath" and "entry point" with help of DI. It works very well. So I never have to run the "server / REST APIs" part to be able to develop the whole UI. Very productive.

.... and to try to answer your question: "what are the obstacles for you to use JS or TS (possibly mixed with Java through J2Cl) for frontend development?" here you are: 😉

(1) JS sofar is difficult to use for a bit complex UI. 

Quote from Anders Hejlsberg: 

"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."

This interview is a must read: http://bit.ly/AndersHTypeScriptInterview

You can see today that all of those a bit complex frameworks use TypeScript instead of JavaScript (VueJS 3.0, Angular, ...)

Conclusion: JavaScript is in this form today difficult to use.

(2) TypeScript is definitely very good as I already said above in this thread. But I cannot see the advantages using TS if you come from Java and can use GWT / J2CL. If you have frontend developers, yes, TS is definitely the way to go since it is more similar to JavaScript. I know that Erich Gamma moves from Java / Eclipse to TypeScript / Visual Studio Code / Electron but sofar I cannot see that VSC is better than Eclipse. So, yes, very interesting to be able to write those things also in Web browser with TypeScript and you can embed it into GitHub as a web editor.

The reason: "Theia is a framework to build web IDEs. It is built in TypeScript and will give contributors a more enjoyable experience with a programming model that is more flexible and easier to use, and makes it faster to deliver their new plugins." But I'm not sure why they could not build plugins based on GWT which is flexible and easier to use. As we know we all like to begin from scratch and don't like the idea of maintenance 😀😅

Introducing TypeScript to a Java team is a different story. The language is the smallest problem but the ecosystem, library, build, CI/CD pipeline, dependencies management, artifacts scanner, etc.(see the presentation of Netflix above). For many companies you mostly have some intelligent forms and for this purpose I don't see that TypeScript has advantages in comparison with Java / GWT / J2CL (of course we need to address the UI frameworks based on TS or GWT / J2CL as well). One thing you should not forget, on-boarding process of new developers and the ability to be a full-stack team. A team which all the developers can do everything, from frontend to server-side implementation (not to have separation between frontend and backend developers).

Conclusion: TypeScript is the way if you have JavaScript developers. If you are coming from Java with Java developers in team, IMHO GWT / J2CL is the way to go. It is also fun to work with the modern GWT web apps 😀😉👍

Just my 2 ct.

t.br...@gmail.com schrieb am Dienstag, 29. September 2020 um 13:45:56 UTC+2:

Vegegoku

unread,
Oct 6, 2020, 4:44:31 AM10/6/20
to GWT Users
Hi all
Here is my take on this,
I think for each argument from one side there is a counter-argument from the other side, and this is natural after all those are just 2 languages and 2 ecosystems, when both used to target the same goal, one will win in a specific area and lose in the other, they share the main concepts and they try to solve the same problems, they are only different slightly with the implementations.

I would say I always leave it to the use case and experience, now take a JavaScript/TypeScript developer who knows those very well and knows the ecosystem ask him to do what he used to do but in java, he will not do good and he will complain that JS is better, now get a Java developer who knows it very well and knows the ecosystem and ask him to do what he does but in JavaScript/TypeScript he will not do good and will complain Java is better.

If we take both above developers and let them showcase what they are doing with there best-preferred language for each other, they will impress each other. if you could have a developer who knows both very well, then that's a win.

The actual problem is when someone who knows Java for example very well, and does not actually know JS and out of hype he jumps to building apps with JS without spending enough time to actually learn it ( this is not cheap at all ), the same goes for JS developers.

At work I am building the UI interface for an application with Java/GWT/Dominokit, the UI application is somehow big, keeps growing, maintainable, integrates very well with our infrastructure (micro-services and micro-frontends), we deploy very often (several times per day), different teams working on different micro-frontends, we started as 2 developers now we have only working on the core part and the few microfront-ends and others working on other microfront-ends. we are being very productive.

W also have another project which is as big as the first one, but it is angular based, no microfront-end, large team (10+), the start was very very slow for this one and still until now it does not move as fast as it should be, but the issue was clear from the first few iterations in the project that it was not the language or the ecosystem, but it was the team themselves, they insist on using angular while they didn't actually know angular beyond few tutorials, they didn't know JS too, we had to teach them few things first.

The final result is what we produce in regards to the tool, 2 apps above could have lived the story revered where the Java one would be the one not doing well.

My conclusion is that you can do it with either, just make sure you are not wasting time and money. and spend enough time learning on the other side.

lofid...@gmail.com

unread,
Oct 6, 2020, 5:17:34 AM10/6/20
to GWT Users
Agree with you Vegegoku!

My experience is just like what you've said, today, if you want to build something new with Web UI, everyone want to jump to JS framework for the UI development. Always saying VueJS, React or Angular would be the best without having to look what we actually can afford --- resources and know how. Therefore I always try to say, hey you can also doing those cool stuffs with Web browser by using GWT / J2CL, you don't have to go for a complete new ecosystem... Because where I come from is an enterprise environment and we have a lot of good Java developers but very few JavaScript developers. If you want to work with Web browser you can still use the Java ecosystem...

Cheers,
Lofi

David Nouls

unread,
Oct 6, 2020, 5:21:21 AM10/6/20
to GWT Users
Hi Lofi,

In my company we are the only group that is working with GWT to develop a new customer facing application. We have a few products in maintenance mode that are also using GWT. But most new developments are using Angular.

The biggest problems we are facing with using GWT/Java for the client are:
- Lack of developers with GUI and GWT skills
- Lack of developers who are even willing to learn GWT.  GWT is seen as a dead technology after Google pushed it out.
- Management does not like us to keep on using GWT for the same reason.

I managed to convince management to use GWT for our product because we have a long history of using GWT and we had experience before with the maintenance burdens of using JavaScript in the past. And we can deliver GUI changes quite quickly (in many cases much faster than the teams using Angular).

But we do have a big problem finding GWT developers or finding people who want to learn it. And that is a very big risk for a project.

I know that there is active development going on in GWT and J2CL but, you barely see blog posts about GWT or libraries being released for it.
The gwtproject page is mostly stale, the documentation is mostly about old API's. The more advanced features takes some time to find and learn.

If you compare that with the constant release cycle and amount of info/noise I see related to Angular and other Frameworks then it is understandable that people have the impression that GWT is dead.

Michael Conrad

unread,
Oct 6, 2020, 8:19:20 AM10/6/20
to google-we...@googlegroups.com
We primarily use GWT in combination with Jackson/Jersey and Tomcat here where I work.

We have one front-end and one back-end guy (me).

Early on we were using JS on the client side, but, as soon as we started trying to do anything complex in JS we rapidly found ourselves constantly refactoring code to keep things working - and kept missing things because of the hyper nested callback nature of the mess.

We tested out GWT and immediately switched to it. The UI semantics were just *better* than what the JS libs were offering at the time, and not having to fight function closure, scope, correct typing, etc, on a constant basis was a major boost to our productivity.

The fact we can generally use POJOs shared between the client and server is also a major bonus.

At one time we even considered going to Vaadin, but then they dropped GWT, so really haven't looked at their product in a while.

If TeaVM was easy to setup via Gradle/Buildship/Eclipse, we might look at that as an additional tool to add - but last I checked it looked like a PITA. We don't use Maven as we have many many many loosely coupled projects - that we need to edit simultaneously - that don't share parent projects and Maven insists we can't configure things in such a fashion.

-Mike
--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-tool...@googlegroups.com.

Vegegoku

unread,
Oct 6, 2020, 8:21:45 AM10/6/20
to GWT Users
I am still don't know why people call the developer like this, GWT developers, Angular developers, React developers...etc.. have we ever called developers like `Spring developers`, `hibernate developers`, `Rest developers` ..etc... I would say we have Java developers and JS developers, developers belong to the ecosystem, not to the framework or the library. GWT, for example, is just a compiler, you need people who know java and the java echo system, not GWT, you can make them GWT familiar way faster than you think, you don't even need them to know this is GWT it is just Java. I have done this with few Java developers I showed them that I am building a web application with java without telling them it was GWT and they were impressed, they even built some small apps with the little information I gave to them. The same goes for JS, if you have a developer who just knows Angular, but does not know JavaScript or can't work with other JS frameworks then that is not a good fit in the team. after all the Angular is just like Spring it is one of the frameworks in the ecosystem.

Normally when I work with the fresh developers I ask them to build a sample application using whatever JS framework they prefer, then I show them that they can do it in Java without telling them it is GWT. and in many times they feel WoWed. not implying that one is better but they get wowed how they can do it in both, the good thing about those fresh developers is that they don't have a previous preference of ecosystem over the other, but in the other hand they don't know both ecosystems as they should be.



David Nouls

unread,
Oct 6, 2020, 8:47:35 AM10/6/20
to GWT Users
Let me start by stating that I totally agree that the GUI technology used is not really that important. It is after all just cross compiled to the browser platform. So knowledge of the platform is much more important.

In the organisations that I work we mostly with contractors. People are selected based on their prior experience with specific technologies because we need people to be efficient very quickly. You really need to know the frameworks very well because many GWT power features require some experience and a different way of working than what people are used to.

We do check for generic knowledge of programming, design or browser features and most of the time that drives our decision to hire someone much more than a deep GWT specific knowledge. But we often have people that refuse our offer purely because it is GWT. The reason is that they see it as a bad career move to work in a project that uses a framework that they think is dead. I’m not making this up, we had this response many times. And it makes sense from their point of view. Contractors need to stay relevant in the market. CV's are filtered on buzzwords and technologies. I sometimes feel anxious as well since I have many years of GWT knowledge, but I know that all companies are looking for other frameworks and don’t care about the arguments.

In the backend the focus on frameworks is a bit less extreme because they are all based on the same language and the frameworks like spring and EJB are very old and well understood and part of a vibrant community. If you are still depending on Struts and handcrafted SQL/JDBC on the server side then you will probably meet the same resistance to hire people.
--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-tool...@googlegroups.com.

Vegegoku

unread,
Oct 6, 2020, 9:00:06 AM10/6/20
to GWT Users
I am in the same situation, But this is wrong. and it is not that hard to make any java developer work on GWT especially if they claim to know some frontend since that implies that they know HTML,CSS, JS which is more important than knowing GWT.

lofid...@gmail.com

unread,
Oct 6, 2020, 1:42:50 PM10/6/20
to GWT Users
Hi David,

thanks for your feedback.

Yes, agree with you with all your points... I'm not sure what we could do to show that we are still alive... 😀 At the moment we have following:
  • Colin with Vertispan always invites us for an online meetup, here are the results so far: https://www.youtube.com/channel/UCbTjCnaZEusVEAPBMtnz9Fw
    • Here you can ask everything about GWT / J2CL so you have the access to the GWT / J2CL experts.
  • Some of us try to spread the words by writing articles, etc. and also trying to apply for some conference talks. So far not yet successful with conferences.
  • I try to write a short / simple deck and it could be used to show the advantages of GWT / J2CL to the managers, see https://bit.ly/gwtintropresentation
  • I try to build a "padlet" for Modern GWT / J2CL: https://bit.ly/GWTIntroPadlet
What we could do more:
Thanks,
Lofi

lofid...@gmail.com

unread,
Oct 6, 2020, 2:09:53 PM10/6/20
to GWT Users
Also agree with general opinions in this thread:
  • Actually it is enough to know Java and its ecosystem.
  • The APIs of those UI frameworks + Web browser as a platform (Web APIs) have to be learned by all Java or JavaScript or TypeScript developers anyway.
  • As I saw it by myself, it is actually not hard to learn those APIs, see https://bit.ly/GWTModernExperiences
I also agree with CVs and contractors, like what David said. But last time I also didn't think that searching for VueJS developers is also not that easy. At the end you just take a developer with JavaScript and maybe Angular know how... 😀So, you hope that the developer will learn the VueJS fast and this is important, today if you want to learn Spring Boot you have enough resources on Internet, also VueJS / Angular / React. But what about GWT? A lot of things are old...

So, yes, we need to update gwtproject-site and need to create a lot more resources to learn GWT / J2CL and of course, new versions, new versions - and always release to Maven Central... to make the developer experience outstanding...

Thanks,
Lofi

Craig Mitchell

unread,
Oct 16, 2020, 12:16:36 AM10/16/20
to GWT Users
> Why Don’t You Use Java for Programming the Client-Side Web Apps on Web Browser?

Because of React.  Companies are investing in creating reusable React components.  Reacts virtual DOM makes it very difficult to integrate a React component into a GWT app, so you end up just using React, and coding in JS / TS.

lofid...@gmail.com

unread,
Oct 18, 2020, 10:56:08 AM10/18/20
to GWT Users
Thanks Craig for the info...

I'm not familiar with React (only Hello World 😉)

Can you integrate React with these GWT React frameworks? So write your components in Java and integrate them back into React JavaScript?

Peter Donald

unread,
Oct 18, 2020, 5:15:42 PM10/18/20
to GWT Mailing List
On Mon, Oct 19, 2020 at 1:56 AM lofid...@gmail.com <lofid...@gmail.com> wrote:
Thanks Craig for the info...

I'm not familiar with React (only Hello World 😉)

Can you integrate React with these GWT React frameworks? So write your components in Java and integrate them back into React JavaScript?

It may be possible in react4j to publish a java component as a react component but not without significant overhead/boilerplate. It is also possible to consume a js react component from within react4j with a little overhead and we built some of our early apps like this. However, react4j's sweet spot is when the majority of the application is written in java.

With gwt-react it is much easier to both consume js components and publish java components ... except for the normal constraints of publishing java to js. My guess is that the sweet spot for gwt-react is for applications that combine js components into a java app but I have never used it in anger.


-- 
Cheers,

Peter Donald

Woyce Batkins

unread,
Dec 17, 2020, 8:01:24 PM12/17/20
to GWT Users
I am new here, so hello everyone.
I am very interested in this topic. I have gotten tired of the whole javascript ecosystem. I did not know that you could easily have GWT run only on the frontend and used jee/spring/whatever on the backend as you please. I always thought it was a client-server bundle.
Is there a tutorial that shows how it can be done?
How is the compilation speed for code-change/webpage-refresh? I have done scala many years, so I understand how frustrating it can be, even though scala is amazing.
Thanks

Frank Hossfeld

unread,
Dec 18, 2020, 10:44:32 AM12/18/20
to GWT Users

Lofi has some interesting things to look at:  
* GWT Awesome Library List (Gwit a LiLi)
* there is also a boot starter for gwt, but I do not recall the name.

Good starting points are:
*  gwt-maven-archetypes: https://github.com/tbroyer/gwt-maven-archetypes
* There is also are archetype creator from DominoKit
* Nalu project generator: http://www.mvp4g.org/boot-starter-nalu/BootStarterNalu.html (Disclaimer I am the author)

And a good place to ask your questions: https://gitter.im/gwtproject/gwt

Hope that helps.

Woyce Batkins

unread,
Dec 18, 2020, 7:30:44 PM12/18/20
to GWT Users
Thank you very much. I ll give it a try.

lofid...@gmail.com

unread,
Dec 22, 2020, 6:40:39 AM12/22/20
to GWT Users
We also have a Padlet for GWT 😉

I try to collect all the information about GWT / J2CL on one Black Board: https://padlet.com/lofidewanto/gwtintro

There are articles, presentations, groups and other information for a modern GWT / J2CL development...

Hope this helps!

lofid...@gmail.com

unread,
Dec 22, 2020, 12:26:53 PM12/22/20
to GWT Users
Some tips I could say:
  • GWT is a transpiler / compiler to JavaScript, so the result only runs on Web browser, no server component. Server container or Web server only used for delivering the HTML, JS and CSS. So actually you could just use the result JS from the file system and make a double click on the HTML file to open your web app (JS).
  • The simplest example I build is the Java Calculator from this article: http://bit.ly/WebJavaStory. In this simple Maven example you can see how to run the web app, how to code, transpile and unit test and also to debug the simple calculator all with web browser.
I'm using GWT since 2006 / 2007 and until today I haven't seen any comparable tools which makes your work very productive, especially as a Java developer.

Hope this helps! Have fun!

Vassilis Virvilis

unread,
Dec 23, 2020, 3:16:49 AM12/23/20
to google-we...@googlegroups.com
Hm the thread was about why not using java for frontend development but now has general tips for GWT.

The padlet is cool. Thanks for assembling it.

My 2c.

I have used GWT RPC in the past but I was not happy with it. The main reason was that I couldn't decouple server and client from GWT dependencies. The closest you could make was with an intermediate project that hosted the interface files.

The issue was solved for me with RestyGWT in the client and Apache CXF/Rest in the server. Totally separate and the only files I share are my POJO files.

Sharing POJO definitions between client and server is the biggest advantage of GWT for me along with static typing in the frontend. Can't live without these two.

Maybe there is a way to automatically create or define POJOs that is language independent so I could completely decouple frontend from backend. I haven't found such a way that is not completely dynamic and which throws the IDE search and usage features out of the window.

Hope that helps.

  Vassilis




--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-tool...@googlegroups.com.


--
Vassilis Virvilis

pavel....@gmail.com

unread,
Jan 24, 2021, 6:36:40 AM1/24/21
to GWT Users
Hi, I see that everyone leaves 2c, so I will do the same.
But before few words about my background - 6 years with GWT+SmartGWT and now 3 years with VueJS + Vuetify + Typescript.

Definitely, it's much faster to prototype an application using VueJS.
To manage the state(Vuex) and routes(vue-router) is simple and does not matter what UI components you are going to use.

But, in the long-term development, I see that maven is better than npm - simpler to set up a multimodule project with some common settings and dependencies.
In JS world npm does not support modules. Yarn workspaces help a bit but it works just for private projects(no way to deploy it to the remote repository).
Typescript helps to write a code but in 99% of cases, 3rd libraries contain only d.ts files without Javadoc. So, you need to open a website with documentation because it's not clear what the library does.
Refactoring - forget. Event idea can't properly resolve usages of your methods.
After webpack to understand where has the error happened it's like a mission impossible. 
Testing - better to write functional code because to mock classes is not so easy as with mockito or easymock.
With JS/TS you write code slower because IDE does not resolve or properly resolve what to import, especially if code comes from another module.

So, in long term, I guess GWT provides better and simple development and support.

середа, 23 грудня 2020 р. о 09:16:49 UTC+1 vas...@gmail.com пише:

Frank Hossfeld

unread,
Jan 24, 2021, 2:11:29 PM1/24/21
to GWT Users
A few years ago, a client of mine was thinking about switchung to Vue. So, I startet learning Vue. To do so, I search the internet, bought a book, install npm, code the examples and so on ... 

Two or three weeks later, my virus scanner (oh yes, I am a Mac user that has a virus scannner ... my client requested it) found two trajans which were trying to transfer Bitcoins, loaded via npm initiated by my Vue development. 

After some research I get to know, that this is a common issue, when using npm. Bad Boys trying to conquer a repo, add bad code, deploy it and distribute the files via npm. 

I think, you need to get some attention on which file you load. Or, better have a clean room where all the js files are located (after an audit ...)

Not sure, if this is a common issue or just due to my carelessly ... but it makes my scare.  

Craig Mitchell

unread,
Feb 13, 2021, 6:59:20 AM2/13/21
to GWT Users
> Sharing POJO definitions between client and server is the biggest advantage of GWT for me along with static typing in the frontend. Can't live without these two.

Not needing POJOs in a dynamically typed language (JS), could be considered an advantage, due to less code needing to be written.  Although, I personally agree that a static typed language is better, even if it is more code.

Zhang Alex

unread,
Mar 3, 2021, 8:45:38 PM3/3/21
to GWT Users
In the past years, My company build a larget HIS frontend platform based GWT ,  The large means: lot of module,  code by java , output to javascript seems beautify
But, when the application more bigger, the compiler package speed more slower;  debug, publish will wait long time...
Recently, we decied to replace gwt with other pure js frontend(like extjs), in order to slove these problem .

lofid...@gmail.com

unread,
Mar 4, 2021, 5:39:14 AM3/4/21
to GWT Users
Thanks for the information!

Why don't you just separate the project (Maven, etc) in smaller projects and integrate them just in the HTML files DOM / ScriptInjector?

So in general you could build many Micro UIs (many JS files) in GWT and integrate them in one HTML DOM or put them together through ScriptInjector.

lofid...@gmail.com

unread,
Mar 4, 2021, 5:46:50 AM3/4/21
to GWT Users
... and in the beginning everything is small and fast but you'll see the same problem (also with pure JS or any other technologies) if you build one huge app...

This is similar to the backend problem... Monolith vs. Microservice --> Monolith UI vs. Micro UI...

Zhang Alex

unread,
Mar 4, 2021, 8:32:39 PM3/4/21
to google-we...@googlegroups.com
In fact, We just did it like you're saying, every project composes with a different maven module. 
But , one difference is , the final output material is one xxx.nocache.js . the sense may cause build speed too slowly.

Could you describe " separate the project (Maven, etc) in smaller projects and integrate them just in the HTML files DOM / ScriptInjector and build many Micro UIs (many JS files) in GWT and integrate them in one HTML DOM or put them together through ScriptInjector" in more detail.

Cheers.

lofid...@gmail.com <lofid...@gmail.com> 于2021年3月4日周四 下午6:39写道:
--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-tool...@googlegroups.com.

Zhang Alex

unread,
Mar 4, 2021, 8:33:03 PM3/4/21
to google-we...@googlegroups.com
agree.
Cheers.

lofid...@gmail.com <lofid...@gmail.com> 于2021年3月4日周四 下午6:46写道:
--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-tool...@googlegroups.com.

Zhang Alex

unread,
Mar 4, 2021, 8:38:51 PM3/4/21
to google-we...@googlegroups.com
and have other reasons
1. debugging  speed reason
2. Is it possible to hire someone who is willing to use GWT? 

lofid...@gmail.com <lofid...@gmail.com> 于2021年3月4日周四 下午6:46写道:
... and in the beginning everything is small and fast but you'll see the same problem (also with pure JS or any other technologies) if you build one huge app...
--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-tool...@googlegroups.com.

lofid...@gmail.com

unread,
Mar 5, 2021, 4:21:43 AM3/5/21
to GWT Users
  • I'll try to make an example of simple MicroUI, actually I already plan this and the project is already there on Github ;-) https://github.com/gwtboot/microfrontends-example
  • Debugging: It is as fast as debugging JS webapp. You just debug on browser, see: https://bit.ly/WebJavaStory -- Debugging
  • Hiring devs: OK, I don't know but in my experience you just need a Java dev who wants to learn new framework. If you are not doing "crazy things" in browser, instead just doing business app development, should be just fine to have Java devs with the "energy" to learn a new framework. Following knowhow is a must:
But this was my experience, maybe other could share their stories?

Thanks,
Lofi
Reply all
Reply to author
Forward
0 new messages