Re: New project best practice

[Bryan Buchanan]

Wow - thanks for the detailed reply.

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

Re: New project best practice

[Vassilis Virvilis]

Peter thanks for the detailed post.

I agree with most of the points. My suggestions for a new project, although
even I am not following it strictly due to existing codebase.

1) Split Client (GWT) and Server part (GWT-RPC). This wasn't possible for
me due to the interface files with GWT-RPC. It is possible however with
Resty-GWT and jaxrs in the server. I am using CXF but others option do
exist. For complex pojos there are ways to interfere with the serialization
and deserialization in order to make things digestable in both sides

2) Use elemental2 and jsinteropify your js dependencies. I agree with Peter
that there is a cultural between java and js and some things do not map
intuitively. I have jsinteropify

   - jquery
   - datatables
   - d3
   - daterangepicker
   - bootstrap modals

and only datatables is seriously not properly mapped to java mappings.

3) Avoid gwt widgets. God I will miss HeaderPanel -- welcome FlexBox. Gwt
widgets are not so nice compared to native javascript libraries and they
are slowly deprecating...

My two cents



On Sun, Nov 5, 2017 at 4:32 AM, Peter Donald  wrote:

> Hi,
>
> On Fri, Nov 3, 2017 at 1:45 PM, Bryan Buchanan 
> wrote:
>>
>> If I was to start a new GWT project today, what is the recommended way to
>> generate the UI (Elements, UIBinder, ??) and exchange data with a back end
>> (RCP, ??)
>>
>
> There are as many different answers to this as there are people is my
> guess and a lot of the answers are contingent on j2cl/gwt3 not being
> vapourware.
>
> However this is our experience. We have several largish apps that are all
> built around a subset of GWT (Events, UIBinder, Widgets and GWT-RPC) that
> have been in active development since 2011 or so. Up until a few months ago
> we had planned to continue to use Events, UIBinder, Widgets into GWT3/j2cl
> and convert to jsinterop as required. (GWT-RPC was to be replaced but we
> had an abstraction layer that would make that relatively easy). However
> something forced us to look at the javascript ecosystem in earnest and we
> have since switched our strategy and are absolutely loving the change.
>
> Roughly we looked at all the popular javascript framework ecosystems and
> came to the conclusion that we really wanted to use either VueJS or React
> for the view and Mobx for state management. There was a whole suite of
> other libraries that we wanted to use from javascript as well. We were sort
> of limited in what we could select as we needed a stable base that likely
> to survive the next 10ish years and we still wanted to use Java for the
> application logic, network stack, dependency injection etc. Ideally, we
> also wanted to be able to use Closure Compiler to compile both java and
> javascript into a single bundle.
>
> We found that some of the libraries were very difficult to wrap and call
> from java or that the constructs were clumsy and confusing. i.e. We often
> found that to wrap library X required that the user had deep knowledge of
> both the library, how javascript works and how gwt works which was too
> much. Some libraries just did not make sense in a GWT/java world.
>
> So what we have essentially done is whittled it down to a small number of
> essential libraries and we are creating java-ish abstractions on top of
> them. The developers then just treat it like a normal GWT library. The
> advantage is that they do not need to have a deep understanding or
> javascript, jsinterop etc but get all the advantages of using a
> well-thought out abstraction.
>
> About the only thing we have no good solution for is assets (i.e. CSS,
> images, etc) and the plan was to continue to use GWT 2.x abstractions for
> that until j2cl came out or we became desperate for something more. This is
> no where as good as the css-in-js solutions or webpack loaders available in
> native javascript ecosystem but hopefully we can remedy it in the future.
>
> Anyhoo we use the following libraries without reservation:
>
> * Dagger 2 for dependency injection (https://google.github.io/dagger/)
> * Elemental2 for Browser Integration (https://github.com/google/elemental2
> )
>
> Elemental2 does not see frequent releases, is beta, and missing lots and
> is a PITA to build. However it is built by Google and presumably used
> internally quite heavily and based of closure which is even wider usage so
> we expect this to improve over time. It also covers all/most of our use
> cases so we have been happy with it. When we hit something that not yet
> covered it is simple to write your own jsinterop abstraction.
>
> An interesting library that we are watching but have yet to use is VueGWT (
> https://github.com/Axellience/vue-gwt). It looks like it could be very
> nice and developers seem active and
>
> We also have our own library that does state management which is a
> reimplementation of principles of Mobx in java with a few other libraries
> blended into it. It is probably one of the best 

Re: New project best practice

[Peter Donald]

Hi,

On Fri, Nov 3, 2017 at 1:45 PM, Bryan Buchanan  wrote:
>
> If I was to start a new GWT project today, what is the recommended way to
> generate the UI (Elements, UIBinder, ??) and exchange data with a back end
> (RCP, ??)
>

There are as many different answers to this as there are people is my guess
and a lot of the answers are contingent on j2cl/gwt3 not being vapourware.

However this is our experience. We have several largish apps that are all
built around a subset of GWT (Events, UIBinder, Widgets and GWT-RPC) that
have been in active development since 2011 or so. Up until a few months ago
we had planned to continue to use Events, UIBinder, Widgets into GWT3/j2cl
and convert to jsinterop as required. (GWT-RPC was to be replaced but we
had an abstraction layer that would make that relatively easy). However
something forced us to look at the javascript ecosystem in earnest and we
have since switched our strategy and are absolutely loving the change.

Roughly we looked at all the popular javascript framework ecosystems and
came to the conclusion that we really wanted to use either VueJS or React
for the view and Mobx for state management. There was a whole suite of
other libraries that we wanted to use from javascript as well. We were sort
of limited in what we could select as we needed a stable base that likely
to survive the next 10ish years and we still wanted to use Java for the
application logic, network stack, dependency injection etc. Ideally, we
also wanted to be able to use Closure Compiler to compile both java and
javascript into a single bundle.

We found that some of the libraries were very difficult to wrap and call
from java or that the constructs were clumsy and confusing. i.e. We often
found that to wrap library X required that the user had deep knowledge of
both the library, how javascript works and how gwt works which was too
much. Some libraries just did not make sense in a GWT/java world.

So what we have essentially done is whittled it down to a small number of
essential libraries and we are creating java-ish abstractions on top of
them. The developers then just treat it like a normal GWT library. The
advantage is that they do not need to have a deep understanding or
javascript, jsinterop etc but get all the advantages of using a
well-thought out abstraction.

About the only thing we have no good solution for is assets (i.e. CSS,
images, etc) and the plan was to continue to use GWT 2.x abstractions for
that until j2cl came out or we became desperate for something more. This is
no where as good as the css-in-js solutions or webpack loaders available in
native javascript ecosystem but hopefully we can remedy it in the future.

Anyhoo we use the following libraries without reservation:

* Dagger 2 for dependency injection (https://google.github.io/dagger/)
* Elemental2 for Browser Integration (https://github.com/google/elemental2)

Elemental2 does not see frequent releases, is beta, and missing lots and is
a PITA to build. However it is built by Google and presumably used
internally quite heavily and based of closure which is even wider usage so
we expect this to improve over time. It also covers all/most of our use
cases so we have been happy with it. When we hit something that not yet
covered it is simple to write your own jsinterop abstraction.

An interesting library that we are watching but have yet to use is VueGWT (
https://github.com/Axellience/vue-gwt). It looks like it could be very nice
and developers seem active and

We also have our own library that does state management which is a
reimplementation of principles of Mobx in java with a few other libraries
blended into it. It is probably one of the best things about our new
architecture but it is still in flux but will hopefully stabilise by the
start of December. Unfortunately it is yet to be properly documented but
you can see the start of it at http://realityforge.org/arez/ and
https://github.com/realityforge/arez

We are also working on a fork/rewrite of GWTReact (
https://github.com/GWTReact/gwt-react) - you can see our work at
http://realityforge.org/react4j/ and https://github.com/realityforge/react4j
but it is in an early stage and I expect it will stabilise Mar next year. I
am encouraged to see that react may also be moving towards being
optimisable by closure compiler which would potentially make a lot of
different in j2cl world.

You can see what an Arez+React4j applications looks like at
https://github.com/realityforge/react4j/tree/master/todomvc/src/main/java/react4j/todomvc

So it depends on how much runway you have to launch your app and how long
you want to support it. If you can experiment in the javascript ecosystem
and bring what you want from there. Our move to Arez+React4j has been
amazingly successful and I can not see us ever going back to the old way of
building apps ... ever. What works for us may not work for you (the groups
is mostly java developers who are not front end