Hi, On Fri, Nov 3, 2017 at 1:45 PM, Bryan Buchanan <bry...@webbtide.com> 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 specialists). However the javascript ecosystems is rich enough that you will find something that works in your context. (It should be noted that I have also hear rumours that there are people who are looking at bringing significant portions of gwt2 framework in j2cl age so staying with what you know and adopting GMD or a similar modern widget toolkit may also work) There are some things that are missing in GWT2.x world that I hope will be fixed by j2cl/GWT (optimising native javascript, webpack equivalent, better asset pipeline control) but it has not stopped us moving everything else forward and development is great again. -- 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+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.
