State of GWT?

135 views
Skip to first unread message

Gordan Krešić

unread,
Sep 29, 2025, 10:18:06 AM (5 days ago) Sep 29
to google-we...@googlegroups.com
I know the topic is broad (and, hopefully, click-baity), but I'm wondering what would be community's recommendation on how to use GWT in 2025?

For reference, I used GWT since Paleozoic (v1.6?), but left last project using it in 2022. Now I have to build one webapp prototype and I'm wondering if my GWT-fu can still be of any use. Could someone advise what would be the best way to use GWT in 2025?

From my homework on the topic, I can see that GWT project itself is still maintained [1], as well as Elemental2 [2] and some other libs [3][4]. However, as https://www.gwtproject.org/ is severely outdated (I can't remember it was ever up-to-date, to be honest), I still have a lot of open questions:

1. I remember GWT was in the process of splitting it into many (J2CL-compatible) submodules, but other than searching Maven Central, I can not find any list of them?

2. Is there any better way of integrating recent JavaScript libraries other than manually writing my own Elemental2 wrappers? I know Elemental2 bindings are auto-generated from Closure, so I'm hoping that there may be some tools that could generate them at least from TypeScript as well. Not that there were not efforts [5]. My prototype would have to work with maps and although I see that gwt-ol [6] is still maintained, I'm wondering what would be my options if I have to integrate with, for example, Windy API?

3. J2CL seems to remain Google's internal toy, right?

Thanks for any time you decide to spend reading and (hopefully) answering this.

Cheers,

-gkresic.

[1]: https://github.com/gwtproject/gwt
[2]: https://github.com/google/elemental2/
[3]: https://github.com/DominoKit/domino-ui
[4]: https://github.com/NaluKit/nalu
[5]: https://github.com/ltearno/typescript2java
[6]: https://github.com/TDesjardins/gwt-ol

Jens

unread,
Sep 30, 2025, 7:17:26 AM (4 days ago) Sep 30
to GWT Users
Generally GWT SDK is in maintenance mode which means there is no incentive to add new features to GWT. Most current work is done in the compiler, emulation and distangling code dependencies to eventually use maven/gradle instead of ant.

My main pain point with GWT today is actually CSS. CSS is moving pretty fast and GWT is stuck on an old Closure Stylesheets library. Beside that if you really just want to make a throw away prototype I think I would learn a different JS framework for making such prototypes because you simply have to type less code as in GWT with Java. But of course it also depends on the complexity of the prototype as well.


1. I remember GWT was in the process of splitting it into many (J2CL-compatible) submodules, but other than searching Maven Central, I can not find any list of them?

Many of them which are considered completed are available on github at https://github.com/orgs/gwtproject/repositories?language=&q=&sort=&type=all

Colin made a google sheet back in the days at https://docs.google.com/spreadsheets/d/1b1D9fEqRh5lZ8cqMJtYoc_25rfTRvsuJkTtS2vjgi3o/edit?gid=0#gid=0 but it might be outdated. I lost track about the status of not yet completed projects.


 
2. Is there any better way of integrating recent JavaScript libraries other than manually writing my own Elemental2 wrappers? I know Elemental2 bindings are auto-generated from Closure, so I'm hoping that there may be some tools that could generate them at least from TypeScript as well. Not that there were not efforts [5]. My prototype would have to work with maps and although I see that gwt-ol [6] is still maintained, I'm wondering what would be my options if I have to integrate with, for example, Windy API?

Personally I just write JsInterop by hand because most of the time you don't need 100% of the API of a third party JS library. Generated code can also be a bit clunky as seen in elemental2 . Beside the generator you mentioned I don't know any other TS -> JsInterop generator. The one of Google is Closure externs -> JsInterop. 

 
 
3. J2CL seems to remain Google's internal toy, right?

Well you can use it but personally I think you are right, it won't be very popular outside google. 


-- J.

Craig Mitchell

unread,
Oct 1, 2025, 12:48:31 AM (3 days ago) Oct 1
to GWT Users
> Now I have to build one webapp prototype and I'm wondering if my GWT-fu can still be of any use. Could someone advise what would be the best way to use GWT in 2025?

If you want create a quick and easy webapp prototype, I recommend using https://github.com/NaluKit/gwt-maven-springboot-archetype to generate a framework based off Spring Boot.

IMHO: GWT's ability to shield you from needing to write JavaScript, is as strong as it has ever been in 2025.

Frank Hossfeld

unread,
Oct 3, 2025, 5:37:49 AM (yesterday) Oct 3
to GWT Users
A few years ago, i was thinking about moving to React or vue. So I started some pocs to see how thinks work. At the end npm has loaded some malicious code on my computer. Spooky. That's is one of many reasons to stay with GWT. Next, I am familiar with GWT. I know the pitfalls and drawbacks. We'll use GWT, domino-ui, domino-rest, Nalu & Spring Boot and we are happy with it. So, starting a new project, that would be the tool stack. We build business software and get paid for transforming business needs into code. With that tool stack we can create well maintainable and stable software quite fast. We have an incredible low error rate and at least nearly no downtimes.    
 
 Jens is right, GWT is in maintenance mode. After GWT was handed to the community, all work is done by a few people (like Colin, Jens, Thomas, Ahmad, etc) without getting paid. Not sure, but I think, in case more people starts sponsoring the project (https://opencollective.com/gwt-project) this might change.

RobW

unread,
4:50 AM (6 hours ago) 4:50 AM
to GWT Users
Very much our experience. We build commercial apps, and having used GWT for years we know it inside out, so we can build things fast. Yes, it's in maintenance mode, but that also means it's very stable and throws us zero curve balls. We've looked at other frameworks, but all seem to end up with way more code for similar sized solutions - and we're not JS experts, so working in a single Java codebase is way way more comfortable for us. We do divert into JSNI at times to wire in some libs (codemirror, gridstack etc). But we create minimal bindings for just the API calls we need.
Reply all
Reply to author
Forward
0 new messages