Friday, September 18, 2020

Upcoming Virtual Events

Slow Ventures Snail Mail

Friday, September 18th, 2020

Slow Family,

We are hosting a few fun upcoming events through the end of the month on Livestack (a platform we are working on for fan-funded events). These all should be a great time if you can join:

Comedy Showcase with Johnny Corn 
Saturday, 9/19 @ 8:30p PT

Johnny Corn, an SF Bay Area comedian & actor, was requested by one of his fans to put on a showcase with other comedians here in the bay. He will be joining the virtual stage along with longtime friends Nicole Tran & Reggie Shorter.

Alyx Bell x Elizabeth Woolf: Reunion Show
Sunday, 9/20 @ 4p PT

Elizabeth & Alyx both met freshman year at UC Berkeley, started a band together and since then have grown into their careers as solo artists. Both artists are now Portland based and will be streaming the show live from Alyx's backyard. You can check out and pre-order Elizabeth's album debuting in October here.

Iqram & The Immigrant Groove: Release of 'One Nation' 
Tuesday, 9/29 @ 4:30p PT

Iqram & The Immigrant Groove makes funky Immigrant Music and is created by two Immigrants, Iqram (Zimbabwe) & Mamadou (Senegal). They'll be celebrating the release of their upcoming single, 'One Nation', in advance of the November  election. You can listen to the track before it goes live to all streaming platforms on Ense Exclusives here.

Hope to see you there!

The Slow Team

Want moar? Check us out on:
Facebook, Twitter, Medium or our Website

Signup for Snail Mail Newsletters at  http://slow.claims
Our mailing address is:
1006 Kearny St, San Francisco, CA 94133

Don't Want These Emails?
unsubscribe from this list
 

Donate BTC: 3BJW4B6GGpoQrjeom6RpVtkza3XPw2qjoK
Donate ETH: 0xD7599b3D15805aDF3144676914964e8fff53C925

Thursday, September 17, 2020

Re: New Presentation about Modern GWT Webapp Development

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:


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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/dfe9e090-bbe0-4968-8827-3172e604089en%40googlegroups.com.

Wednesday, September 16, 2020

Re: New Presentation about Modern GWT Webapp Development

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

t.br...@gmail.com schrieb am Mittwoch, 16. September 2020 um 19:49:33 UTC+2:

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)

--
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/c99e20f7-84d5-4e07-9afe-7e96ea8d8fa1n%40googlegroups.com.

Re: New Presentation about Modern GWT Webapp Development


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)

--
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/0345bd0d-f5bc-48ed-a206-e2dd0b1825b9o%40googlegroups.com.

Re: New Presentation about Modern GWT Webapp Development

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

lofid...@gmail.com schrieb am Mittwoch, 16. September 2020 um 18:21:41 UTC+2:
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

t.br...@gmail.com schrieb am Mittwoch, 16. September 2020 um 10:36:32 UTC+2:


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)

--
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/2ecfd469-9a66-4e34-a139-f43cb1e59b84n%40googlegroups.com.

Re: New Presentation about Modern GWT Webapp Development

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

t.br...@gmail.com schrieb am Mittwoch, 16. September 2020 um 10:36:32 UTC+2:


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)

--
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/1cdc952a-c8d7-413e-8d4d-284bad681e2cn%40googlegroups.com.

Re: New Presentation about Modern GWT Webapp Development

Great job nice présentation 

Le mer. 16 sept. 2020 à 09:36, Thomas Broyer <t.broyer@gmail.com> a écrit :


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)

--
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/2886a824-dba4-463e-bac6-29a3e1cbbe67o%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/CACgjETbdvXuSzSsyHYy5OX31OAuUQ%3DzLKVpxEpVUkSgJV-wsUQ%40mail.gmail.com.