Monday, June 3, 2019

Re: A Short GWT JsInterop Article for Beginners

Nice!

On Tuesday, June 4, 2019 at 6:21:32 AM UTC+10, Dr. Lofi Dewanto wrote:
Hi All,

I wrote a short article to introduce GWT and JsInterop for beginners, hope to see more people using GWT: http://bit.ly/WebJavaStory

Enjoy, thanks,
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/3d76a880-3646-42d3-8a1e-dfc19ee7bee0%40googlegroups.com.

A Short GWT JsInterop Article for Beginners

Hi All,

I wrote a short article to introduce GWT and JsInterop for beginners, hope to see more people using GWT: http://bit.ly/WebJavaStory

Enjoy, thanks,
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/1e60c5ea-ae86-4096-adb3-1ecb7c679ead%40googlegroups.com.

Re: What is the advantage of GWT 3.0?

Sounds great! Thanks!


On Sunday, June 2, 2019 at 3:44:23 PM UTC-7, Peter Donald wrote:


On Sun, Jun 2, 2019 at 12:59 PM Andrew Buck <anb...@gmail.com> wrote:
I love GWT 2.8 and I appreciate all the work that the community has put into it as well as the work towards GWT 3.0. I'm trying to understand what the advantage of GWT 3.0 is though. It seems like GWT 3.0 is a subset of GWT 2.8 with a different compiler under the covers. How is the closure compiler better than the GWT 2 compiler and is it really worth trying to switch when GWT 2.8 is mature and works well?

The reason we are moving that way is:

* <1s refresh times in dev mode regardless of the size of the project. The promise is that the compile time is proportional to the size of the change, not the size of the app.
* Integration with modern javascript so can use modern browser facilities without backflips. i.e. Simple creation of ES6 class instances so can do things like WebComponents without ugly hacks and/or loss of optimize-ability.
* Potential for much better code optimization and writing custom compiler passes.
* Emitting modules as non-web apps without writing custom linkers. i.e. Currently if you are building a browser extension or a web worker or an app to run in node you need to write a custom linker
* potential for hot-reload in candidate modules without loosing any application state (i.e reload just a single ui component in our react/gwt app without loosing the rest of the state in our application)
* Integration/optimization with native javascript. i.e. Bringing in native js modules will be possible and they will all be compiled and optimized together
* Exporting java libraries to native Typescript/javascript without any ugliness and full optimization still available

To be honest the first two are the main reasons ... the rest is icing on the cake ;)

-- 
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/e163dbab-9300-426b-a5b5-42ad0152a0df%40googlegroups.com.

Re: GWT - Still Active ?

Well, let's name few problems here:

1) Source maps: I don't know why, but Chrome can't find them. I've tried everything (I swear, I followed step by step every tutorial in earth - it just wont work. It may be because our folder structure that is bit more complex than those simple examples).
2) So, I'll forget and leave Java sources, and try to debug Javascript code. I've configured GWT compiler to produce "pretty", "non-obfuscated code". The generated javascript files are so big that chrome can't open it in developer mode. I just open an "empty" window. Nothing else.

Just to let you know, I'm using NetBeans - but this has nothing to do with the IDE I use - I'm just talking about debug javascript code.

I do consider myself a experienced engineer, having worked with several languages and systems - but I can't manage to get superdevmode working at all. May be just my system is currently too large.

Regards,

Edson


Em domingo, 2 de junho de 2019 15:01:04 UTC-3, Andrew Buck escreveu:
Debugging of both the server and client code works great. I'm not sure why it doesn't work for you. Client side debugging is done in the browser console using source maps that are automatically generated by the GWT compiler.

On Saturday, June 1, 2019 at 3:22:09 PM UTC-7, Edson Richter wrote:
This is my opinion (from a person with more than 30 years of experience in software enginnering), and I respect every other persons opinion - I'll just not put my eggs on this basket for another 8 years "just to see if it will get better".
Last year I had big issue with dates, because GWT has outdated DST tables (backend had correct dates, front end show everything one hour earlier!!!). This is just one little big problem for enterprise apps. I've asked support for this issue here, without any result (if someone had pointed me how to fix, I'll contribute code back to the project!). Finally, I had to write my own DST table and use "creativity" to overcome this "bug".
Not having support is also a big issue.
Not being able to debug the code anymore is another one.
More and more, GWT will get those "pieces" failing... and finally, it won't be usable anymore.

Regards,

Edson


Em sexta-feira, 31 de maio de 2019 11:41:27 UTC-3, Jamal Romero escreveu:
Out of curiosity, what would prevent someone still build projects based on current GWT 2.8.2 and keep using all the goodies? I think as of 2.8.2 it is future proof especially with a shift to jsinteop included in current release version? People even with current version took their own path and modernized part of GWT like the excellent gwt material & domino ui kit.

--
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/6f3dfaf6-ab6e-400a-a154-35b3c386422d%40googlegroups.com.

Sunday, June 2, 2019

[ANN] (Unofficial) Elemental2 2.24 release

Elemental2 provides type checked access to browser APIs for Java
code. This is done by using closure extern files and generating
JsTypes, which are part of the new JsInterop specification that
is implemented in both GWT and J2CL.

https://github.com/google/elemental2

This is an unofficial release to Maven Central under a different groupId.
Please don't bug the original authors. Versions are released on demand.

API Changes relative to Elemental2 version 2.23

elemental2-core:
  API Differences: https://jsinterop.github.io/api-diff/?key=elemental2-core&old=2.23&new=2.24
  - 39 non breaking changes.
  - 19 potentially breaking changes.
  - 49 breaking changes.
elemental2-dom:
  API Differences: https://jsinterop.github.io/api-diff/?key=elemental2-dom&old=2.23&new=2.24
  - 85 non breaking changes.
  - 68 potentially breaking changes.
  - 165 breaking changes.
elemental2-indexeddb:
  API Differences: https://jsinterop.github.io/api-diff/?key=elemental2-indexeddb&old=2.23&new=2.24
  - 1 non breaking changes.
elemental2-svg:
  API Differences: https://jsinterop.github.io/api-diff/?key=elemental2-svg&old=2.23&new=2.24
  - 1 breaking changes.
elemental2-webassembly:
  API Differences: https://jsinterop.github.io/api-diff/?key=elemental2-webassembly&old=2.23&new=2.24
  - 1 potentially breaking changes.

The complete set of Elemental2 API differences is available at

  https://jsinterop.github.io/api-diff/?key=elemental2&old=2.23&new=2.24

The Maven dependencies can be added to your pom.xml via

    <dependency>
      <groupId>org.realityforge.com.google.elemental2</groupId>
      <artifactId>${artifact-id}</artifactId>
      <version>2.24</version>
    </dependency>

where artifact-id is one of

* elemental2-core
* elemental2-dom
* elemental2-promise
* elemental2-indexeddb
* elemental2-svg
* elemental2-webgl
* elemental2-media
* elemental2-webstorage
* elemental2-webassembly

Hope this helps,

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/CACiKNc7MxXc_bDCniVAQp5B_j9MfKmrpU9t9yqpnELr42u5iYQ%40mail.gmail.com.

Re: What is the advantage of GWT 3.0?



On Sun, Jun 2, 2019 at 12:59 PM Andrew Buck <anbuck@gmail.com> wrote:
I love GWT 2.8 and I appreciate all the work that the community has put into it as well as the work towards GWT 3.0. I'm trying to understand what the advantage of GWT 3.0 is though. It seems like GWT 3.0 is a subset of GWT 2.8 with a different compiler under the covers. How is the closure compiler better than the GWT 2 compiler and is it really worth trying to switch when GWT 2.8 is mature and works well?

The reason we are moving that way is:

* <1s refresh times in dev mode regardless of the size of the project. The promise is that the compile time is proportional to the size of the change, not the size of the app.
* Integration with modern javascript so can use modern browser facilities without backflips. i.e. Simple creation of ES6 class instances so can do things like WebComponents without ugly hacks and/or loss of optimize-ability.
* Potential for much better code optimization and writing custom compiler passes.
* Emitting modules as non-web apps without writing custom linkers. i.e. Currently if you are building a browser extension or a web worker or an app to run in node you need to write a custom linker
* potential for hot-reload in candidate modules without loosing any application state (i.e reload just a single ui component in our react/gwt app without loosing the rest of the state in our application)
* Integration/optimization with native javascript. i.e. Bringing in native js modules will be possible and they will all be compiled and optimized together
* Exporting java libraries to native Typescript/javascript without any ugliness and full optimization still available

To be honest the first two are the main reasons ... the rest is icing on the cake ;)

-- 
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/CACiKNc7NUQ1b-AD6ZOrobxH3okOq57_dNjuiDMp3Mr8nCJOprA%40mail.gmail.com.

Re: GWT - Still Active ?

Debugging of both the server and client code works great. I'm not sure why it doesn't work for you. Client side debugging is done in the browser console using source maps that are automatically generated by the GWT compiler.

On Saturday, June 1, 2019 at 3:22:09 PM UTC-7, Edson Richter wrote:
This is my opinion (from a person with more than 30 years of experience in software enginnering), and I respect every other persons opinion - I'll just not put my eggs on this basket for another 8 years "just to see if it will get better".
Last year I had big issue with dates, because GWT has outdated DST tables (backend had correct dates, front end show everything one hour earlier!!!). This is just one little big problem for enterprise apps. I've asked support for this issue here, without any result (if someone had pointed me how to fix, I'll contribute code back to the project!). Finally, I had to write my own DST table and use "creativity" to overcome this "bug".
Not having support is also a big issue.
Not being able to debug the code anymore is another one.
More and more, GWT will get those "pieces" failing... and finally, it won't be usable anymore.

Regards,

Edson


Em sexta-feira, 31 de maio de 2019 11:41:27 UTC-3, Jamal Romero escreveu:
Out of curiosity, what would prevent someone still build projects based on current GWT 2.8.2 and keep using all the goodies? I think as of 2.8.2 it is future proof especially with a shift to jsinteop included in current release version? People even with current version took their own path and modernized part of GWT like the excellent gwt material & domino ui kit.

--
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/576bc6d0-d89c-46fa-b88f-beca37e9aadc%40googlegroups.com.