New Presentation about Modern GWT Webapp Development

[Dr. Lofi Dewanto]

Hi All,

if you need a presentation about modern GWT development as an introduction, just take a look at this:

https://bit.ly/gwtintropresentation

I also added this presentation in the Modern GWT Padlet: https://bit.ly/GWTIntroPadlet

Have fun,

Lofi

[Thomas Broyer]

Great deck, there are a few inaccuracies though:

• Slide 18:  “Most browsers will allow a maximum of two simultaneous connections for fetching resources.” This has been wrong for some time; limit has been bumped to 6 since IE8, Firefox 3.6 (https://developer.mozilla.org/en-US/docs/Web/HTTP/Connection_management_in_HTTP_1.x#Domain_sharding, https://hpbn.co/http1x/#using-multiple-tcp-connections, https://en.wikipedia.org/wiki/HTTP_persistent_connection#Use_in_web_browsers, http://www.stevesouders.com/blog/2008/03/10/ie8-speeds-things-up/, http://kb.mozillazine.org/Network.http.max-persistent-connections-per-server), I've even found a resource stating that IE11 used up to 13 connections (https://docs.pushtechnology.com/cloud/latest/manual/html/designguide/solution/support/connection_limitations.html)
• Slide 20: I'm pretty sure modern browsers will start to fetch bigImageOne and reallyBigImageTwo in parallel to externalScriptZero (see https://developer.mozilla.org/en-US/docs/Glossary/speculative_parsing), and of course the example is tailored for a 2-connection-per-server limit, which is no longer the case. As we're at it, you might also want to talk about <script defer> and <script async>.
• Slide 23: "one-to-one" this is not true: there will be at least 2 files: *.java.js and *.impl.java.js, and each nested class will generate two additional files (see https://github.com/google/j2cl/tree/309799e486ed371f364468560c5983948ad54f0c/transpiler/javatests/com/google/j2cl/transpiler/readable/enums/output for example)

[Dr. Lofi Dewanto]

Hi Thomas,

thanks a lot for the review. I updated following:

(1) Slide 18: updated with your content

(2) Slide 20: I let the slide 20 the same but I inserted a slide 23, which said "... more than two connections..."

(2.1) I also add a slide 24 about <script async> and <script defer>

(3) Slide 23 now 25: I updated the infos just like what you said with the examples but I let the name "one-to-one". I feel it is the big difference between GWT and J2CL. 

• In GWT you have all the Java files transpiled to one JS (after linker) which is optimized ("many-to-one", although it is not really one... permutations). 
• In J2CL you have one Java file each transpiled to one / two or more JS.

I would really appreciate all the reviews 🙏 

Thanks a lot,

Lofi

[Jens]

Personally I would not say that GWT widgets are deprecated. They are ported to be compatible with J2CL, they just look a bit dated because nobody has done a new fancy CSS for them. So it is generally fine to use them, but you should not expect that any new components will be added to the currently available ones anytime soon. But if someone is really interested in it I could see that widget internals could be modernized even more, a more modern CSS theme could be written and then gradually enhance these widgets.

I would more see them as "not recommend if you expect an evolving UI framework with components for all kinds of use cases, even use cases you don't have.".

-- J.

[Dr. Lofi Dewanto]

Hi Jens,

thanks a lot for your comment. Yes, a good example is actually GWTBootstrap3:

• Old one based on old stuffs GWT: https://gwtbootstrap3.github.io/gwtbootstrap3-demo
• And the new one based on Elemental2: https://github.com/treblereel/gwtbootstrap3

So as an application developer I don't really need to change my code, because it still use the same APIs.

I changed the "deprecated" to two types: "NeedUpdateElemental2" and "NoFancyL&F" 😄

Thanks,

Lofi

[Dr. Lofi Dewanto]

Update again with <NeedUpdateModern> and <NoFancyL&F>

Because I think modern GWT == Elemental2 and Java Annotation Processor (no GWT generators) and I still put the "included" GWT UIs as both. Because in 2.8.x you still use GWT generators and older Widget stuffs.

Thanks,

Lofi

[Dr. Lofi Dewanto]

I added a slide for: 

Why not server-side Java UI frameworks like Vaadin, Wicket, JSF, …?

IMHO, this is an important point too.

Thanks, 

Lofi

[Joker Joker]

Great job! These things help promote GWT.

среда, 13 мая 2020 г. в 14:33:58 UTC+4, lofid...@gmail.com:

[Joker Joker]

Please add to Tools slide 100% working and mantained gwt-gradle-plugin

https://github.com/esoco/gwt-gradle-plugin

среда, 16 сентября 2020 г. в 10:49:52 UTC+4, Joker Joker:

[lofid...@gmail.com]

Hi, thanks for the comment.

There are some Gradle plugins for GWT, which one is the "best"? Sofar I only use Maven, so never try Gradle...

Maybe others could also tell which Gradle Plugin should we propose? @Thomas Broyer?

Thanks,

Lofi

[Thomas Broyer]

On Wednesday, September 16, 2020 at 9:48:39 AM UTC+2, lofid...@gmail.com wrote:

Hi, thanks for the comment.

There are some Gradle plugins for GWT, which one is the "best"? Sofar I only use Maven, so never try Gradle...

Maybe others could also tell which Gradle Plugin should we propose? @Thomas Broyer?

I don't use any plugin for GWT in Gradle (configuring JavaExec and Test tasks "by hand").

One thing that no plugin seems to have done yet, is use Gradle variants for shared libs to expose the sources to dependent subprojects in the same build only if/when they need it, and possibly use different dependencies: in a project with 37 subprojects, the GWT app only transitively depends on 10 of those subprojects, all of which are shared with the server; and some of them then add the sources JAR of third-party dependencies to the GWT-specific classpath.

With Maven, you would either put the <classifier>sources</classifier> dependency in the server classpath as well (for simplicity), add all the transitively-needed sources dependencies down to the GWT app module, or create intermediate artifacts that "aggregate" classes and sources (and possibly add the gwt.xml), like in https://github.com/tbroyer/gwt-maven-plugin/issues/127#issuecomment-474338891; whereas with Gradle, you can do that in the very same project:

plugins {
  java
  id("local.gwt-shared-lib")
}
dependencies {
  implementation("org.slf4j:slf4j-api")
  implementation("some third party lib")
  gwt("some emulation lib for SLF4J")
  gwt("adapter lib for the other third-party lib")
}

When the GWT app depends (at any level of transitivity) on that lib, it'll automatically have 'gwt' dependencies in the classpath when calling GWT (compilation, code server, tests); the server app will only have the 'implementation' dependencies in its classpath.

This works well for an application project at least; it would probably have to be different for a lib that you intend to deploy to a Maven repository for others to use; which is why I never formalized this in a (public) Gradle plugin yet.

Ideally I think we'd want a "java-multiplatform" plugin, similar to kotlin-multiplatform, to support all of the JVM, J2Cl and/or GWT, and J2ObjC, but Kotlin has an advantage here: they made it part of the language itself: https://kotlinlang.org/docs/reference/mpp-connect-to-apis.html

(sorry for the digression)

[Hamid Razoki]

Great job nice présentation 

--
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/2886a824-dba4-463e-bac6-29a3e1cbbe67o%40googlegroups.com.

[lofid...@gmail.com]

Hi Thomas,

thanks a lot for your insight! 

Personally I like the idea of Maven to build small projects and always the same, instead of doing "variant" in Gradle (if I understand it correctly). Building "intermediate" artifacts in Maven is also good for me, KISS 😉Building only one project to content everything I feel like I'm using Ant again 😂At the end the complexity is there, whether you put it into the "intermediate" artifacts or you put it into the Gradle "variant".

I'm not sure whether I like the idea of "expect/actual" in Kotlin. I thought we don't need this anymore with Java --> WORA. But now we add such a feature back to the programming language thanks to "multi platform" or "platform specifics. Is that not the wrong place / wrong abstraction to put the "platform specific stuffs"? Is that similar to C++ preprocessor macros?

@Joker: do you have real experiences with the Gradle plugin you mentioned? If you think, that it is the plugin to be used, I'll add to my slides... But again I never use it...

Thanks,

Lofi

[lofid...@gmail.com]

Hi Thomas,

... actually I feel that doing platform specific stuffs in my code it's not the way.

It is comparable to GWT vs. jsweet. In GWT you have everything in Java semantic. In jsweet you actually have everything in Java but with JavaScript semantic. jsweet is for me still better than JavaScript 😉but I lost the Java semantic.

Putting platform specific stuffs in the code mixes the separation of concern, IMHO...

Cheers,

Lofi

[Thomas Broyer]

On Wednesday, September 16, 2020 at 6:49:36 PM UTC+2, lofid...@gmail.com wrote:

Hi Thomas,

... actually I feel that doing platform specific stuffs in my code it's not the way.

It is comparable to GWT vs. jsweet. In GWT you have everything in Java semantic. In jsweet you actually have everything in Java but with JavaScript semantic. jsweet is for me still better than JavaScript 😉but I lost the Java semantic.

Putting platform specific stuffs in the code mixes the separation of concern, IMHO...

Last time I wrote super-source was… last week!

Using @JsType(isNative=true,namespace=GLOBAL,name="Object") classes to talk to ProseMirror, translating between some XML and those JS objects (context: https://twitter.com/tbroyer/status/1303647011279966208).

In this case, this is purely client code, but I didn't want to use a GWTTestCase to test my XML↔Objects transforms, so I wrote the test to run in the JVM (and also made it work in a GWTTestCase, to make sure it does indeed work, but it's a lot slower).

Now how would you handle arrays? Well, I just use a @JsType(isNative=true,namespace=GLOBAL,name="Array") with a few @JsOverlay methods delegating to Js.asArrayLike(this)… in the super-source, with a simplement implementation wrapping an ArrayList for the JVM.

And how to compare the object trees in the tests? I cannot use things like isEqualToComparingFieldByFieldRecursively, and I didn't want to build something equivalent just for tests, so I just serialize them to JSON, using JSON.stringify() in super-source for GWT (not directly JSON.stringify() though, as object fields are not in a predictable order, but more https://www.rfc-editor.org/rfc/rfc8785.html#name-ecmascript-sample-canonical, which relies on JSON.stringify for "primitive" values), and GSON (that we already have around in GWT) in the JVM.

Of course I could have built things differently, with abstract factories so I could inject a GWT-specific or a JVM-specific one, and I actually went that route initially, but honestly, just so I can use a different List subclass within tests?

(granted, the previous time I wrote super source, besides GWT's own javaemul, was a long time ago :D but I never really shared a lot of code between server and client anyway: besides that rich text editor, those 10 other subproject dependencies are actually only there for enums and some constants, and of course one of them is about RequestFactory interfaces)

[lofid...@gmail.com]

Hi Thomas,

Surely we need to do the platform specific stuffs somewhere... but not in my programming language as keywords --> "the abstraction level" 🤔

Using platform specific super-source for GWT is fine but I don't have that in Java and I don't want to have that in Java. For me you have following level of integration:

- Programming language (like Java, Kotlin, ...)

- Frameworks and libraries (like GWT, Spring Framework, ...)

- Build tools (like Maven, Gradle, ...)

Platform specific stuffs should not go to programming language but they can go to frameworks or build tools, so that the programming language can be stable for a long time.

I'm afraid that the programming language will become "unstable" if you add something like "expect/actual"? But maybe I'm just too carefully 😀The new generation of programming language will break everything faster 😂

Cheers,

Lofi

[jumanor]

Gran trabajo, muchas gracias.

great job!

[Joker Joker]

Lofi,

I tried 3 plugins and this one (esoco) is the best one among them. 2 of them are abandoned. The plugin from esoco is the only one mantained at the moment.

https://github.com/steffenschaefer/gwt-gradle-plugin (abandoned)

https://github.com/Putnami/putnami-gradle-plugin (abandoned)

https://github.com/esoco/gwt-gradle-plugin  (active)

Putnami was my choise before it was abandoned.

Now I use esoco gradle plugin on 2 my large production projects and on on several gwt libraries.

пятница, 18 сентября 2020 г. в 00:39:06 UTC+4, jumanor:

[Michael Conrad]

There is also this jiakuan fork of the steffenschaefer plugin:

https://github.com/jiakuan/gwt-gradle-plugin

Maintenance of the fork is active.

--

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/e0ed6d1f-5962-4d23-b3d4-5354270b5f79n%40googlegroups.com.

[Thomas Broyer]

Fwiw, without plugin (Kotlin DSL):

val gwtOutputDir = file("$buildDir/gwtc/war")
tasks {
    val gwtCompile by registering(JavaExec::class) {
        val companionOutputDir = file("$buildDir/gwtc")
        val deployDir = file("$companionOutputDir/extra")
        val extraDir = deployDir
        val genDir = file("$companionOutputDir/gen") // XXX: useful?
        val workDir = file("$companionOutputDir/work")


        outputs.dir(gwtOutputDir).withPropertyName("outputDir")
        outputs.dir(deployDir).withPropertyName("deployDir")
        outputs.dir(extraDir).withPropertyName("extraDir")
        outputs.dir(genDir).withPropertyName("genDir")
        outputs.dir(workDir).withPropertyName("workDir")


        classpath = gwt
        maxHeapSize = "1g"
        main = "com.google.gwt.dev.Compiler"
        args(
            "-failOnError",
            "-XdisableCastChecking",
            "-XdisableClassMetadata",
            "-war", gwtOutputDir,
            "-deploy", deployDir,
            "-extra", extraDir,
            "-gen", genDir,
            "-workDir", workDir,
            "com.example.app.App"
        )


        doFirst {
            delete(gwtOutputDir, deployDir, extraDir, genDir)
        }
    }


    register<JavaExec>("run") {

        val workDir = file("$buildDir/gwt/codeserver")


        classpath = gwt
        maxHeapSize = "2g"
        main = "com.google.gwt.dev.codeserver.CodeServer"
        args(
            "-failOnError",
            "-launcherDir", gwtOutputDir,
            "-workDir", workDir,
            "com.example.app.App"
        )


        doFirst {
            delete(gwtOutputDir)
            mkdir(workDir)
        }
    }


    integrationTest {
        val warDir = file("$buildDir/gwt/www-test")
        val workDir = file("$buildDir/gwt/work")
        outputs.dir(warDir).withPropertyName("warDir")
        outputs.dir(workDir).withPropertyName("workDir")


        isScanForTestClasses = false
        include("**/*Suite.class")


        maxHeapSize = "1g"
        systemProperty("gwt.args", """-ea -draftCompile -batch module -war "$warDir" -workDir "$workDir" -runStyle HtmlUnit:FF38""")

    }
}

On Monday, September 21, 2020 at 2:04:38 PM UTC+2, Michael Joyner wrote:

There is also this jiakuan fork of the steffenschaefer plugin:

https://github.com/jiakuan/gwt-gradle-plugin

Maintenance of the fork is active.

On 9/21/20 6:55 AM, Joker Joker wrote:

Lofi,

I tried 3 plugins and this one (esoco) is the best one among them. 2 of them are abandoned. The plugin from esoco is the only one mantained at the moment.

https://github.com/steffenschaefer/gwt-gradle-plugin (abandoned)

https://github.com/Putnami/putnami-gradle-plugin (abandoned)

https://github.com/esoco/gwt-gradle-plugin  (active)

Putnami was my choise before it was abandoned.

Now I use esoco gradle plugin on 2 my large production projects and on on several gwt libraries.

пятница, 18 сентября 2020 г. в 00:39:06 UTC+4, jumanor:

Gran trabajo, muchas gracias.

great job!

El lunes, 11 de mayo de 2020 a las 16:01:56 UTC-5, lofid...@gmail.com escribió:

Hi All,

if you need a presentation about modern GWT development as an introduction, just take a look at this:

https://bit.ly/gwtintropresentation

I also added this presentation in the Modern GWT Padlet: https://bit.ly/GWTIntroPadlet

Have fun,

Lofi

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

[lofid...@gmail.com]

I added Gradle in the "Tools" page, enjoy 😊 

[lofid...@gmail.com]

I added the presentation with "Fun with GWT / J2CL" - Quake2 Port to J2CL from Dimitrii, it is a really nice use case 😉👍

[deja...@googlemail.com]

Thanks Lofi,

there is another interesting Gradle plugin for GWT especially with regard to the approach to use npm and webpack:

https://github.com/ascendtech/gwt-gradle

Slide 42 Example 1: The null check is useless because Arrays.asList will throw a NPE if argument is null.

Don't know if gwt-ol is interesting for the slides because actually it is a simple JsInterop wrapper but maps are looking good in presentations:

https://github.com/TDesjardins/gwt-ol

https://tdesjardins.github.io/gwt-ol-demo-site/#application/map/XyzExample

[lofid...@gmail.com]

Thanks a lot for the info.

I added the Gradle plugin, wow we have 3 Gradle plugins.... is it not better just to have one? 😉

The check on page 42 is about the "values", so the input param 😉

I will create a new GWT libs list project to have a list of all GWT libs available... so not only UI framework... and will put everything over there... hope that the community will make some PR, so we can have a lot of libs...

Lofi

[Thomas Broyer]

On Wednesday, September 30, 2020 at 10:48:34 PM UTC+2, lofid...@gmail.com wrote:

Thanks a lot for the info.

I added the Gradle plugin, wow we have 3 Gradle plugins.... is it not better just to have one? 😉

The check on page 42 is about the "values", so the input param 😉

I will create a new GWT libs list project to have a list of all GWT libs available... so not only UI framework... and will put everything over there... hope that the community will make some PR, so we can have a lot of libs...

Some kind of "awesome gwt" then? https://github.com/sindresorhus/awesome

Fwiw, a Google search for "awesome gwt" returned https://awesomeopensource.com/projects/gwt and https://gwt.zeef.com/awesomegwt

[lofid...@gmail.com]

Hi Thomas,

thanks for the clue... yeah something like "awesome gwt" but like you said we already have it. I know this one https://gwt.zeef.com/awesomegwt (great links collection) and I already put this in GWT Padlet --> "GWT Links Collection"

I thought it is just a simple one pager "Only Libs" table with following content:

Category / JS Lib Name / JS Lib Address / GWT Lib Name / GWT Lib Address / JsInterop or JSNI

Example:

maps / open-layers3 / https://openlayers.org / gwt-ol / https://github.com/TDesjardins/gwt-ol / JsInterop

diagrams / chart.js / https://www.chartjs.org / charba / https://github.com/pepstock-org/Charba / JsInterop

diagrams / highchart.js / https://www.highcharts.com / gwt-highcharts / https://github.com/ascendtech/gwt-highcharts / JsInterop

...

That's it., so we can see whether someone already did the work with JsInterop (analogy to DefinitelyTyped for the types in TS).

And everyone could make a PR to update the one page...

Is it worth it to try?

[lofid...@gmail.com]

... because IMO the weak point of GWT / J2CL today is the JsInterop implementation of all those JS libs... I always need to google to find it, which is ok but it would be great to be able to see what JS libs we already have as JsInterop integrations...

[Tino D.]

Am Mi., 30. Sept. 2020 um 22:48 Uhr schrieb lofid...@gmail.com <lofid...@gmail.com>:

The check on page 42 is about the "values", so the input param 😉

The null check assumes that "values" can be null. If it is null you will get a NullPointerException before this check takes place because of the call Arrays.asList(). Simply putting the first statement in the if-body will solve the problem.

[lofid...@gmail.com]

Yes, you're right I wrote bad unit tests 😉I updated im my repo with better unit tests: https://github.com/lofidewanto/jsinterop-simple-example/blob/master/src/test/java/com/github/lofi/CalculatorTest.java

Thanks!

[lofid...@gmail.com]

I open a new GitHub project for putting every GWT libs I know sofar...

Library List (LiLi):

https://github.com/gwtboot/gwt-boot-jsinterop-lili

If you have libs I don't know just open a PR / MR...

Thanks,

Lofi

[lofid...@gmail.com]

Hi All, 

I changed the name of the repo for the GWT Awesome LiLi: 

https://github.com/gwtboot/gwt-boot-awesome-lili

PR and MR are very welcome! 😀

Lofi

[lofid...@gmail.com]

I added the "heart" ❤️ symbol to show that the libs / frameworks still being supported... I tried to add all the hearts in which libs I know...

If you want to add the heart just follow the two ways I mentioned in the beginning:
https://github.com/gwtboot/gwt-boot-awesome-lili

All the supported libs / frameworks are always in the beginning of the category...
Hope to get more libs / frameworks for GWT / J2CL 😀👍

[Slava Imeshev]

Lofi, This is great, thank you for getting this together.