Polymer (2.0) + GWT => Stock of the situation ? Coming GWT 3 soon or not ? What is the right way for a LTS application ?

[fmipsylone]

Hi, This is not an issue ... maybe a brainstorming discussion ;)
There is a while from now that I'm looking for the best and long term approach to integrate Polymer with GWT.

I used a lot GWT 2.5 and 2.6 for b2b projects in the past. I followed GWT evolutions, GWT3.0 anticipation projects like The Herald Pehl (from Red Hat) conference at the GWTcon 2016 and WebComponents and Polymer integration initiatives like WeTheInternet/gwtc, and this awesome gwt-api-generator which can be a really source of inspiration.
But I have to confess that, due to many reasons (Obscure GWT roadmap, HTML5 APIs evolutions and too much partials support), I was sure that many of theses initiatives would be deprecated quickly.
And I understand developers and companies reviewing their point of view on GWT usage because of the lacks (for me) of a strong LTS right way and manner to evolve with GWT today.

I'm always convinced by GWT for middle and strong LTS projects. Java8, J2CL, enhance that. And I'm sure that a combination based on the couple GWT/Polymer is the right way for a reliable and new generation UI application. The Polymer project make the exclusion of the widgets API out of GWT a really good thing for UIs.

But for now what is the situation ? If we want to start a development today, what is the right way to proceed for Polymer integration ?
It is mentioned in the README.md that "Vaadin no longer provides support (...) We took this decision because once demonstrated that polymer elements could be easily be integrated in GWT".
Yes It's true. But I did not find on the web any prettier or better alternatives to integrate and manipulate easily Polymer Elements from a GWT application.

So today, If we want to be GWT3 pseudo-compliant (no UiBinder) with a UI based on Polymer 2.0, and builds based or more recent build tools (migration from bower to npm or yarn) what we can use for a LTS GWT app ?

Does we have to continue integration of the gwt-api-generator ? What is the status for Polymer 2.0 ?
Does an API generator stays a good solution for future (due to the elements quantity and the different cases to manage) ?
Do you think that create a fork or start a from scratch project based on elemental2 (in beta at this time) would be a good idea ?

Or, in the state of things and taking into account the Polymer Elements evolution philosophy, does the idea of keeping out Polymer 2.0 (static import) from a GWT app and just communicate through a JSInterop API with separated or combined toolchains would be THE solution to have a reliable application, to avoid DRY code, and keep UI detach from the core of an app ?

Thanks for your advises.

[manolo]

Sorry by the delay, I agree that WC + GWT would be the future of development with GWT.
Polymer WC is a good option for the first, and the second is elemental2 + JsInterop, either with gwt-2.8.1 and probably with j2cl.

Roadmap for the generator,

• use elemental2 by default (already merged)
• use analyzer instead of Hydrolysis to support both polymer 1.x and 2.x components (work in progress)
• remove widget support (still to be decided)
• use polymer html templates in runtime (not decided) but gwt-elemento could be a good alternative.

Since elements api from java perspective should not vary so much, I would say that it's a good LGT, even though the evolution of those components to polymer 2, or 3

[ibaca]

-IMO Widget support is pretty important, but make it decoupled and as an optional modules is a good idea too. And, you are the developer but, it is not as hard to add widget support, isn't it?- Correction: actually it is only important to *have an easy and clear strategy to integrate WC with widgets*, but yep, maybe avoiding all those widgets wrappers and delegating to elemento or some other lib to just integrating elements with widgets might fit better.

…

On dom., 10 sept. 2017 11:01 Manuel Carrasco Moñino < ***@***.***> wrote: Sorry by the delay, I agree that WC + GWT would be the future of development with GWT. Polymer WC is a good option for the first, and the second is elemental2 + JsInterop, either with gwt-2.8.1 and probably with j2cl. Roadmap for the generator, - use elemental2 by default (already merged) - use analyzer instead of Hydrolysis to support both polymer 1.x and 2.x components (work in progress) - remove widget support (still to be decided) Since elements api from java perspective should not vary so much, I would say that it's a good LGT, even though the evolution of those components to polymer 2, or 3 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#83 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA_nMTFT2gtA5xZgszQZnwoDO6UUojheks5sg6VqgaJpZM4OuuN9> .

[manolo]

Even though Widgets has been the centre of GWT, I think almost advantages that made GWT develop this abstraction model are not valid nowadays.
I believe widgets system will remain as a separated library, but also I think it needs an evolution to remove those old fashion widgets and make them pluggable or replaceable, and this would require some important efforts that depend on the community contributing.

[ibaca]

I see it a bit different, but to be honest, I'm not sure if this can be done or if this is practical, but... there is a possibility to maintains Widgets removing progressively (and partially backward compatible) all the abstraction leaving it as a thin component, as most UI libs have. So the widget migration consists on refactor and delegate most of the UI responsibility to the root element or custom element. A weird thing here is that now Widgets are the VIEW (or are used in the VIEW) of any MVP (or its variants), but if all the UI is delegated to the element, the widgets might be the presenter.

Not sure at all... just might be an alternative to widgets just removing responsibilities progressively. Removing the current events system in favor of direct element subscription is the first step, but this will drop IE8 and not sure if IE9 support. Anyway, doing this in a separate project will be much faster.

Using "Polymer-Widgets" can causing very bad issues: Issues: 145
The problem is how the UiBinder is building the DOM-Templates with <span> elements as placeholders for widgets. Therefore I would not use Polymer widgets anymore.

My recommendation for future GWT & WC:

• really good JsInterop support, esp. for data types
• having the data model in JS with JsInterop interfaces
• bind everything (data model and event handling) with the polymer "dom-bind" template
• using node finding instead of @UiField binding
• support computed properties, esp. the class attribute (hidden works already)

This way all you need are Java wrappers for Polymer, Template and HTMLElement. The latter can be extended for some individual methods like open() for a paper-dialog...

[ibaca]

Ok, you are right.

Actually what I said is that there is a possibility to migrate widget to a custom element, making Widget extends HTMLElement and use custom elements to make this work. So yep, polymer and the GWT widgets are actually solving the same problem, are tools to create UI components. I have been trying out this here https://github.com/ibaca/rxtodo-gwt/blob/webcomponent/src/main/java/todo/client/FooterElement.java
So at this point, both GWT Widgets and Polymer will be custom elements, you can choose to use either Polymer or GWT Widgets to create your components.

This is more related to the future of GWT. In this project, yep probably I was wrong, the widgets wrapper are not needed.

So yep, polymer and the GWT widgets are actually solving the same problem, are tools to create UI components

But you can't share it across other projects (without GWT) nor are you able to benefit from other WC (behaviors). For UI components there is definitely no benefit to do it the "Java-way" anymore.

IMHO GWT should focus on things where it can be better than other frameworks:

• structuring of (bigger / more complex) web applications
• routing
• i18n
• writing / testing business logic within the Java ecosystem

The open point is data binding since the editor framework is also somewhat outdated. Should GWT offer its own data binding or not? With JsInteropt it's possible to use Angular or Polymer data-binding where I personally prefer Polymer since there is no "magic" behind the scenes - just setting properties on elements, the same for binding event handling methods / functions.

[fmipsylone]

I totally agree with @manolo and partially with @muelbr.

GWT should be oriented to be used as a core component of a web application. IMHO Its role is to mainly guarantee the perfect integration and compliance with HTML standards to allow a long term support of core and logics web apps. Secondly, It has to manage the UIs loading, models and web services creation...
We don't know what would be the next UIs frameworks. We are already talking about Polymer 3 (with ES6 module imports in place of HTML imports), ES7...
So IMHO UIs and Widgets should be totally externalized to GWT. GWT will act as a Model and Web Services manager and a Presenter enhenced by JSInterop. It should be fully independant of the UIs widgets toolboxes or frameworks used.

IMO routing and i18n should be also externalized as they are part of the UIs.
Using Polymer, it is easy to navigate through the UI with just links so why to pull up the routing management to GWT ?
It is the same thing for i18n, translations should be part of the UIs framework used, and other translations should be pull up from the web services. GWT core application component could be totally i18n independant.

I think that GWT has to be in charge of the application logics, the models interactions, web services data exchanges (it would be cool to have a perfect Rest Client), third parties data bindings and app logics testing. GWT has to evolve with HTML standards (thanks to elemental) to allow a fluent evolution of the app. IMHO the way to go is to make easy communication between GWT and third parties libraries through Promises with JSInterop. Or having ReactiveJava (RxJava) integrated will be a idea. By this way communication with be fully transparent and every third parties should be easy integrable, replaceable and interchangeable whereas the core app will remain the same and stay up to date. Taking advantages of all the GWT benefits (Java language, Java tools, code generation (AP), IOC,..)

[Waxolunist]

According to routing: IMHO places and activities in the right way used is a superior routing mechanism. The views are interfaces and all gwt-polymer usage is in the implementations of these interfaces, which can also be just jsinterop facades. No problem with that.
Also i18n in gwt is quite good. I would miss it.

[Waxolunist]

Polymer 2 is working, as long as I use hybrid elements. I could also use other elements which have a 2.x dependency and are written using es6 class syntax, if you could publish the analyzer stuff.