Our 10+ year journey with GWT (+ job opening)

[Alexander Bertram]

Dear all, 

I hope this email isn't too off-topic, but I wanted to share an opening for a job on our team with a large GWT component.

https://jobs.bedatadriven.com/software-engineer

The first version of our product, ActivityInfo, a data collection and analysis platform for humanitarian relief, was built with GWT, GXT and Google Gears in 2009 and seriously would not have been possible without GWT. 

In 2018, nearly 10 years later, we looked at the amazing js ecosystem and considered moving to Typescript or Elm.

Instead, we decided to keep the bits that we loved about GWT: the typesafety, code-reuse with the server, i18n, code splitting, linkers, and the amazing compiler, and add SCSS for styles and our own port of Preact + rxJava-like reactivity for dom manipulation using Elemental2.

Three years after the start of ActivityInfo 4.0 we couldn't be happier with the choice, and are more productive than ever. 

If you're an experienced GWT developer that would enjoy the challenge of a working on a modern GWT codebase, I hope you'll consider joining our team!

Best,

Alex

[Marteijn Nouwens]

We also have choosen and stuck with gwt for the same reason. Productivity is really important. We come across angular but it still is not the same. === really :-)

I am an experienced gwt developer with 12+ years :-). Has is been that long. Must be, my youngest was just born when we launched our daycare product written in gwt. 

And located in the Netherland. But not looking for a Job. :-( 

But I will send your link to some people I know.  

Happy to help you along.

Marteijn

Op zondag 20 december 2020 om 16:15:55 UTC+1 schreef Alexander Bertram:

[David Nouls]

Hi Alex,

Same story here. I have been working with GWT since it first came out. For our current project we again opted for GWT because we share a lot of code between client and server and productivity is high.

I’m not available at the moment (maybe end of next year)… but living in Belgium/Leuven I don’t think that is doable. Relocation is not an option. Good luck finding people, there are not a lot on the market.

Groeten,

David

--
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/46240bd9-f716-4448-a481-acfc87229f8fn%40googlegroups.com.

[Vegegoku]

We are in times where working remotly id actually a good option.

[Segun Razaq Sobulo]

I've been using GWT for 7+ years (with appengine java backends) and actively looking for a job. I'll push my resume.

Thanks

[Alexander Bertram]

Nice to hear from everyone!

Here's to the next ten years :-)

Best wishes for 2021,

Alex

[Wasin S.]

Yes, almost 10 years for me too and production application  running for 3 years.
GWT 2.6.1 + Eclipse 4.8.  Tomcat8 + MySQL5.7  + Java8 + JasperReport
my next 10 years plan is  move to TypeScript + VueJS.

[Vegegoku]

I wonder if that will actually last for the next 10 years.

[RobW]

Our web front end is on 15 years with GWT as of this year, and we're expecting 5 more with luck. So we'll hit the 20 year mark if all goes well

[lofid...@gmail.com]

@swas...

<quote>

Yes, almost 10 years for me too and production application  running for 3 years.
GWT 2.6.1 + Eclipse 4.8.  Tomcat8 + MySQL5.7  + Java8 + JasperReport
my next 10 years plan is  move to TypeScript + VueJS.

</quote>

After 10 years, will we still be able to see TypeScript + VueJS? 😂

Cheers,

Lofi

[Vegegoku]

I think TypeScript is here to stay and it might improve a lot, for Vue it is growing but maybe it is up to when the next framework show up, we xan also put the PWA in the picture and the multiplatform from a single source code base, WASM ..etc.. recently things were moving really fast that we could even expect some extreme changes in the coming years.

[Thomas Broyer]

Why did you bet on GWT 10 years ago and wouldn't bet on TypeScript nowadays?

(fwiw, TypeScript is already 8 years old; Vue.js is 6 years old, React is 7)

[lofid...@gmail.com]

IMHO that's the problem with frameworks / languages. If they are "strong enough" they won't be gone... I don't think that TypeScript / Vue.js / React / Angular etc. will be vanished. They will stay forever just like COBOL and other technologies like Borland / Embarcadero Delphi Object Pascal. My comment above was a joke, because I don't know what will happen in 10 years. There will be another hot things. Maybe we move completely on the native client development instead of Web browser? But who knows...

So at the end of the day the devs need to maintain apps with the zoo of frameworks and languages. 

Scary if you see this history of web frameworks: https://raw.githubusercontent.com/mraible/history-of-web-frameworks-timeline/master/history-of-web-frameworks-timeline.png

I think, it's time that the development of apps / Web apps should go higher in the abstraction level to be technology / framework independent. PIM (Platform Independent Model) anyone?  😉

BTW.: I still have JSPs in production. Also COBOL 😅

Cheers,

Lofi

[David Nouls]

That is actually a good point indeed. We also have very old tech in production including some ALGOL.

I do have the impression that the JS Frameworks race has been slowing down a bit. Sure there will always be some new ideas, but the big frameworks are there for quite some.

At least with GWT/Java it is rather easy to maintain! GWT does not change much, sometimes that is an advantage.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/2c7b6eec-67cd-4361-8777-18490db3dba7n%40googlegroups.com.

[Marco Castillo]

It is nice to hear all this experience with GWT. I would like to share mine. I'm based in Guatemala, our development team develop a product, Axeso, it is a product that enhances the security in Google Apps (next GSuite, now Google Workspace). We develop the administrator console using GWT, the backend in Google App Engine using java mainly and NoSQL databases, and at this time (almost ten years later) we're deciding what new framework would be the successor of GWT.

I was considering https://gwtmaterialdesign.github.io/gwt-material-demo/, we would like to give our console a more material design look. And with all the stories I just read, maybe I will ditch React (it was going to be our choosed framework for substituting GWT) and kept GWT.

Regards

Marco

[lofid...@gmail.com]

@Marco Castillo: nice story, thanks for sharing!

In December I tried to understand the concept behind the JavaScript frameworks especially Angular, Vue.js and React and found out:

- Components / programming model: we have components in Java / GWT already for a long time

- Dependencies: all those frameworks need dependency management like Maven, so no difference

- Compiler / transpiler / optimizer: all of them use a lot of these tools, no difference than development in Java / GWT

All in all, the idea of just "lightweight" JavaScript frameworks development without all those tools is - for serious Web apps - impossible.

Here is my article:

https://medium.com/swlh/web-apps-ui-development-trend-in-2020-components-to-rule-them-all-a9e2cb32d27

I'll try to write the next article about GWT / Java which already has all those capabilities yesterday and today. 

Thanks,

Lofi

BTW. As GWT developer I feel that Angular has the same programming model concept to GWT with the components and design patterns. Very similar concept only with different tech stack: TypeScript

[RobW]

Similar decision process for us. After a lot of research into Vue, React etc we decided the switch over and learning curve just didn't pay back. Our app scaffold in GWT is actually really solid, and it's easier for us to add more modern approaches like a JSON based REST API and newer layouts and widgets (like Material Design) into that framework rather than throw it all away. A big benefit is we can do it step by step, panel by panel too if we want - making it much more manageable to refresh the overall app.

[Jofrantoba]

Hi, Alexander.

I'm jofrantoba. I'd like working but my english is basic.

My best is the reading. 

atte @jofrantoba

https://youtube.com/playlist?list=PLAFyX6INxrfkdBLuF_oNlPlQj1nYhEYdg

GWT 2.7  RPC/RequestFactory

Google App Engine /Java

http://devolpay.com/#X

--

[lofid...@gmail.com]

@RobW: Thanks for the insight. 

I also think that such an app modernization process is the most reasonable way.

I never had a chance in my job as software developer and architect to rework the whole important apps just with some new technologies without additional business values. In my experiences such a project will fail, since at the end everyone will ask "So what's new? The UIs don't change at all?" and such an answer like "Oh we change the technologies under the hood, but the UIs look the same" won't help... OK, I never work for Google which has the power "money and resources" to re-write everything from scratch 😂

I also haven't seen that just because of using new technologies your apps could be extended easier than before.

One thing I always see as a good value is to take apart a huge app and build smaller deployable parts. 

I've written this article as an example: https://dzone.com/articles/enterprise-applications-customization-with-microse 

Cheers

Lofi

[Peter Donald]

FWIW - about 3 years ago we started to rewrite a suite of apps built using a collection of technologies from AWT/SWING Desktop apps, jruby/rails, jsp/jsf, gwt applications and some of the suite has been in operation since 2001 (with the build starting in 1999). We decided to go to Typescript+Mobx+React+GraphQL as the core frontend tech stack after a reasonable evaluation period but after about 12 months of development ... as we added tooling to support the scope of the projects (i.e. closure compiler and extensive build tooling) we found that the development experience still did not comparable to GWT. 

Js has so many easily accessible libraries that really are where all the interesting ideas are being explored but getting them production ready was such a PITA and the development turnaround time at the size we were working with was on par with equivalent gwt sized apps or worse. Small, quick prototypes are so much faster when you can lean on the js ecosystem but once you need to get development working smoothly with lots of not necessarily great frontend developers and java is so much nicer. 

We ended up wrapping react in java, wrote our own mobx-like library. Once we switch to GWT3/J2CL (*and have multiline strings in java!) then I can't imagine there is much in the js ecosystem that we will miss sans the variety of libraries.

While the JS frameworks are slowing down, I would expect a cambrian explosion to occur when wasm comes of age which is soon I hope. The J2CL are already working towards that target so I hope we can largely piggy back on their work but keep with the same GWT/j2cl codebase we work with now for at least another 15 odd years.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/25324b20-e0d8-4a7b-a292-9782066fdf1b%40Spark.

--

Cheers,

Peter Donald

[Vassilis Virvilis]

Hi Peter,

That's a very good insight. Thanks for sharing.

I do not have a +10 years product in GWT yet (6+)  but I have +10 overall experience. What looked like a game changer for me was the new jsinterop some years ago.

I have created some bindings (some good enough, some not so good, some awful) to the underlying user facing javascript libraries. What I am missing is a clear way to contribute these bindings in a more centralized way.

I asked here one or two times but IIRC the answer was there should be an automatic way to import js libraries. Maybe through DefinitelyTyped typescript https://github.com/DefinitelyTyped/DefinitelyTyped definitions? not sure if it is even possible.

I am not aware of such a way or at least a roadmap. Do you think that with the WASM target the jsinterop binidings will be more automatic / easier / less manual?

Any further insight will be much appreciated.

 Vassilis

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/CACiKNc4QQnbo4cJARmYT_fPWEAJ_iK6o8oXiJi0Z%3DT7cVgn%3D5g%40mail.gmail.com.

--

Vassilis Virvilis

[Peter Donald]

On Sun, Jan 24, 2021 at 8:17 PM Vassilis Virvilis <vas...@gmail.com> wrote:

I asked here one or two times but IIRC the answer was there should be an automatic way to import js libraries. Maybe through DefinitelyTyped typescript https://github.com/DefinitelyTyped/DefinitelyTyped definitions? not sure if it is even possible.

There are a few problems that we became aware of quickly. To get dead code elimination / minimization / optimization you really need to have a consistent type model for all code within an output target. When we experimented with this approach we used the same model that I believe is used inside google. i.e. closure typed javascript is the definitive representation, java is compiled to closure compiler annotated js via j2cl, typescript is compiled is compiled to closure annotated js via tsickle, jsinterop-generator converted closure annotated code into jsinterop annotated java and then closure compiler was responsible for optimization/assembly.

However you could rarely take an off-the-shelf typescript library and import it into the mix as tsickle was usually on an older version of typescript or the library was not completely typed or it used some typescript features not supported by tsickle. This usually meant that the library had to be patched and/or was not stripped of unused code and/or was not optimized etc. We often ended up writing our own library event when there was an equivalent available in the js ecosystem. (Which is no different to what we have to do with java-to-js solutions but generally the tooling available for long term maintenance is less good for js than for java). Even when all the stars aligned we often found that closure could not detect some code was unused due to the way js works and so we had to patch code so we could eliminate unused code by changing how we used a library. This is probably one of the reasons we ended back writing code in java. We could not use the existing ecosystem and had to work with a limited ecosystem if we wanted high-quality, minimized code .

So while it may be possible to use existing libraries from typescript and/or DefinitelyTyped, unless the typing is 100% then bugs will creep in and you won't be able to eliminate unused code. Where we are using js libraries we tend to write our own bindings or we just rewrite the functionality we need in java and get all the benefits provided by the compiler.

I am not aware of such a way or at least a roadmap. Do you think that with the WASM target the jsinterop binidings will be more automatic / easier / less manual?

WASM is still a moving target and I haven't tracked it of late ... but there were specs that defined the inter module API which would be trivial to automatically generate bindings for. There was also primitive tooling that did dead code elimination and optimization between modules (by essentially removing the unused API ingress and re-running intra module optimizer to strip dead code) but I don't know how good it is. I don't know if it will ever be possible to do whole application optimization and combining into a single module but I am not sure that will be much of a problem in practice. At least not for languages that do not have much overhead during compilation.

Anyhoo - it will be an interesting time regardless.

--

Cheers,

Peter Donald

[Vassilis Virvilis]

Thanks for the insightful reply. You seem to focus on optimization which I agree is a worthy target.

I was focusing on development practices and reuse. For example I have created bindings for jQuery. I would love to just use somebody else's bindings. But here is the thing. I didn't need jQuery for me or my application. I needed it for DataTables.net. I created bindings for them too and jQuery was a requirement.

Having done the exercise I believe that it is impossible to reuse jQuery from another source and DataTables.net from another. They have to be developed in sync or at least first the jQuery and then the DataTables.net bindings. It looks like a huge waste of effort to me and not very scalable regarding ecosystem growth if every gwt developer develops his own bindings every time.

But what would be a proper solution here? Create a mega project to coordinate smaller bindings only projects? Provisions have to be taken for packaging and namespaces in order to avoid collisions and a ton of other things that are massive headaches.

Thanks again.

--

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/CACiKNc7Z%3DC3F0cXTggkPhPFeh8%3D5M%3DYpE45%3DWfnCWJzSaBFGgw%40mail.gmail.com.

--

Vassilis Virvilis

[lofid...@gmail.com]

@Peter: Thanks a lot for your comprehensive insight, like always! 👍

One production ready WASM I know is from .NET: https://visualstudiomagazine.com/articles/2020/05/19/blazor-webassembly-3-2.aspx 

But I never tried it...

[Peter Donald]

On Tue, Jan 26, 2021 at 5:08 AM Vassilis Virvilis <vas...@gmail.com> wrote:

Thanks for the insightful reply. You seem to focus on optimization which I agree is a worthy target.

It is the limiting factor when building at large scale.

 

I was focusing on development practices and reuse. For example I have created bindings for jQuery. I would love to just use somebody else's bindings. But here is the thing. I didn't need jQuery for me or my application. I needed it for DataTables.net. I created bindings for them too and jQuery was a requirement.

Having done the exercise I believe that it is impossible to reuse jQuery from another source and DataTables.net from another. They have to be developed in sync or at least first the jQuery and then the DataTables.net bindings. It looks like a huge waste of effort to me and not very scalable regarding ecosystem growth if every gwt developer develops his own bindings every time.

But what would be a proper solution here? Create a mega project to coordinate smaller bindings only projects? Provisions have to be taken for packaging and namespaces in order to avoid collisions and a ton of other things that are massive headaches.

It could work ... and if you have the time it is worth trying. Seeing if you can gather support on the chat channel seems like the best way forward. Good luck!

I guess my concern is that if the binding is not generated automatically from the types in the source js project then the binding will be an opinionated mapping of a subset of the js API that made sense to the author or their use-case. If that mapping makes sense for enough other people then I can imagine that it is worth collaborating with other people to develop and maintain it over time. We maintain a fairly opinionated binding of react and (several) bindings for keycloak.js but other than those two libraries, any binding we have tends to be project specific because the mapping focuses on small subsets of the relevant libraries. 

--

Cheers,

Peter Donald