Roadmap Question for GWT 3.0

[Ed]

If I wanted to start now for the the GWT 3.0 release, what would be the best mechanism to replace:

1. GWT.create

2. RPC

We starting a refactor of existing code, and would like some foresight into this matter.

Thanks

Ed

[Jens]

1. GWT.create

<generate-with>: Annotation processors

<replace-with>: Dagger 2.x + AutoFactory (assisted inject) for injection and System.getProperty() to build the Dagger dependency graph based on your deferred binding properties.

For Dagger I created a pull request that generates a dagger-gwt artifact including a GWT module: https://github.com/google/dagger/pull/119

2. RPC

Anything that generates code in a way that is compatible with annotation processors so they can migrate to APT in the future. I guess you need to ask maintainers of your preferred alternatives and hear what they say. Regardless of GWT 3.0 I would never really use GWT-RPC again because things like RPC policy files, "do not use interfaces in serializable types" and that it is hard to consume outside of GWT are annoying.

-- J.

[Ed]

Thanks Jens, Great response, gives our devs something to learn.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

[Ed]

@jens

Is there any downside to Request Builder?  Possible deprecation in GWT 3.0?

Best Regards

Ed

[Jens]

Is there any downside to Request Builder?  Possible deprecation in GWT 3.0?

Well the internally used XMLHttpRequest / Timer classes would need to be ported to JsInterop of course because they use JSNI.

There are some general to consider with RequestBuilder as well:

- It is quite low level

- RequestCallback is not Java8 friendly (lambda / method references) as it is not a SAM interface.

- for now does not support XHR 2 (ArrayBuffer, Blob, Document response types) out of the box

-- J.

[Ümit Seren]

In addition to what Jens said:
If possible, go Restful. it makes it much easier to later add non-GWT clients and also forces you to think about your domain model as resources (might lead to a clean API).

I guess once Elemental 2.0 is released (AFAIK along the lines with GWT 3.0) you could  either use XMLHttpRequest or fetch (https://developers.google.com/web/updates/2015/03/introduction-to-fetch?hl=en) if you don't mind to use a polyfill for non-supported browser (maybe at that point all the evergreen browsers already support it natively) or use a higher abstraction (like RestyGWT, etc)

On Tuesday, June 30, 2015 at 12:42:51 PM UTC+2, Ed wrote:

@jens

Is there any downside to Request Builder?  Possible deprecation in GWT 3.0?

Best Regards

Ed

On Mon, Jun 29, 2015 at 1:43 PM, Ed <ej1...@gmail.com> wrote:

Thanks Jens, Great response, gives our devs something to learn.

On Mon, Jun 29, 2015 at 12:55 PM, Jens <jens.ne...@gmail.com> wrote:

1. GWT.create

<generate-with>: Annotation processors

<replace-with>: Dagger 2.x + AutoFactory (assisted inject) for injection and System.getProperty() to build the Dagger dependency graph based on your deferred binding properties.

For Dagger I created a pull request that generates a dagger-gwt artifact including a GWT module: https://github.com/google/dagger/pull/119

2. RPC

Anything that generates code in a way that is compatible with annotation processors so they can migrate to APT in the future. I guess you need to ask maintainers of your preferred alternatives and hear what they say. Regardless of GWT 3.0 I would never really use GWT-RPC again because things like RPC policy files, "do not use interfaces in serializable types" and that it is hard to consume outside of GWT are annoying.

-- J.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsub...@googlegroups.com.

[Ed]

@jens @umit

Thank you very much for this insight.

Best Regards

Ed

On Tue, Jun 30, 2015 at 9:44 AM, Ümit Seren <uemit...@gmail.com> wrote:

In addition to what Jens said:
If possible, go Restful. it makes it much easier to later add non-GWT clients and also forces you to think about your domain model as resources (might lead to a clean API).

I guess once Elemental 2.0 is released (AFAIK along the lines with GWT 3.0) you could  either use XMLHttpRequest or fetch (https://developers.google.com/web/updates/2015/03/introduction-to-fetch?hl=en) if you don't mind to use a polyfill for non-supported browser (maybe at that point all the evergreen browsers already support it natively) or use a higher abstraction (like RestyGWT, etc)

On Tuesday, June 30, 2015 at 12:42:51 PM UTC+2, Ed wrote:

@jens

Is there any downside to Request Builder?  Possible deprecation in GWT 3.0?

Best Regards

Ed

On Mon, Jun 29, 2015 at 1:43 PM, Ed <ej1...@gmail.com> wrote:

Thanks Jens, Great response, gives our devs something to learn.

On Mon, Jun 29, 2015 at 12:55 PM, Jens <jens.ne...@gmail.com> wrote:

1. GWT.create

<generate-with>: Annotation processors

<replace-with>: Dagger 2.x + AutoFactory (assisted inject) for injection and System.getProperty() to build the Dagger dependency graph based on your deferred binding properties.

For Dagger I created a pull request that generates a dagger-gwt artifact including a GWT module: https://github.com/google/dagger/pull/119

2. RPC

Anything that generates code in a way that is compatible with annotation processors so they can migrate to APT in the future. I guess you need to ask maintainers of your preferred alternatives and hear what they say. Regardless of GWT 3.0 I would never really use GWT-RPC again because things like RPC policy files, "do not use interfaces in serializable types" and that it is hard to consume outside of GWT are annoying.

-- J.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-tool...@googlegroups.com.

To post to this group, send email to google-we...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-tool...@googlegroups.com.

[P.G.Taboada]

I cannot disagree more. Restful, as far as I understand, does not replace gwt-rpc as it does not provide polymorphism. It might be an issue with the current implementations I had a look - can someone tell me some implementation that can handle object graphs and polymorphism as gwt-rpc does?

There are some folks (like me), that stick to the command pattern once introduced by ray in his google io talk. 

I am not giving away batching, caching, versioning of my services that easy...

My code is doing

<A extends Action<R>, R extends Result>
      void execute(A action, AsyncCallback<R> callback);

all over the place. It is a piece of cake for to change the communication layer, as long as I can send Actions through it.

is dagger + ... an alternative to gwt-rpc?

[Lars]

Both gwt-jackson (https://github.com/nmorel/gwt-jackson/wiki/Type-support) and restygwt (resty-gwt.github.io/documentation/restygwt-user-guide.html) supports polymorphism (and gwt-jackson in addition generics)!

gwt-rpc is nice at the beginning (fast learning curve), but hurts later on - because it's mixes data(-structure) with implementation :-(

[Jens]

is dagger + ... an alternative to gwt-rpc?

Dagger is an injection library like google-gin with the difference that it uses annotation processors instead of GWT.create(). It has nothing to do with gwt-rpc. 

[marian lux]

Where can I read that GWT RPC and widget system will be dropped with GWT 3.0? Is there a presentation / doc online?

And what does it mean that GWT.create will be dropped?

And: really dropped or set as deprecated?

[Jens]

Where can I read that GWT RPC and widget system will be dropped with GWT 3.0? Is there a presentation / doc online?

And what does it mean that GWT.create will be dropped?

And: really dropped or set as deprecated?

GWT 3.0 drops support for JSNI and GWT.create(). JSNI will be replaced with JsInterop and GWT.create() will be replaced with either annotation processors (generate-with case) or dependency injection/System.getProperty (replace-with case). So all library code of GWT which depends on those two features need to be ported to the new GWT compiler. 

Widget is probably doable but GWT-RPC might be really difficult (if not impossible) because the current GWT-RPC generator asks questions like "give me all types that implement XYZ" which an annotation processor can only hardly answer (if at all). GWT-RPC might be portable if some refactoring in the app using GWT-RPC is acceptable (e.g. slapping annotations on DTOs instead of marking them with Serializable).

You can see videos about that topic from the GWT 2015 meet up at https://www.youtube.com/playlist?list=PL1yReUCGwGvrqscLu1EAyYRPrr0ceEHLE

Slides are linked in the playlist description.

-- J.

[Ed]

It was process but we ported everything to  the low level RequestBuildner.and json. Now we have just one timer in the UI a huge reduction from the async nature of RPC.

 In our situation we render everything out of a DataDictionary on the server side and use a Frame for the results,

The GUI is pure GWT. Size of application rose from 182k to 1.5 meg including split points.  Without profiling it is noticeably faster without RPC.  I am guessing that there are less instantiations of classes on server and UI.

All in all, we are ready for GWT 3.0 and look forward to the stable 2.8.

Thanks for all your help!

Best Regards

--

You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-tool...@googlegroups.com.

[marian lux]

Thank you for your answer Jens. So much GWT solutions build on widget system so I think there will be a port/solution (thinking about the new GWT Material Project which was startend a view months ago...).

@Ed: so you use a REST service on backend? Seems also for us a good solution but debugging inside IDE will be lost.

[salk31]

Is there a guide somewhere of migration path to 3.0 per feature? 

I've been trying to follow these threads but I'm still not sure on the future of things like RequestFactory and Editor. They heavily depend on GWT.create and the latter depends on Widgets, are they really going away?

We have a large-ish app so want to start worrying about migration even if we are long way off.

Cheers

Sam

[Thomas Broyer]

I think nobody has such information yet; not even Google who are pushing for the change. They do have many apps that use widgets and RPC today (example: Google Groups, the exact app I'm typing this message into) and will need to come up with a migration path for those apps too.

[salk31]

Thanks Thomas,

For my own use I'm going to keep a list of what I think I know http://salk31.blogspot.co.uk/2015/10/gwt-30-migration.html corrections welcome.

I can see why they want to reduce the scope of GWT and integrate (not build) but is such a high quality complete package in 2.7 it is a bit scary. I've had to use BroadVision, Vignette, Struts 1, Cocoon, Wicket... in the past and GWT felt like finally web development had grown up.

[steve Zara]

I'm eager for GWT 2.8 because of Lambda support, but I can't see that my company will ever use GWT 3.0 if what you write is true. We have products that make substantial use of GWT Widgets, and there is no prospect of re-writing to some other system.  GWT without the Widgets just isn't GWT - it's just a Java -> JavaScript transpiler.  We also use UIBinder heavily.  

Of course, this may not be what happens.  It's a symptom of what seems to be a common problem with GWT - lack of clear information about what is happening with the project (still no sign of GWT 2.8, and no indication of when there might be a sign).

GWT really is wonderful and has been a source of great productivity for my company for many years.  I really hope the heart of it isn't slashed out to produce some incompatible new version.  

On Saturday, 17 October 2015 11:36:45 UTC+1, salk31 wrote:

Thanks Thomas,

For my own use I'm going to keep a list of what I think I know http://salk31.blogspot.co.uk/2015/10/gwt-30-migration.html corrections welcome.

I can see why they want to reduce the scope of GWT and integrate (not build) but is such a high quality complete package in 2.7 it is a bit scary. I've had to use BroadVision, Vignette, Struts 1, Cocoon, Wicket... in the past and GWT felt like finally web development had grown up.

o

[salk31]

Maybe there is effectively going to be a fork? So if the interest was there could be GWT 2.9 - GWT 2.123

I think that might represent the truth that there is one user base that wants to build Java apps that happen to run in a browser vs users who are working on products that need to squeeze everything out of the browser.

The discussion about classic dev mode didn't seem very healthy https://groups.google.com/forum/#!topic/google-web-toolkit/QSEjbhhHB4g  maybe because of this split?

[steve Zara]

I'm puzzled as to what the disadvantages could be of GWT Widgets.  They are, after all, translated to efficient JavaScript and allow full use of the browser.  I can see that some developers might want to integrate with JavaScript frameworks, but others, like me, start writing applications in pure GWT and use of JavaScript is just like use of JNI in typical Java code - for those rare things you can't do in Java, or to connect with libraries.

I guess if there was a split there could be much more work on what many developers seem to want, such as a cross-browser debugging toolkit that makes use of source maps consistent and gives a better Java-style view of variables.  

I want to see Java as a primary language for browser development, not some secondary add-on to JavaScript frameworks.

--
You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/SjvCh37nahw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.

[salk31]

I can see the logic of GWT 3.0. The browser has evolved a lot since GWT was first designed. Back in those days every browser had significant quirks and the lowest common denominator was very low. In 2015 there is less reason for a big layer between domain code and the browser. I think the same applies to JQuery etc. I also think GWT wasn't quite sure how to do layout which harms love for it. There is a fork in the Widgets for the Layout and non-Layout classes. Hence two TabPanels etc? A fight between those that wanted to do layout like Swing and those that wanted to lean on the browser renderer?

To unsubscribe from this group and all its topics, send an email to google-web-toolkit+unsub...@googlegroups.com.

[Vassilis Virvilis]

If you just want to run java apps in the browser there are solutions out thtere
Free: http://www.webswing.org
Paying: http://www.creamtec.com/products/ajaxswing/overview.html

Now if you want to run create webapps then it is another matter. For me the web stack is a crazy platform. But still since it is backed by all these people (us, developers) is the __platform__ and if you want to write for the __platform__ then you have to speak the platform language natively. That is HTML, CSS, JS. All the  new cool things, the new UI paradigms the new libraries the new API are happening in browser-land in JS.

I think that the GWT did the right thing with the super dev mode. I develop in chromium and firefox. I occasionally test in IE and in Safari to deal with the weird platform idiosyncrasies (bugs?). I also test less often in mobile devices to get the touch events more or less right. How I am about to test all these things in classic dev mode with Firefox 24? Why do I need a java debugger when my main problem is not on the logical end of my program but on the assumptions my program makes for the platform it runs on? (Why the event didn't fire? Why it did fire multiple times? What does preventDefault() does in this case? Why there are extra padding? Where the hell is my padding? Who painted my pixels?)

About the fork you mentioned. I think the GWT is on the right track also on this one. I am slowly phasing out the use of gwt widgets not because I want to, not because they are not working good enough. They are perfectly fine for me but my users want more shiny toys i.e. rotary dials instead of menus and drawers instead of pull down menus or menubars. And you have to admit the GWT widgets are somewhat rusty - most of them are designed with tables and they are impossible to change without breaking compatibility.

So I believe a division of GWT to GWT-compiler and GWT-widgets as a separate compatible library is not a bad move especially if it accompanied with a better ([semi] automatic) way to interface new and cool JS libraries like JSInterop claims to be. It makes perfect sense to me.

--
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 post to this group, send email to google-we...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

--

Vassilis Virvilis

[Ümit Seren]

+1 
I think the division of GWT-compiler and GWT-widgets is the right thing to do. The web-platform is moving fast and to GWT has to adopt to stay relevant.
Webcomponents have the potential to become the new widgets and the new JSInterops will make it quite easy to consume webcomponents that are developed in vanilla JS. Also, now that Microsoft moved to an evergreen approach with their Edge browser, all the quirks with browser incompatibilities will become less and less important. 
Dart is also taking a similar appraoch. They are working on a new JSInterop that is annotated based and looks quite similar to GWT's JSInterops (http://work.j832.com/2015/10/byojsl.html) and they are working on a DEV_compiler that allows to easily consume Dart from Javascript (similar to what @JsExport does I guess). 
I know that many people have huge legacy apps that are based on GWT-widgets and it is a pain to migrate but it does not have to be an all or nothing approach. It is possible to phase out gwt-widgets step by step with 2.8 and once everything is phased out switch to GWT 3.0. Also there is no reason why one couldn't just use GWT 2.8 because if one heavily use the GWT-widgets abstractions and is not really working close the web plattform, then GWT 3.0 won't give any real killer features that are not available in 2.8 (IMHO). 

In general I am quite excited about the future of GWT. 

--
You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/SjvCh37nahw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.

[Jens]

Somehow people seem to forget that they don't have to migrate at all if its not profitable. Just stay on GWT 2.8.x and only start new projects with new technology. There will be plenty of companies that have huge apps that will not be rewritten anytime soon (if at all) so IMHO GWT 2.8.x will continuously get bug fixes for years. Maybe in the long run not from the Google GWT team because Google has the power to actually migrate their apps and will probably focus on the new compiler then once that has happened.

Personally I consider the new Java to Closure compiler/transpiler as a separate product. Migrating to a new product costs money and time so its totally valid to not migrate. Our company will definitely not migrate anytime soon unless there is an easy incremental migration path. Only new stuff might be build with the new Java to Closure compiler. 

-- J.

[salk31]

I'm trying to understand my options.

* Stick with 2.x and risk being left behind and the project becoming neglected due to split effort.

* Try to migrate to 3.x and possibly throw away a big investment.

* Look to move to something other than GWT.

Obviously we will also be taking action to isolate ourselves from this uncertainty. A lot of that is just good practice anyway.

FWIW Our team works on a single app that is meant to have a life of 10+ years.

[Vassilis Virvilis]

Actually what makes sense for me in an after split era is

* compile with the newest GWT 3.5, 4, 5 to pick up new features

* link with legacy but compatible gwt-widgets until I can gradually get rid of them - or not.

This way I can migrate step by step my application (widget per widget) and stay relevant in the meantime or for some application to not upgrade at all.

Of course that assumes that gwt widgets will be maintained at least minimally to the point that they are compilable with the newer GWT versions.

--

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 post to this group, send email to google-we...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

--

Vassilis Virvilis

[Jens]

* Stick with 2.x and risk being left behind and the project becoming neglected due to split effort.

You are not behind when using 2.x:

GWT 2 = GWT 2.x Compiler + JsInterop + Elemental 1 + Elemental 2 when released + all current GWT SDK code + all GWT libraries.

GWT 3 = J2CL + JsInterop + Elemental 2 + anything from GWT SDK and other GWT libraries that is compatible with J2CL

So not such a difference right? In fact with GWT 3 you currently get less than with GWT 2.x because you can not use all library code available. However everything that works with GWT 3 should automatically also work with GWT 2. 

 

FWIW Our team works on a single app that is meant to have a life of 10+ years.

Same here, but I am not concerned at all about using GWT 2. However maybe I get jealous if GWT 3 provides a lot faster developer workflow.

-- J.

[Thomas Broyer]

On Monday, October 19, 2015 at 12:22:19 PM UTC+2, Jens wrote:

* Stick with 2.x and risk being left behind and the project becoming neglected due to split effort.

You are not behind when using 2.x:

GWT 2 = GWT 2.x Compiler + JsInterop + Elemental 1 + Elemental 2 when released + all current GWT SDK code + all GWT libraries.

GWT 3 = J2CL + JsInterop + Elemental 2 + anything from GWT SDK and other GWT libraries that is compatible with J2CL

So not such a difference right? In fact with GWT 3 you currently get less than with GWT 2.x because you can not use all library code available. However everything that works with GWT 3 should automatically also work with GWT 2.

I don't think "JSNI 2" (the one without the 'native' keyword and special comment syntax) will be backported to GWT 2.x, and evolutions to JsInterop are likely to be GWT 3+ only too.

I think what salk31 meant is that in one or 2 years from now, GWT 2.x might really be "behind", depending on who puts the efforts in supporting GWT 2.x. Who knows if existing library code won't break in newer versions of evergreen browsers? (just like History.newItem in GWT <=2.6 breaks in Firefox 41+ because Firefox finally aligned its behavior on the "consensus" specified in "HTML the living standard"; more generally, all permutation-specific code might break in the future as browsers converge to an interoperable behavior, so GWT 2.x will have to be actively maintained). And as GWT 3.x and 2.x will start diverging (JSNI 2, JsInterop 2; Java 9 ?), libraries will start to become incompatible with GWT 2.x.

So I really think that this is a legitimate concern, and that nobody has the answer yet. The only thing we're sure is that Google will push internally to moving to j2cl; we just don't know how they'll do it (rewrite parts of the apps that aren't compatible with j2cl, or start bringing to GWT 3.x the libs that they internally need, possibly not in a fully backwards-compatible way though, as they have the tooling to refactor all their codebase at once: kythe, refaster, etc.)

[Jurjen van Geenen]

+1: RPC is one of GWT's strong suits. Haven't seen another web-oriented (de-)serialization mechanism that handles polymophism, generics and bidi relations without config or pain. Doesn't litter your domain classes with non-standard annotations or dependencies. AnyGWT 3.0 alternative should be just as good.

Op maandag 6 juli 2015 01:26:12 UTC+2 schreef P.G.Taboada: