Thursday, January 28, 2021

Re: Devmode Server starting automatically in Eclipse


Urgh, murphey's law, been poking at this on and off all day, within half an hour of taking to the internet to moan about it i've found the option!  It's hidden away in project options, not the plugin ones :-(   nevermind me...
On Thursday, January 28, 2021 at 10:14:56 PM UTC Stik wrote:
I've never seen the Eclipse plugin do this before, i'm sure i've always had to start the code server manually myself, but now it seems to be starting automatically when Tomcat does.  If the run config is missing, then it creates it.   

Any idea how i stop this?  I can't find any relevant options for the plugin.  Version 3.0.0.201710131939, on 2020-03

Stik

--
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-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/04d9736c-a9e1-4859-a947-ab6749f3b96en%40googlegroups.com.

Devmode Server starting automatically in Eclipse

I've never seen the Eclipse plugin do this before, i'm sure i've always had to start the code server manually myself, but now it seems to be starting automatically when Tomcat does.  If the run config is missing, then it creates it.   

Any idea how i stop this?  I can't find any relevant options for the plugin.  Version 3.0.0.201710131939, on 2020-03

Stik

--
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-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/0eafc532-f68b-49aa-9136-883e0a0d3c90n%40googlegroups.com.

Monday, January 25, 2021

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

On Tue, Jan 26, 2021 at 5:08 AM Vassilis Virvilis <vasvir2@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

--
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-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/CACiKNc6kuakQ9epWFAW82x8hnzJHoZQ2JoSmx8PeWLBqBYSTGQ%40mail.gmail.com.

Re: Abridged summary of google-web-toolkit@googlegroups.com - 7 updates in 3 topics

In my experience it doesn't play any roles in what programming language an app is written but if it is huge, chaotic and no unit tests, it is very difficult to debug and to extend. I have a huge Java webapp and different devs working on it... Luckily Java is statically-typed and Java IDE is very good today, so it helps a lot...

So it won't help just to move to a new tech stack (Angular, TS, etc.) and still writing a huge app. Anything which is big enough will be hard to maintain.

About GWT skills, IMHO, if one could embrace HTML, DOM, WebAPIs from web browser and of course knows Java, she / he could work on GWT / Vue.js or whatever it is. For the details you need to try it anyway...

Just my 2c.
Edson Richter schrieb am Montag, 25. Januar 2021 um 14:58:09 UTC+1:
Just in case... Many people suggests to hire "pros" and "experts": it is my fault, because I've not provided my background. I do work with TI for about 35 years, programming in 15 or more languages (stopped counting long ago), a MS System Engineer and Lotus Notes Professional (!!!) since 1995, heavy background on networks and protocols... Even as CTO of my own company often I do code hacking nights because I love technology. I"be been using Gwt since 2.0... Our project started on Gwt in 2009... I had to edit gwt source code many times to fix things that has not been fixed (like timezone DST), and created many hacks in javascript inside my java code. After many years teaching developers to work with gwt (this is another problem: to hire developers with gwt skills), I've made a plan, and we are working on it. So sar, so good, we still be working with gwt for a year or two. But, then, I smile everytime I (or my team) need to debug something - either server side or client side. In huge applications like ours, it's like having pockets full of gold, even having to mine them hard.

Em dom, 24 de jan de 2021 10:01, <google-we...@googlegroups.com> escreveu:
"pavel....@gmail.com" <pavel....@gmail.com>: Jan 24 03:36AM -0800

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.
...more
"lofid...@gmail.com" <lofid...@gmail.com>: Jan 23 11:41AM -0800

@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 ...more
Peter Donald <pe...@realityforge.org>: Jan 24 04:13PM +1100

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 ...more
Vassilis Virvilis <vas...@gmail.com>: Jan 24 11:16AM +0200

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 ...more
Edson Richter <brvi...@gmail.com>: Jan 23 11:56AM -0300

After fighting with no debug working on gwt (yeah, believe me, tryied
everything) and fighting hard with missing date/time daylight savings time
horror stories, we decided to move gradually to ...more
"lofid...@gmail.com" <lofid...@gmail.com>: Jan 23 11:21AM -0800

I'm sorry to hear your problem with debugging and daylight saving time...
In such case I would just take a paid / professional consulting like e.g.
Vertispan to solve my problems. ...more
Vegegoku <aka...@gmail.com>: Jan 23 12:32PM -0800

Rewrite in most cases is just a wrong step, doing it gradually may make it
less expensive but it is still a very expensive approach, I have always
been wondering why companies prefer a rewrite ...more
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to google-web-tool...@googlegroups.com.

--
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-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/7a050e1f-76b0-4792-9bfd-b2997b17284cn%40googlegroups.com.

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

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

But I never tried it...
vas...@gmail.com schrieb am Montag, 25. Januar 2021 um 19:09:00 UTC+1:
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.




On Mon, Jan 25, 2021 at 10:35 AM Peter Donald <pe...@realityforge.org> wrote:


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

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

--
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-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/b0058ab1-52f6-48fc-8df0-fcf182e5510bn%40googlegroups.com.

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

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.




On Mon, Jan 25, 2021 at 10:35 AM Peter Donald <peter@realityforge.org> wrote:


On Sun, Jan 24, 2021 at 8:17 PM Vassilis Virvilis <vasvir2@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

--
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-toolkit+unsubscribe@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

--
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-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/CAKbOjEy_9EgY%2BEwVzE4x_KcumBcd8iWH4g8rDk8%2BiVbLp%2Bvtjg%40mail.gmail.com.

Re: Abridged summary of google-web-toolkit@googlegroups.com - 7 updates in 3 topics

Just in case... Many people suggests to hire "pros" and "experts": it is my fault, because I've not provided my background. I do work with TI for about 35 years, programming in 15 or more languages (stopped counting long ago), a MS System Engineer and Lotus Notes Professional (!!!) since 1995, heavy background on networks and protocols... Even as CTO of my own company often I do code hacking nights because I love technology. I"be been using Gwt since 2.0... Our project started on Gwt in 2009... I had to edit gwt source code many times to fix things that has not been fixed (like timezone DST), and created many hacks in javascript inside my java code. After many years teaching developers to work with gwt (this is another problem: to hire developers with gwt skills), I've made a plan, and we are working on it. So sar, so good, we still be working with gwt for a year or two. But, then, I smile everytime I (or my team) need to debug something - either server side or client side. In huge applications like ours, it's like having pockets full of gold, even having to mine them hard.

Em dom, 24 de jan de 2021 10:01, <google-web-toolkit@googlegroups.com> escreveu:
"pavel....@gmail.com" <pavel.yatsuk@gmail.com>: Jan 24 03:36AM -0800

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.
...more
"lofid...@gmail.com" <lofidewanto@gmail.com>: Jan 23 11:41AM -0800

@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 ...more
Peter Donald <peter@realityforge.org>: Jan 24 04:13PM +1100

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 ...more
Vassilis Virvilis <vasvir2@gmail.com>: Jan 24 11:16AM +0200

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 ...more
Edson Richter <brviking@gmail.com>: Jan 23 11:56AM -0300

After fighting with no debug working on gwt (yeah, believe me, tryied
everything) and fighting hard with missing date/time daylight savings time
horror stories, we decided to move gradually to ...more
"lofid...@gmail.com" <lofidewanto@gmail.com>: Jan 23 11:21AM -0800

I'm sorry to hear your problem with debugging and daylight saving time...
In such case I would just take a paid / professional consulting like e.g.
Vertispan to solve my problems. ...more
Vegegoku <akabme@gmail.com>: Jan 23 12:32PM -0800

Rewrite in most cases is just a wrong step, doing it gradually may make it
less expensive but it is still a very expensive approach, I have always
been wondering why companies prefer a rewrite ...more
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to google-web-toolkit+unsubscribe@googlegroups.com.

--
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-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/CACZ-w1S4bQnDdvvX9k26gZSaDObE%2Byzk%3DYcr7tdbPDoaFgsp%2BQ%40mail.gmail.com.

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



On Sun, Jan 24, 2021 at 8:17 PM Vassilis Virvilis <vasvir2@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

--
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-toolkit+unsubscribe@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.

Sunday, January 24, 2021

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

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.  

pavel....@gmail.com schrieb am Sonntag, 24. Januar 2021 um 12:36:40 UTC+1:
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 пише:
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




On Tue, Dec 22, 2020 at 7:27 PM lofid...@gmail.com <lofid...@gmail.com> wrote:
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!

lofid...@gmail.com schrieb am Dienstag, 22. Dezember 2020 um 12:40:39 UTC+1:
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!

mysare...@gmail.com schrieb am Samstag, 19. Dezember 2020 um 01:30:44 UTC+1:
Thank you very much. I ll give it a try.

On Friday, December 18, 2020 at 4:44:32 PM UTC+1 frank.h...@web.de wrote:

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.

mysare...@gmail.com schrieb am Freitag, 18. Dezember 2020 um 02:01:24 UTC+1:
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
On Sunday, October 18, 2020 at 11:15:42 PM UTC+2 peter.j...@gmail.com wrote:
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

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

--
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-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/3f9c093e-3a1e-4283-8dd4-1d9d7cb5f2ean%40googlegroups.com.

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

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 пише:
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




On Tue, Dec 22, 2020 at 7:27 PM lofid...@gmail.com <lofid...@gmail.com> wrote:
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!

lofid...@gmail.com schrieb am Dienstag, 22. Dezember 2020 um 12:40:39 UTC+1:
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!

mysare...@gmail.com schrieb am Samstag, 19. Dezember 2020 um 01:30:44 UTC+1:
Thank you very much. I ll give it a try.

On Friday, December 18, 2020 at 4:44:32 PM UTC+1 frank.h...@web.de wrote:

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.

mysare...@gmail.com schrieb am Freitag, 18. Dezember 2020 um 02:01:24 UTC+1:
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
On Sunday, October 18, 2020 at 11:15:42 PM UTC+2 peter.j...@gmail.com wrote:
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

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

--
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-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/7e609b0d-092f-4854-b0b9-f3fbf59ec358n%40googlegroups.com.

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

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


On Sun, Jan 24, 2021 at 7:14 AM Peter Donald <peter@realityforge.org> wrote:
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.

On Thu, Jan 21, 2021 at 3:14 AM David Nouls <david.nouls@gmail.com> wrote:
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.
On 20 Jan 2021, 16:48 +0100, lofid...@gmail.com <lofidewanto@gmail.com>, wrote:
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
t.br...@gmail.com schrieb am Mittwoch, 20. Januar 2021 um 14:36:30 UTC+1:
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)

On Tuesday, January 19, 2021 at 5:26:38 PM UTC+1 lofid...@gmail.com wrote:
@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
RobW schrieb am Dienstag, 19. Januar 2021 um 15:29:42 UTC+1:
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

On Tuesday, 19 January 2021 at 10:46:44 UTC aka...@gmail.com wrote:
I wonder if that will actually last for the next 10 years.

On Tuesday, January 19, 2021 at 10:04:19 AM UTC+2 swas...@gmail.com wrote:
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.
On Monday, 4 January 2021 at 23:37:53 UTC+7 Alexander Bertram wrote:
Nice to hear from everyone!

Here's to the next ten years :-)

Best wishes for 2021,
Alex

On Tuesday, December 22, 2020 at 10:22:08 AM UTC+1 Segun Razaq Sobulo wrote:

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

Thanks
On Monday, 21 December 2020 at 15:24:19 UTC+1 aka...@gmail.com wrote:
We are in times where working remotly id actually a good option.

On Monday, December 21, 2020 at 4:19:13 PM UTC+2 David Nouls wrote:
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
On 20 Dec 2020, 16:16 +0100, 'Alexander Bertram' via GWT Users <google-we...@googlegroups.com>, wrote:

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.


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

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

--
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-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/2c7b6eec-67cd-4361-8777-18490db3dba7n%40googlegroups.com.

--
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-toolkit+unsubscribe@googlegroups.com.
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

--
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-toolkit+unsubscribe@googlegroups.com.
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

--
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-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/CAKbOjEwsH4%3De54C0J94PZhPFj7Lfmi7hSQ1%3DPFuMHC7CLnmwfg%40mail.gmail.com.