Tuesday, February 26, 2019

Re: Tips on libraries

First of all thanks for the suggestions (Thomas, Pavlo, Frank). 

I understand your point of view Thomas, unfortunately I have some constraints, both in terms of budget and delivery times, which I must take into consideration; this is why I said that I must be productive and, for example, abandoning GIN for Dagger is not so simple: as you said, GWTP is a framework and I should try to replace all the different features I have available with something equivalent. However, I will take into consideration the various ideas that have been mentioned in previous posts, thanks again.

As for the part of pure graphical interface, has any of you ever tried to integrate a framework using JsInterop (eg Bootstrap 4)? Is it a viable way or am I saying nonsense? :-)

Il giorno lunedì 25 febbraio 2019 16:31:00 UTC+1, Thomas Broyer ha scritto:


On Monday, February 25, 2019 at 3:08:35 PM UTC+1, Ramon Flamia wrote:
Thanks Thomas, I imagined this answer :-) 

As I wrote in the initial post, my biggest concern is being updated with the UI, so I'm waiting for someone to show me his experience with other UI libraries, maybe even with JsInterop. I have seen the showcases of GWT Material and Domino UI, but I would like to understand how they fit together with the other technologies I have mentioned.

Your suggestions are very useful, but at the moment I do not think I can follow them. Let's me explain my point of view: one thing that struck me when reading the various blog or posts related to GWT is that there is this desire to create code that is already future-proof. But today the release of GWT 3.0 has not yet been announced, nor do we know good specifications. Correct me if I'm wrong: is the advice to avoid GWT generators just to be ready for the future? If so, I see it as a violation of YAGNI.

The main idea is to not lock yourself into choice that will be hard to replace. GWT Places are OK because the generator is optional, and so simple that it can easily be implemented as an annotation processor (and has already been rewritten this was). GIN would be OK too, but the replacement is Dagger 2, which is already available, heavily used (on Android, not necessarily GWT) and actively maintained; so why pick GIN now to later have to migrate to Dagger 2, rather than directly choose Dagger?
What I'm trying to say is to choose wisely: if there's a path forward, or it would relatively easily be replaced/abstracted, then use it; if it's highly structuring and is barely maintained, then carefully balance the gains vs costs/risks; and this of course depends on the expected lifetime of your project.
Beware that browsers' behaviors change, and that an unmaintained client library/framework might mean a broken app in the future; take that into account into your risk evaluation.
 
In particular, if I completely exclude the use of GWTP, I lose some things:
  • integration with a dependency injection framework (to this you already answered me, telling me to replace GIN with Dagger)
  • MVP architecture and consequently difficulty in carrying out TDD development
  • management of the browser history (probably in the link that you indicated to me, related to gwt-places, I can find something interesting)
  • years of experience with this library, which makes me very productive
From what I understand, GWTP is a framework, not a library. The cost of changing to anything else is high.
GWT Places and Activities worked well for me, and is lighter, less "framework-y"; MVP is easy to apply as a pattern, and doesn't necessitate a framework/library. See https://github.com/tbroyer/gwt-maven-archetypes/tree/master/dagger-guice-rf-activities/src/main/resources/archetype-resources/__rootArtifactId__-client/src/main/java for a dummy example.
 
Also, if I have to avoid GWT generators then it means that the GWT Editors and JSR-303 part (Validation) must also be replaced, right?

Bean Validation is already deprecated in GWT proper, so use it at your own risk (you may want to try https://gitlab.com/ManfredTremmel/gwt-bean-validators/tree/master/gwt-bean-validators though)
Editors have a migration path: https://github.com/DominoKit/gwt-editors (they might not play well with gwt-bean-validators though)

You can have a look at https://docs.google.com/spreadsheets/d/1b1D9fEqRh5lZ8cqMJtYoc_25rfTRvsuJkTtS2vjgi3o/edit?usp=sharing for a glance of what GWT 3 might look like.
 
Finally, I had already imagined replacing RPC calls with REST (RestyGwt maybe?), but I have to do some tests first to check that it is advantageous.

From my own tests, JsInterop work great for modelling JSON requests and responses (you can use com.google.gwt.http for requests, or directly XMLHttpRequest, from com.google.gwt.xhr or JsInterop/Elemental2, or fetch through JsInterop/Elemental2). Depending on your browser support needs, URLSearchParams could be used for application/x-www-form-urlencoded requests (https://caniuse.com/#feat=urlsearchparams), and you could always use polyfills for wider browser support.
 
So, if the answer at "Is there one or more framework that offers the same features as GWTP and whose learning curve is fast enough?" is "No", then I'll continue to use GWTP + GIN: I need to be as productive as I am now and I think that modularizing code and using best-practices in class design is the best way to get a feature-proof code (if and when GWT 3.0 is released then I'll see what do...). Otherwise, please tell me how I can replace all the features I've talked about.

Use what works best for you, but not (only) because you're already proficient with it, also weight in the costs/risks of later change (and yes, architecture plays a big role in the equation).

--
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 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.

No comments:

Post a Comment